为什么 Java 字符使用 UTF-16？

Question

最近我阅读了很多关于 Unicode 代码点以及它们如何随着时间的推移而演变的内容，并且确定我也阅读了http://www.joelonsoftware.com/articles/Unicode.html 。

但我找不到真正的原因是为什么 Java 使用 UTF-16 作为字符。

例如，如果我有包含 1024 个字母的 ASCII 范围字符串的字符串。 这意味着1024 * 2 bytes等于 2KB 字符串内存，它将以任何方式消耗。

因此，如果 Java 基本字符是 UTF-8，那么它只是 1KB 的数据。 即使字符串中有任何需要 2 个字节的字符，例如 10 个字符的“字”，自然会增加内存消耗的大小。 (1014 * 1 byte) + (10 * 2 bytes) = 1KB + 20 bytes

结果不是那么明显的1KB + 20 bytes VS. 2KB 1KB + 20 bytes VS. 2KB我不说 ASCII，但我对此的好奇心是为什么它不是 UTF-8，它也只处理多字节字符。 UTF-16 看起来像是在任何具有大量非多字节字符的字符串中浪费内存。

这背后有什么好的理由吗？

Answer 1

Java 在2004/2005过渡到 UTF-16 之前使用了UCS-2 。 当初选择UCS-2的原因主要是历史原因：

Unicode 最初设计为固定宽度的 16 位字符编码。 Java 编程语言中的原始数据类型 char 旨在通过提供一种可以容纳任何字符的简单数据类型来利用这种设计。

Unicode FAQ 页面进一步解释了这一点以及 UTF-16 的诞生：

最初，Unicode 被设计为纯 16 位编码，旨在代表所有现代文字。 （古代文字将用专用字符表示。）随着时间的推移，尤其是在添加了超过 14,500 个复合字符以与遗留集兼容之后，很明显 16 位对于用户社区来说是不够的。 由此产生了 UTF-16。

正如@wero已经提到的，使用 UTF-8 无法有效地进行随机访问。 所以综合权衡之后，UCS-2 似乎是当时最好的选择，尤其是在那个阶段没有分配补充字符的情况下。 这让 UTF-16 成为最简单的自然发展。

Answer 2

原因之一是随机访问或迭代字符串字符的性能特征：

UTF-8 编码使用可变数量 (1-4) 字节来编码 unicode 字符。 因此，通过索引访问字符： String.charAt(i)比java.lang.String使用的数组访问实现起来更复杂，速度也更慢。