0

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

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

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

是否有意义？

4

3 回答 3

2

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

如果您读取由您自己的应用程序创建的文件，或者由使用众所周知的指定文件编码的应用程序创建的文件，那么您应该在实例化 IO 读取器和写入器时简单地使用这种编码。

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

于 2013-02-16T17:21:35.633 回答
0

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

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

最后，因为许多文件都依赖于您无法控制的选择，所以这将归结为测试和自定义，但我觉得建议您从 UTF-8 开始并根据需要降级而不是相反。

于 2014-01-02T17:30:52.537 回答
0

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

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

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

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

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

于 2015-02-04T12:55:09.033 回答