最近我读了很多关于unicode代码点以及它们如何随着时间的推移而演变的事情，并确定我也阅读了http://www.joelonsoftware.com/articles/Unicode.html。
但是我无法找到Java使用UTF-16作为char的真正原因。
例如，如果我的字符串包含1024个字母的ASCII范围字符串字符串。这意味着1024 * 2 bytes等于它将消耗的2KB字符串内存。
因此，如果Java base char是UTF-8，那么它只有1KB的数据。即使字符串具有任何需要2字节的字符串，例如10字符“字符”自然也会增加内存消耗的大小。 (1014 * 1 byte) + (10 * 2 bytes) = 1KB + 20 bytes
结果不是那么明显1KB + 20 bytes VS. 2KB我没有谈到ASCII，但我对此的好奇心是为什么它不是UTF-8，它只是照顾多字节字符。 UTF-16在任何具有大量非多字节字符的字符串中看起来像浪费内存。
这背后有什么好理由吗？
答案 0 :(得分：27)
在UCS-2中通过UTF-16转换之前，Java使用了2004/2005。原始选择UCS-2的原因是mainly historical：
Unicode最初设计为固定宽度的16位字符编码。 Java编程语言中的原始数据类型char旨在通过提供可以保存任何字符的简单数据类型来利用此设计。
这和UTF-16的诞生进一步explained by the Unicode FAQ page：
最初，Unicode被设计为纯16位编码，旨在表示所有现代脚本。 （古代脚本用私有字符表示。）随着时间的推移，特别是在添加了超过14,500个复合字符以便与传统集合兼容之后，很明显16位对用户社区来说还不够。出现了这个出现的UTF-16。
由于@wero有already mentioned，使用UTF-8无法有效地进行随机访问。所有事情都在衡量，UCS-2似乎是当时最好的选择，特别是因为那个阶段没有分配补充字符。然后将UTF-16作为最简单的自然进展。
答案 1 :(得分：-2)
一个原因是随机访问或迭代字符串字符的性能特征：
UTF-8编码使用可变数（1-4）字节来编码unicode char。因此，通过索引访问字符：String.charAt(i)实现起来会更复杂，并且比java.lang.String使用的数组访问速度慢。