平台在不同平台上的默认字符集？答案

【问题标题】：Platform's default charset on different platforms?平台在不同平台上的默认字符集？
【发布时间】：2012-03-07 22:36:09
【问题描述】：

一些遗留代码依赖于平台的默认字符集进行翻译。对于“西方世界”中的 Windows 和 Linux 安装，我知道这意味着什么。但是考虑到俄罗斯或亚洲平台，我完全不确定他们平台的默认字符集是什么（只是 UTF-16？）。

因此我想知道执行以下代码行时会得到什么：

System.out.println("Default Charset=" + Charset.defaultCharset());

PS：

我不想在这里讨论字符集的问题及其与 Unicode 的区别。我只想收集什么操作系统会产生什么特定的字符集。请仅发布具体值！

【问题讨论】：

标签： java character-encoding platform

【解决方案1】：

这是用户特定的设置。在许多现代 Linux 系统上，它是 UTF-8。在 Mac 上，它是 MacRoman。在美国的 Windows 上，它通常是 CP1250，在欧洲，它是 CP1252。在中国，您经常会看到简体中文（Big5 或 GB*）。

但这是系统默认设置，每个用户都可以随时更改。这可能是解决方案：使用系统属性file.encoding启动应用程序时设置编码

See this answer 怎么做。我建议将其放入一个启动您的应用程序的小脚本中，这样用户默认值就不会受到污染。

【讨论】：

没错，系统的默认字符集可以由用户更改 - 但有多少非开发人员会这样做？
企业网络中携带全球登录信息的人怎么样？我要说的是：永远不要期望那里有任何有用的价值。在您的代码中，您应该始终在读取数据时指定数据的编码。如果这不起作用，那么您必须设置 file.encoding 否则事情将中断:-)
@Aaron Digulla：如果数据由用户提供并且没有编码元数据，那么平台默认编码实际上可能是您最好的选择。
如果我可以问怎么办？如果字符集可以更改和损坏您的数据，您需要通过确保您的应用看不到用户的默认值来处理这个问题。如果字符集可以更改，但对您的应用没有影响，那何必呢？
@Fordi static 主类导入的类中的代码仍然可以看到旧值。一个更好的解决方案是使用-Dfile.encoding=UTF-8 调用Java。但这也不能解决许多文件格式根本不使用 UTF-8 作为默认编码的问题，或者懒惰的用户会尝试将未知编码的文件提供给软件。

【解决方案2】：

对于“西方世界”的 Windows 和 Linux 安装，我知道这意味着什么。

可能没有你想象的那么好。

但考虑到俄罗斯或亚洲平台，我完全不确定他们平台的默认字符集是什么

通常是他们国家历史上使用的任何编码。

（只是 UTF-16？）。

绝对不是。在 Unicode 标准存在之前，计算机的使用已经广泛传播，每个语言领域都开发了一种或多种可以支持其语言的编码。那些在 ASCII 之外需要少于 128 个字符的人通常会开发“扩展 ASCII”，其中许多最终被标准化为 ISO-8859，而其他人则开发了两字节编码，通常是几个相互竞争的编码。例如，在日本，电子邮件通常使用JIS，但网页使用Shift-JIS，一些应用程序使用EUC-JP。这些中的任何一个都可能作为 Java 中的平台默认编码遇到。

这一切都是一团糟，这正是开发 Unicode 的原因。但是混乱还没有消失，我们仍然需要处理它，并且不应该对要解释为文本的给定字节串的编码做出任何假设。There Ain't No Such Thing as Plain Text。

【讨论】：

迈克尔，你说得太对了，让我泪流满面。这是一场灾难，以至于我什至考虑对标准库进行猴子修补以禁止“默认编码”。我有 TB 的语料库被这个问题无法修复地破坏了。这里的问题是不合理的 Java 默认值，而不是 Java 本身，它当然可以处理它。我不知道如何系统地修复它，因为从一开始到结束都与错误兼容似乎是 Java 的操作方式。我不知道如何修复设计缺陷。
问题是你不能“不做任何假设”。用户将编写没有编码指示的纯文本文件。旧系统将存储编码未知的字符串。