我正在测试我的应用程序的i18n兼容性。 我有一个英文版的Windows 7，这意味着系统的显示语言是英语。我将系统区域设置设置为非unicode应用程序的中文。
我的应用程序在导出jdk1.6下的中文字符的Html文件时遇到问题，但在jdk1.7下运行时工作正常。
我调试了它，发现直接原因是Charset.defaultCharset()返回了不同的值。
在jdk1.7下Charset.defaultCharset()返回GBK，这是中文的字符集。
在jdk1.6下Charset.defaultCharset()返回window_1252，这是拉丁语的字符集。
我知道问题可以通过代码中的指定字符集来解决，比如说utf-8。
但我想知道为什么Charset.defaultCharset()在JDK1.7和JDK 1.6下返回不同的值。
答案 0 :(得分：3)
Charset.defaultCharset()给出了JVM运行的字符集，因此它并不总是相同的值。例如，如果您使用Netbeans运行程序，它将始终返回UTF-8，因为这是Netbeans中Java项目的默认编码。
我的设置类似于你的设置。我的Windows是英文（菜单，对话框是英文），我使用土耳其语非Unicode应用程序。当我在没有任何标志或系统参数的情况下启动JVM时，Java 7和Java 6运行时都会在调用Charset.defaultCharset()时给出“CP1254”。 System.getProperty("file.encoding")和默认IO编码也相同。 （这两个Java版本的系统区域设置不同，但这是另一个故事。）
所以我猜你的问题是关于如何启动你的JVM，或者关于JVM如何决定它应该使用的默认编码。如果您确定问题不是前者（您运行JVM时没有任何编码参数，并且您不尝试更改程序中任何位置的默认字符集），那么JVM会错误地获取默认编码，并且很可能是异常行为。
答案 1 :(得分：3)
支持的编码在不同的实现之间 Java平台，标准版7（Java SE 7）。
Java虚拟机的每个实例都有一个默认字符集， 可能是也可能不是标准字符集之一。默认 charset是在虚拟机启动期间确定的 取决于底层使用的语言环境和字符集 操作系统。
另外，我发现了"bug"关于使用-Dfile.encoding进行最终评估的问题：
这不是错误。 “file.encoding”属性不是必需的 J2SE平台规范;这是Sun的内部细节 实现，不应由用户代码检查或修改。 它也是只读的;这在技术上是不可能的 支持将此属性设置为上的任意值 命令行或程序执行期间的任何其他时间。
更改VM使用的默认编码的首选方法 运行时系统将更改底层平台的区域设置 在开始Java程序之前。