如果我们有代理项对,为什么要使用UTF-32而不是UTF-16?

在UTF-32中,unicode字符始终由4个字节表示,因此解析代码比UTF-16字符串更容易编写,因为在UTF-16中,字符由不同数量的字节表示。在不利的方面,UTF-32聊天机器人会 需要4个字节,如果您主要使用英语字符,这可能会造成浪费。因此,它是一种设计选择,取决于您的需求是使用UTF-16还是UTF-32。

有些人可能更喜欢处理UTF-32而不是UTF-16,因为处理代理项对几乎总是处理“特殊情况”,而必须处理这些特殊情况意味着您有可能因为错误地处理它们而出现bug(或者更可能是忘记处理它们)。

Comparison of the Advantages of UTF-32, UTF-16, and UTF-8

版权所有19912009 Unicode,Inc.Unicode标准,版本5.2

wchar_t ,这意味着这些编程语言可以提供内置支持和现成的字符串API,程序员可以利用这些API。然而,UTF-16具有许多抵消优势,这可能导致实现者选择它作为内部处理代码。

UTF-32和UTF-16。 平均而言,超过99%的所有UTF-16数据使用单代码单元表示。这几乎包括软件需要处理的所有文本特殊操作的典型字符,例如,格式控制字符。因此,大多数文本扫描操作根本不需要解压缩UTF-16代理项对,而是可以安全地将它们视为字符串的不透明部分。 对于许多操作,UTF-16与UTF-32一样易于处理,而且UTF-16作为处理代码的性能往往相当好。UTF-16是大多数支持Unicode的实现所选择的内部处理代码。除了Unix平台,UTF-16提供了紧凑大小的正确组合,并能够处理BMP之外的偶然字符。 UTF-32在简化软件编码设计和维护方面有一定的优势。由于字符处理是固定宽度的,UTF-32处理不需要在软件中维护分支来测试和处理UTF-16补充字符所需的双代码单元元素。相反,大表中的32位索引并不是特别高效的内存。为了避免此类索引带来的大量内存损失,Unicode表通常作为多级表处理(请参阅第5.1节“转换到其他标准的代码”中的多级表)。在这种情况下,32位代码点值被分割成更小的范围,以允许分段访问表。即使在典型的UTF-32实现中也是如此。 对于相同的数据,UTF-32作为处理代码的性能实际上可能比UTF-16的性能差,因为额外的内存开销意味着缓存限制将被更频繁地超过,内存分页将更频繁地发生。对于处理器设计对16位对齐访问施加惩罚但内存非常大的系统,这种影响可能不太明显。 UTF-8。就使用的字节数而言,UTF-8相当紧凑。在东亚地区,如汉语、日语和韩语,它使用汉字或韩国语音节,需要UTF-8中的三字节代码单元序列,因此,它实际上只在尺寸上处于明显劣势。UTF-8的处理效率也明显低于其他编码形式。 二进制排序。UTF-8字符串的二进制排序与Unicode代码点的二进制排序具有相同的顺序。这显然与二进制UTF-32字符串的顺序相同。

总体结构

当仅处理BMP字符(范围为U+0000..U+FFFF)时,所有三种编码形式对二进制字符串比较或字符串排序给出相同的结果。但是,在处理补充字符(范围为U+10000..U+10FFFF)时,UTF-16二进制顺序与Unicode码点顺序不匹配。例如,在UTF-16系统和UTF-8或UTF-32系统之间尝试与二进制排序列表进行互操作时,这可能会导致复杂性。但是,对于根据特定语言或区域设置的约定而不是使用二进制顺序排序的数据,无论编码形式如何,数据的顺序都是相同的。

简短回答:没有。

不那么讽刺的回答:当您更关心索引的速度而不是空间使用,或者作为某种中间格式,或者在对齐问题比缓存问题更重要的机器上,或者。。。

如果你的文字是 主要地 在英语中,使用utf-8可以节省大量空间,但索引字符不是O(1),因为有些字符占用的空间超过一个字节。

对于非英语文本,UTF-16可能比UTF-8更好,因为在UTF-8中,有些字符占用3个字节,而在utf16中,它们只占用2个字节。

使用UTF-32,您知道每个字符有4个字节。使用UTF-16,您不知道任何特定字符的长度。

char getChar(int index, String s );

如果您使用的是具有直接内存访问功能的语言(例如C),那么在UTF-32中,此函数可能与一些指针算术一样简单( s+(4*index) ),这将是O(1)的一些量。

但是,如果您使用的是UTF-16,则必须遍历字符串,边走边解码,即O(n)。

通常,您只需使用底层平台的字符串数据类型/编码,通常是(Windows、Java、Cocoa…)UTF-16,有时是UTF-8或UTF-32。这主要是出于历史原因,;这三种Unicode编码之间几乎没有什么区别:这三种编码都定义良好、快速且健壮,并且都可以对每个Unicode码点序列进行编码。UTF-32的独特特性是固定宽度编码(意味着每个代码点由一个代码单元表示)在实践中几乎没有用处:内存管理层需要了解代码单元的数量和宽度,用户对抽象字符和图形感兴趣。正如Unicode标准所提到的,Unicode应用程序无论如何都必须处理组合字符、连字等,代理项对的处理,尽管在概念上不同,但可以在相同的技术框架内完成。