我认为在Java应用程序中始终设置file.encoding系统属性是个好主意。
假设I不设置file.encoding。这意味着Java将使用依赖于平台的默认字符集（例如在String.getBytes中），这使得整个应用程序依赖于平台。
例如，如果我们设置-Dfile.encoding=UTF-8，我们保证像String.getBytes这样的调用在任何平台上都能正常工作。
这有道理吗？
不，这不一定有意义。如果你想在任何平台上读取不是由你自己的应用程序创建的文件，你最好保持默认的文件编码，因为这就是你读取这些文件所需要的。
如果您读取由自己的应用程序创建的文件，或者由使用已知和指定的文件编码的应用程序生成的文件，那么在实例化IO读写器时，您应该简单地使用此编码。
对于String.getBytes()这样的方法，不要使用它们，如果您想使用特定的编码而不是平台的默认编码，请使用String.getBytes(Charset)。
条件是。正如JB所提到的，在读取其他本地应用程序生成的文件时，使用"平台默认值"可能偶尔会有所帮助（如果您有同构服务器场，则可以是同一平台上的其他远程应用程序）。
所以，要谨慎选择，但总的来说，我会这么做。总是创造自己的读者的建议并不总是可能的。一般来说，我相信大多数生成使用扩展字符的文件的东西最终都会使用UTF-8
最后，因为许多文件都依赖于您无法控制的选择，所以这将归结为测试和定制，但我建议您从UTF-8开始，并根据需要降级，而不是相反。
设置file.encoding系统属性通常不是一个好主意，因为这不是Java中支持的配置选项。
这意味着它可能起作用，也可能不起作用不工作可能意味着出现异常。确切地说，这类问题"它在Java 1.6上工作，在Windows上在Java 1.7上工作，但在Linux上不再工作。"
这里给出了背后的原因：
J2SE不需要"file.encoding"属性平台规范；这是Sun实现的内部细节不应被用户代码检查或修改。它还打算只读；从技术上讲，支持该属性的设置是不可能的在命令行上或在编程过程中的任何其他时间设置为任意值处决
更改VM和运行时系统将更改底层平台的区域设置在启动Java程序之前。