什么字符编码最适合跨国公司

Question

如果您有一个网站要翻译成世界上的每种语言，因此拥有一个包含所有这些翻译的数据库，哪种字符编码最好？ UTF-128？

如果是这样，所有浏览器都了解所选的编码？ 字符编码是直接实现还是有隐藏因素？

提前致谢。

Answer 1

如果要支持各种语言的Web内容，则应使用涵盖整个Unicode范围的编码。为此目的的最佳选择是UTF-8。 UTF-8是网络的首选编码;来自the HTML5 draft standard：

  

鼓励作者使用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这样的可变宽度编码的所有缺点，没有大多数优点。

Answer 2

UTF-8是Unicode的事实上的标准字符编码。

  

UTF-8类似于UTF-16和UTF-32，因为它可以表示Unicode字符集中的每个字符。但与UTF-16和UTF-32不同，它具有向后兼容ASCII的优点。它的优点是避免了字节顺序的复杂性以及因此需要使用字节顺序标记（BOM）。由于这些原因和其他原因，UTF-8已成为万维网的主要字符编码，占所有网页的一半以上。

没有UTF-128这样的东西。

Answer 3

处理此问题时需要考虑更多因素。 例如，您可以用UTF-8表示中文，日文和几乎所有内容 - 但是它会为每个这样的“外来”字符使用一组转义字符 - 因此您的数据表示可能需要大量存储，因为这些额外的标记。您也可以查看UTF-16，它不需要中文，日文等的转义/标记 - 但是，每个字符现在需要2个字节来表示;因此，如果您主要处理拉丁字符集，那么您只需将数据存储的大小增加一倍就没有任何好处。还有专门针对日语的shift-jis，它比UTF-8或UTF-16更能代表这些charset，但是你没有支持拉丁字符。 我想说，如果你事先知道你会有很多外国人，可以考虑使用UTF-16;如果你主要处理重音和拉丁字符，请使用UTF-8;如果您不使用任何拉丁字符，请考虑使用shift-jis等。