为什么有人使用UTF-8以外的编码？

Question

我想知道为什么任何开发人员都需要使用UTF-8以外的编码.

Answer 1

维基百科列出了UTF-8与其他各种编码相比的优缺点:

http://en.wikipedia.org/wiki/UTF-8#Advantages_and_disadvantages

最重要的缺点是恕我直言,UTF-8可能会使用更多空间,特别是在亚洲语言中,例如中文,日文或印地文,并且并非所有代码点都具有相同的大小,这使得测量更加困难,并且许多字符串操作(例如搜索效率低).

Answer 2

好吧,有些人这样做是因为他们的工具过时或有缺陷.有些人这样做是因为他们认为不需要支持ASCII以外的任何东西.有些人这样做是因为他们不知道更好.

这些是不使用Unicode的通常借口.

至于不使用UTF-8,有不同的原因.有些系统,比如Windows ¹(以及源自.NET)和Java,正处于Unicode是严格的16位代码的时代.因此,实际上只有一种编码:UCS-2,编码代码直接指向16位字.

后来Unicode扩展到21位,因为65536代码点不再足够了.这会导致出现UTF-32和UTF-16等编码.对于以前使用UCS-2的系统,过渡到UTF-16是最简单和最明智的选择.Windows在Windows 2000的Ye Olde Days中做了这种转变.

因此,虽然我认为现在几乎所有的应用程序都应该支持Unicode,但我认为它们并不是完全有必要专门使用UTF-8.这有历史原因,并且在将现有系统从UTF-16转换为UTF-8方面没有实际好处.

¹ NT.

Answer 3

在UTF-8代码之间0800,UTF-8中FFFF占用三个字节,UTF-16只占两个字节.有关详细信息,请参阅维基百科比较,但基本上如果文本大量使用此范围内的代码点(例如,如果它是中文),则UTF-8文件将大于具有相同内容的UTF-16文件.

Answer 4

UTF-8在编码普通英文文本(与ASCII相同)方面非常有效.如果您的用户群可能主要是中文,那么使用UTF-16会更好.

有关更多信息,请参阅绝对最低每个软件开发人员,绝对必须知道Unicode和字符集.

Answer 5

有时候由于历史/不支持的原因它们受到限制(我在Linux上使用Zend Studio在Linux机器上的Samba共享上进行开发:这种混合意味着我不断恢复到Cp1512而不是UTF8).

有时您不需要使用UTF-8(例如,在数据库中存储md5哈希时:您只需要十六进制范围0-9 AF:为什么要将其设为UTF-8字段,这至少需要一个字节额外的存储而不是普通的ASCII).

有时它只是懒惰学习特定语言的UTF-8函数.

Answer 6

因为他们不知道更好.对utf-8唯一有效的批评是,对于常见的亚洲语言的编码超出了其他编码的范围.UTF-8是优越的,因为

• 它与ASCII兼容.大多数已知和尝试过的字符串操作不需要调整.
• 它是Unicode.任何非Unicode的东西都不应该在这个时代被考虑.如果您在编码X时有重要数据,请在Google上花两分钟编写转换函数.即使您必须与无源遗留应用程序Z接口,您也可以通过管道运行通信,以便您的逻辑保持在21世纪.
• UTF-16也不是固定长度,假设它像许多人那样,只会造成可怕的错误.
• 此外,Unicode非常复杂,几乎可以肯定,任何适用于ASCII的固定大小算法即使在UTF-32中也会产生不良结果.

假设你有这个UTF-16字符串.

[0][1][2][F|3] [4] [5]

并且你想在[3]和[4]之间插入一个代码为8的字符,你会插入(5,8)

如果你没有检查BMP之外的字符(顺序为UTF-8,因为你不知道你有多少双字符),你会得到:

[0][1][2][F|8][3][4][5]

两个新的垃圾字符.非常适合您的固定大小编码.您当然可以完全禁止这些字符,但是当您的代码与现实世界接口时,您可能会发现您的程序为生活在rm -Rf/in .profile而不是[Classical Chinese Proverb] .profile的用户保存配置文件. .

或者只是一个愤怒的用户,无法用你的软件在古典中国谚语上写下他的论文.

Answer 7

因为在英语世界之外,人们一直在使用早于Unicode的各种编码,并且几十年来都为各自的语言量身定制.这些特定于语言的编码已经在各地根深蒂固,几乎是一个标准.如果您希望与遗留系统接口,则必须使用它们,因此所有系统都必须支持它们并且通常将它们用作默认值,即使它们现在也支持UTF-8.甚至可能存在传统上用于不同目的的多种遗留编码.

例子:

• 西欧的ISO-8859-1 - 实际上已经过时了,因为欧洲标志需要ISO-8859-15
• 日本的ISO-2022-JP用于电子邮件,Shift JIS用于网站
• Big5在台湾
• GB2312在中国

最后两个例子表明,编码甚至可能是一个政治问题.