为什么UTF-32存在而每个字符只需要21位?

Ser*_*gey 24 unicode encoding

我们知道代码点可以在0..10FFFF的这个区间内,小于2 ^ 21.那么为什么我们需要UTF-32才能用3个字节表示所有代码点?UTF-24应该足够了.

Jon*_*eet 21

我能想到的两个原因:

  • 它允许未来扩展
  • (更重要的是)计算机通常在处理4字节边界上的数据方面要好得多.与在3字节边界上工作的痛苦相比,减少内存消耗的好处相对较小.

我想这有点像问为什么我们经常有8位,16位,32位和64位整数数据类型(字节,整数,长整数等)但不是24位整数数据类型.我确信在很多场合我们都知道数字永远不会超过2 21,但使用它int比创建24位类型更简单.

  • 要扩展到21位以上,我们需要一个新的'UTF-16兼容'编码.或者我们只是放弃UTF-16.我不介意,但所有将Unicode视为UTF-16同义词的应用程序,库和系统可能都不会高兴. (5认同)
  • 将3个代码点填充到64位整数中怎么样?3个21位数字完全适合64位整数(有符号或无符号). (3认同)
  • @ColeJohnson:这样可行,但直到我们发现21位还不够......并且在需要位移等方面它仍然不易处理.但在某些情况下它可能是一个有用的实现. (3认同)

Ant*_*ala 6

首先,有两种字符编码方案:UCS-4将每个字符编码为32位,为0x00000000-0x7FFFFFFF范围内的无符号整数,以及UCS-2对每个代码点使用16位。

后来发现,仅使用UCS-2的65536个代码点无论如何都会遇到问题,但是许多程序(Windows,cough)依赖于16位宽的宽字符,因此创建了UTF-16。UTF-16编码范围内的代码点U+0000- U+FFFF就像UCS-2;和U+10000- U+10FFFF使用代理对,即一对两个16位的值。

由于这有点复杂,因此引入了UTF-32,它是超越字符的简单一对一映射U+FFFF。现在,由于UTF-16最多只能编码U+10FFFF,因此已决定这将是将要分配的最大值,这样就不会再出现兼容性问题,因此UTF-32实际上仅使用21位。作为额外的好处,最初计划为1-6字节编码的UTF-8现在每个代码点不再需要超过4字节。因此,它可以很容易地证明,它永远需要比UTF-32更多的存储空间。

假设UTF-24格式确实可以节省内存。但是,无论如何,它的节省还是令人怀疑的,因为它比UTF-8消耗更多的存储空间,除了表情符号之类的爆炸声之外-并没有很多有趣的长度很大的文字完全由表情符号组成。

但是,UTF-32用作需要简单索引到代码点的程序中的文本的内存表示形式-这是C数组中第N个元素也是第N个代码点的唯一编码-UTF-24可以相同,可节省25%的内存,但元素访问更为复杂。