HGP*_*GPB 15 utf-8 utf-16 character-encoding utf-32
如果你有一个网站要翻译成世界上的每种语言,因此有一个包含所有这些翻译的数据库,哪种字符编码最好？UTF-128？
如果是这样,所有浏览器都了解所选的编码？字符编码是直接实现还是有隐藏因素？
提前致谢.
Bri*_*ell 31
如果要支持Web内容的各种语言,则应使用涵盖整个Unicode范围的编码.为此目的的最佳选择是UTF-8.UTF-8是网络的首选编码; 来自HTML5草案标准:
鼓励作者使用UTF-8.一致性检查员可能会建议作者不要使用遗留编码.[RFC3629]
创作工具应默认使用UTF-8来创建新创建的文档.[RFC3629]
UTF-8和Windows-1252是浏览器需要支持的唯一编码,UTF-8和UTF-16是XML解析器支持的唯一编码.因此,UTF-8是唯一需要支持所有内容的通用编码.
以下是对Liv答案的扩展回应,而不是对答案的回应; 它描述了为什么UTF-8优于UTF-16,即使对于CJK内容也是如此.
对于ASCII范围内的字符,UTF-8比UTF-16更紧凑(1字节对2).对于ASCII范围和U + 07FF(包括拉丁语扩展,西里尔语,希腊语,阿拉伯语和希伯来语)之间的字符,UTF-8每个字符也使用两个字节,因此它是一个清洗.对于Basic Multilingual Plane之外的字符,UTF-8和UTF-16每个字符使用4个字节,所以它在那里是一个清洗.
UTF-16比UTF-8更有效的唯一范围是从U + 07FF到U + FFFF的字符,其中包括印度语字母和CJK.即使对于该范围内的大量文本,UTF-8最终也具有可比性,因为该文本的标记(HTML,XML,RTF,或者你有什么)都在ASCII范围内,其中UTF-8是一半UTF-16的大小.
例如,如果我选择日语中的随机网页,即nhk.or.jp的主页,则以UTF-8编码.如果我将其转码为UTF-16,它将增长到原始大小的两倍:
$ curl -o nhk.html 'http://www.nhk.or.jp/' $ iconv -f UTF-8 -t UTF-16 nhk.html > nhk.16.html $ ls -al nhk* -rw-r--r-- 1 lambda lambda 32416 Mar 13 13:06 nhk.16.html -rw-r--r-- 1 lambda lambda 18337 Mar 13 13:04 nhk.html
UTF-8几乎在所有方面都比UTF-16更好.它们都是可变宽度编码,因此具有复杂性.然而,在UTF-16中,4字节字符是相当罕见的,因此更容易做出固定宽度假设并使一切正常工作,直到遇到你没有捕到的角落情况.在编码CESU-8中可以看到这种混淆的一个例子,如果您将UTF-16文本转换为UTF-8,只需将代理对的每一半编码为单独的字符(每个字符使用6个字节) ;三个字节用于编码UTF-8中代理对的每一半),而不是将该对解码为其代码点并将其编码为UTF-8.这种混淆很常见,错误的编码实际上已经标准化,因此至少可以使破坏的程序进行互操作.
对于绝大多数内容,UTF-8比UTF-16小得多,如果您关注大小,压缩文本总是比选择不同的编码更好.UTF-8与使用以null结尾的字节序列来表示字符串的API和数据结构兼容,因此只要您的API和数据结构不关心编码或者已经可以处理其字符串中的不同编码(例如作为大多数C和POSIX字符串处理API),UTF-8可以正常工作,而无需为宽字符设置全新的API和数据结构.UTF-16没有指定字节序,因此它可以处理字节序问题; 实际上有三种不同的相关编码,UTF-16,UTF-16BE和UTF-16LE.UTF-16可以是大端或小端,因此需要BOM指定.UTF-16BE和LE是big和little endian版本,没有BOM,所以你需要使用带外方法(例如Content-Type HTTP标头)来指示你正在使用哪一个,但是带状头部因错误或缺失而臭名昭着.
UTF-16基本上是一个意外,因为人们认为16位足以对所有Unicode进行编码,因此开始改变它们的表示和API以使用宽(16位)字符.当他们意识到他们需要更多字符时,他们想出了一个使用一些保留字符来使用两个代码单元编码32位值的方案,因此他们仍然可以使用相同的数据结构进行新编码.这带来了像UTF-8这样的可变宽度编码的所有缺点,没有大多数优点.
| 归档时间： |
|
| 查看次数： |
13229 次 |
| 最近记录： |