我们知道代码点可以在0..10FFFF的这个区间内,小于2 ^ 21.那么为什么我们需要UTF-32才能用3个字节表示所有代码点?UTF-24应该足够了.
Jon*_*eet 21
我能想到的两个原因:
我想这有点像问为什么我们经常有8位,16位,32位和64位整数数据类型(字节,整数,长整数等)但不是24位整数数据类型.我确信在很多场合我们都知道数字永远不会超过2 21,但使用它int比创建24位类型更简单.
首先,有两种字符编码方案: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%的内存,但元素访问更为复杂。
| 归档时间: |
|
| 查看次数: |
3749 次 |
| 最近记录: |