Java为什么要使用UTF-16来表示内部字符串？

我可以想象原因是速度很快，就像访问索引中的字符一样，但是有些字符无法容纳16位，所以它不起作用...

因此，如果仍然要处理特殊情况，为什么不只使用UTF-8？

java strings unicode

— Mrpyo
source

有人问Java设计师，而不是整个社区。投票决定关闭不具有建设性。

— 奥德

@Oded：绝对没有必要，正如DeadMG的答案所示。

— Michael Borgwardt 2012年

我很困惑：我很确定这个问题已经回答了（无论是在这里还是在SO上），但我找不到重复的问题。

— 约阿希姆·绍尔

用于歇斯底里的葡萄干。参见utf8everywhere.org

— Pavel Radzivilovsky '16

Answers:

因为它曾经是UCS-2，所以它是一个不错的固定长度16位。当然，事实证明16bit还不够。他们在顶部改装了UTF-16。

— 死神MG
source

以下是Unicode FAQ的引文：

Originally, Unicode was designed as a pure 16-bit encoding, aimed at representing all modern scripts. (Ancient scripts were to be represented with private-use characters.) Over time, and especially after the addition of over 14,500 composite characters for compatibility with legacy sets, it became clear that 16-bits were not sufficient for the user community. Out of this arose UTF-16.

在Java发行之时，尚未出现UTF-16，并且UTF-8尚未成为Unicode标准的一部分。

— 马尔科姆

UCS-2是一个技术术语，而不是流行语。

— DeadMG

对于主要部分，为了简单明了地面向未来。这是否是被误导的原因和错误的解决方法是另一个问题。

您可以在本文档中看到有关2004年改用Java 5和UTF-16的一些设计决策背后的一些原因，这些原因也解释了一些缺点：Java平台中的补充字符，并了解为什么使用Java生态系统整个堆栈有不同的编码？。

有关使用UTF-16的陷阱的更多详细信息，以及为什么一般而言UTF-8可能是更好的选择，请参阅是否应将UTF-16视为有害？和UTF-8 Everywhere宣言。

— 海姆
source

+1链接到“应该认为UTF-16有害吗？” 题。我最近发现了UTF-8 Everywhere宣言，我相信我现在已经完全确信了。就其价值而言，尽管Java弄错了，但我坚信Windows的表现要差得多。

— 丹尼尔·普里登

嗯，Windows 犯了更多错误并不奇怪：他们更早地转向Unicode，因此他们的正确选择和经验较少。Java后来有了，它变得更正确了，但还是有些错误。现在，两者都必须使用它们必须继续支持的旧的，普遍意义不正确的API。

— 约阿希姆·绍尔

这就是软件世界中的生活，您必须在没有所有数据的情况下做出选择，并且当您输入错误时，您将长期承受后果。:-)

— Brian Knoblauch 2012年

我不知道string在Java 中创建“特殊”类型（很像Array）会带来什么性能影响，而不是String成为一个包含对包含实际字符的“普通”数组的引用的“普通”类。根据生成字符串的方式，UTF-8，UTF-16甚至UTF-32可能是存储它的最有效方法。我认为“普通”类没有任何特别有效的方法String来处理多种格式，但是带有JVM支持的“特殊”类型可以。

— 超级猫

@supercat：我没有确切的答案，但是我有一个相关的答案。:)并没有真正解决特殊类型方法，而是讨论了简化字符串的潜在收益。

— haylem