为什么Java生态系统在其软件堆栈中使用不同的字符编码？

例如，类文件使用CESU-8（有时也称为MUTF-8），但内部Java首先使用UCS-2，现在它使用UTF-16。 有关有效Java源文件的规范说，最小符合标准的Java编译器只需要接受ASCII字符。

这些选择的原因是什么？ 在整个Java生态系统中使用相同的编码会不会更有意义？

Answer 1

源文件的ASCII是因为当时人们认为文本编辑器具有完全的Unicode支持是不合理的。 事情有所改善，但它们仍然不完美。 Jave中的整个\uXXXX本质上是Java等同于C的三字符。 （当创建C时，某些键盘没有花括号，所以你必须使用三字母！）

在创建Java时，类文件格式使用UTF-8，运行时使用UCS-2。 Unicode的代码点少于64k，因此16位就足够了。 之后，当在Unicode中添加了额外的“平面”时，UCS-2被替换为（几乎）兼容的UTF-16，并且UTF-8被替换为CESU-8（因此“兼容性编码方案……”）。

在类文件格式中，他们希望使用UTF-8来节省空间。 类文件格式（包括JVM指令集）的设计主要针对紧凑性。

在运行时，他们想要使用UCS-2，因为有人认为节省空间不如能够避免处理可变宽度字符的需要。 不幸的是，这种情况因为它是UTF-16而适得其反，因为代码点现在可以采用多个“字符”，更糟糕的是，“char”数据类型现在有点错误名称（它通常不再对应于字符，但是而是对应于UTF-16代码单元）。

Answer 2

MUTF-8用于效率，UCS2用于歇斯底里的葡萄干。 🙂

1993年，UCS2 是 Unicode; 每个人都认为每个人都应该拥有65536个字符。

后来，当很明显，世界上确实有很多语言时，为了将’char’重新定义为32位，为时已晚，更不用说一个可怕的想法，所以反而大多是向后 – 兼容的选择。

在与ASCII和UTF-8之间的关系非常类似的方式中，不在历史UCS2边界之外的Java字符串与它们的UTF16表示相同。 只有当你在那些线条之外着色时，你必须开始担心代理人等。

Answer 3

这似乎是一个常见的软件开发问题。 早期代码是一种标准，通常在创建时最简单，然后更高版本添加对更新/更好/更不常见/更复杂标准的支持。

最小编译器可能只需要使用ASCII，因为这是许多常见编辑器使用的。 这些编辑器可能不适合使用Java而不是完整的IDE，但通常足以调整一个源文件。

Java似乎试图将条形设置得更高并处理UTF字符集，但它们也保留了ASCII’救助’选项。 我确信某些委员会会议的说明可以解释原因。