有没有理由比UTF-8更喜欢UTF-16？

Question

检查UTF-16和UTF-8的属性,我找不到任何理由更喜欢UTF-16.

但是,检查Java和C#,它看起来像字符串和字符默认为UTF-16.我认为这可能是出于历史原因,或者出于性能原因,但无法找到任何信息.

谁知道为什么这些语言选择了UTF-16？我也有正当理由这么做吗？

编辑:同时我也找到了这个答案,这似乎是相关的,并有一些有趣的链接.

Answer 1

与UTF-8(通常需要3个字节)相比,东亚语言通常需要较少的UTF-16存储空间(2个字节足以满足99%的东亚语言字符).

当然,对于西方联盟,UTF-8通常较小(1字节而不是2字节).对于像HTML这样的混合文件(那里有很多标记),这非常多.

为用户模式应用程序处理UTF-16 比处理UTF-8 稍微容易一些,因为代理对的行为几乎与组合字符的行为相同.因此,UTF-16通常可以作为固定大小的编码进行处理.

Answer 2

@Oak:这个评论太长了......

我不知道C#(并且会非常惊讶:这意味着他们只是过多地复制了Java )但是对于Java来说它很简单:Java是在Unicode 3.1出现之前构思出来的.

因此,少于65537个代码点,因此每个Unicode代码点仍然适合16位,因此Java char诞生了.

当然,这导致了今天仍在影响着Java程序员(像我)疯了的问题,那就是你有一个方法的charAt这在某些情况下,不会返回既不是Unicode字符,也没有一个Unicode码点和方法(Java 5中添加)提供codePointAt其中采用的参数不是您想要跳过的代码点数量!(您必须向codePointAt提供要跳过的Java char的数量,这使它成为String类中最不易理解的方法之一).

所以,是的,这绝对是令人困惑的大多数Java程序员(大多数甚至都不知道这些问题),并且,是的,这是出于历史原因.至少,这是人们在这个问题之后生气的原因:但是因为Unicode 3.1还没有出来.

:)

Answer 3

我想使用UTF-16的C#派生自内部使用UTF-16的Windows NT系列操作系统.

我想Windows NT在内部使用UTF-16有两个主要原因:

• 对于内存使用:UTF-32浪费了 大量空间进行编码.
• 性能方面:UTF-8比UTF-16更难解码.在UTF-16中,字符是基本多语言平面字符(2个字节)或代理项对(4个字节).UTF-8字符可以是1到4个字节之间的任何位置.

与其他人的回答相反 - 你不能将UTF-16视为UCS-2.如果要正确迭代字符串中的实际字符,则必须使用对unicode友好的迭代函数.例如在C#中你需要使用StringInfo.GetTextElementEnumerator().

有关详细信息,请参阅维基上的此页面:http://en.wikipedia.org/wiki/Comparison_of_Unicode_encodings