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

EN

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“，更糟糕的是，”char“数据类型现在有点命名错误(它通常不再对应于一个字符，而是对应于一个UTF-16代码单元)。

MUTF-8代表效率，UCS2代表歇斯底里的葡萄干。:)

1993年，UCS2是Unicode；每个人都认为65536个字符对每个人来说都应该足够了。

后来，当人们意识到世界上确实有非常多的语言时，为时已晚，更不用说一个可怕的想法了，要将“char”重新定义为32位，因此做出了一个主要是向后兼容的选择。

在某种程度上，与ASCII语言和UTF8之间的关系非常相似，不会偏离历史UCS2边界的Java字符串与它们的UTF16表示形式完全相同。只有当你在这些线之外着色时，你才会开始担心代理，等等。

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

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

Java似乎试图设置更高的门槛和处理UTF字符集，但他们也保留了ASCII 'bailout‘选项。我相信一定会有一些委员会会议的笔记来解释原因。