例如，类文件使用CESU-8（有时也称为MUTF-8），但内部Java首先使用UCS-2，现在它使用UTF-16。关于有效Java源文件的规范说，最小符合标准的Java编译器只需要接受ASCII字符。
这些选择的原因是什么？在整个Java生态系统中使用相同的编码会不会更有意义？
答案 0 :(得分：4)
MUTF-8用于提高效率，UCS2用于歇斯底里的葡萄干。 ：）
1993年，UCS2 是 Unicode;每个人都认为每个人都应该拥有65536个字符。
后来，当很明显，世界上有很多语言时，将'char'重新定义为32位，为时已晚，更不用说一个可怕的想法了 - 向后兼容的选择。
与ASCII和UTF-8之间的关系非常类似，不偏离历史UCS2边界的Java字符串与它们的UTF16表示位相同。只有当你在那些线之外着色时，你必须开始担心代理人等等。
答案 1 :(得分：4)
源文件的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代码单元。
答案 2 :(得分：2)
这似乎是一个常见的软件开发问题。早期代码是一种标准，通常在创建时最简单，然后更高版本增加了对更新/更好/更不常见/更复杂标准的支持。
最小编译器可能只需要使用ASCII，因为这是许多常见编辑器使用的。这些编辑器可能不适合使用Java而不是完整的IDE，但通常足以调整一个源文件。
Java似乎试图将条形设置得更高并处理UTF字符集，但它们也保留了ASCII“救助”选项。我确信委员会会议上有一些说明可以解释原因。