始终在Java中设置file.encoding系统属性是一个好主意吗？

Question

我认为始终在Java应用程序中设置file.encoding系统属性是个好主意。

假设我没有设置file.encoding 。 这意味着Java将使用依赖于平台的默认字符集（例如，在String.getBytes ），这使得整个应用程序依赖于平台。

例如，如果我们设置-Dfile.encoding=UTF-8 ，我们保证像String.getBytes这样的调用在任何平台上都是一样的。

是否有意义？

Answer 1

不，它不一定有意义。 如果您想在任何平台上读取未由您自己的应用程序创建的文件，您最好保留默认情况下的文件编码，因为这是您需要能够读取这些文件的内容。

如果您读取由您自己的应用程序创建的文件，或者使用已知和指定的文件编码的应用程序，那么您应该在实例化IO读取器和编写器时使用此编码。

对于诸如String.getBytes()方法，只是不要使用它们，如果要使用特定的编码而不是平台的默认编码，请使用String.getBytes(Charset) 。

Answer 2

有条件的是。 正如JB所提到的，当读取由其他本地应用程序（或同一平台上的其他远程应用程序，如果您有同构服务器场）生成的文件时，使用“平台默认”可能偶尔会有所帮助。

因此，谨慎选择，但总的来说，我会说这样做。 总是创建自己的读者的建议并不总是可行的。 我相信一般来说，生成使用扩展字符的文件的大多数事情最终会使用UTF-8。

最后，因为许多文件都依赖于你控制之外做出的选择，所以它将归结为测试和自定义，但是我觉得你更开心地建议你从UTF-8开始并根据需要降级而不是反向。

Answer 3

设置file.encoding System-Property通常不是一个好主意，因为这不是Java中支持的配置选项。

这意味着它可能会也可能不会起作用。 不工作可能意味着例外 。 确切地说，“它适用于Java 1.6，它适用于Windows上的Java 1.7，但它不再适用于Linux上的Java 1.7”。

这背后的原因在这里给出：

J2SE平台规范不要求“file.encoding”属性; 它是Sun实现的内部细节，不应由用户代码检查或修改。 它也是只读的; 在技​​术上不可能支持在命令行或程序执行期间的任何其他时间将此属性设置为任意值。

更改VM和运行时系统使用的默认编码的首选方法是在启动Java程序之前更改底层平台的区域设置。