是否有任何理由不为所有内容使用 UTF-8、16 等？答案

【问题标题】：Is there any reason not to use UTF-8, 16, etc. for everything?是否有任何理由不为所有内容使用 UTF-8、16 等？
【发布时间】：2011-06-09 11:46:35
【问题描述】：

我知道最近网络主要是标准化为 UTF-8，我只是想知道是否有任何地方使用 UTF-8 会是一件坏事。我听说 UTF-8、16 等可能会占用更多空间，但最终它可以忽略不计。

另外，在 Windows 程序、Linux shell 和类似的东西中，你可以安全地使用 UTF-8 吗？

【问题讨论】：

对于不支持 UTF-8 的现有协议，这是不使用 UTF-8 的一个很好的理由 :) 我个人只喜欢支持 UTF-8 编码，因为它允许 unicode 字符同时允许我的生活围绕着 ASCII 字符空间（在“愚蠢”的编辑器中打开 UTF-16 内容让我眼花缭乱）。
@pst: B e c a u s e i t l o o k s l i k e t h i s ?

标签： character-encoding utf

【解决方案1】：

众所周知，utf-8 最适合文件存储和网络传输。但人们争论 utf-16/32 是否更适合处理。一个主要论点是 utf-16 仍然是可变长度的，甚至 utf-32 仍然不是每个字符一个代码点，那么它们比 utf-8 好在哪里？我的观点是 utf-16 是一个非常好的折衷方案。

首先，需要在 utf-16 中使用双代码点的 BMP 之外的字符是极少使用的。该范围内的汉字（以及其他一些亚洲字符）基本上是死的。普通人根本不会用，除非专家用它来数字化古籍。所以，utf-32 大部分时间都是浪费。不要太担心这些字符，因为如果您没有正确处理它们，它们不会让您的软件看起来很糟糕，只要您的软件不适合那些特殊用户。

其次，我们通常需要将字符串内存分配与字符数相关联。例如10 个字符的数据库字符串列（假设我们以标准化形式存储 unicode 字符串），对于 utf-16 将是 20 个字节。在大多数情况下，它会像那样工作，除非在极端情况下它只能容纳 5-8 个字符。但是对于 utf-8，一个字符的公共字节长度对于西方语言是 1-3，对于亚洲语言是 3-5。这意味着即使在常见情况下我们也需要 10-50 个字节。更多数据，更多处理。

【讨论】：

我不同意“不要太担心这些字符，因为如果你没有正确处理它们，它们不会让你的软件看起来很糟糕”。当你的意思是“我的程序使用/支持 UTF-16 的一个子集”时说“我的程序使用/支持 UTF-16”要么是虚伪的，要么是彻头彻尾的谎言。错误是一回事。故意不支持整个 UTF-16 不是错误。

【解决方案2】：

如果 UTF-32 可用，则首选使用 UTF-32 进行处理。

如果您的平台本身支持 UTF-32/UCS-4 Unicode - 那么“压缩”版本 UTF-8 和 UTF-16 可能会更慢，因为它们为每个字符（字符序列）使用不同数量的字节，这无法通过索引直接查找字符串，而 UTF-32 对每个字符使用 32 位“平面”，大大加快了一些字符串操作。

当然，如果您在非常受限的环境（例如嵌入式系统）中进行编程，并且可以确定周围只有 ASCII 或 ISO 8859-x 字符，永远，那么您可以选择这些字符集是为了提高效率和速度。但总的来说，请坚持 Unicode 转换格式。

【讨论】：

对于相同的数据，UTF-32 占用 ASCII（或 UTF-8 编码 ASCII 字符时）的 4 倍空间。这绝对很重要。此外，与 ISO-8859-* 等“传统”字符集不同（与 UTF-8 不同），UTF-32 和 UTF-16 存在字节顺序问题。
"UTF-32 (or UCS-4) is a protocol for encoding Unicode characters that uses exactly 32 bits for each Unicode code point. All other Unicode transformation formats use variable-length encodings. The UTF-32 form of a character is a direct representation of its codepoint."
@dkarp：这就是我在第一句话中写“用于处理”的原因。对于存储，您可能需要考虑存储格式或压缩，具体取决于环境、组件的速度、访问字符串的频率和其他因素。很少只针对一个因素进行优化。 -- 但正如我所写，主要因素是平台支持。例如，我上次查看时，Windows 在内部使用 UTF-16，因此最好使用 UTF-16，将字符串操作优化留给平台/库提供程序。
@foo 对不起，我不买。如果您不想以 UTF-32 进行输入，又不想以 UTF-32 进行输出，又不想将臃肿的 UTF-32 字符串存储在内存中，那有什么好处呢？ UTF-32 甚至不是每 32 位一个字符/字素，它是每 32 位一个 code point。 Combining characters, canonical equivalence, joy. 很少有平台和应用程序使用 UTF-32 是有原因的——收益通常不会超过成本。
@dkarp：您对代码点和字符之间的区别是正确的；然而，不同运行长度的问题仍然存在，包括缓存/访问速度方面。所以有有点赞成和反对。从 UTF-8/8-Bit-charset 的角度来看，您也可以将 UTF-16 称为“臃肿”；然而，许多平台制造商决定采用它，可能在这里看到了最佳的权衡平衡——Java 现在做到了，Windows 现在做到了，Mac OS 做到了，Qt 可能还有更多使用 UTF-16。（显然接受字节顺序处理的必要性）。

【解决方案3】：

当您需要编写一个程序（执行字符串操作），该程序需要非常非常快并且您确定不需要外来字符时，UTF-8 可能不是最好的主意。在所有其他情况下，UTF-8 应该是一个标准。

UTF-8 适用于几乎所有最新的软件，甚至在 Windows 上。

【讨论】：

嗯，你可以在 Windows 上编写基于 UTF-8 的软件（我已经做到了），但你必须避免使用像 fopen 这样的函数ANSI" 字符串 :-(
什么？开？用什么语言？我是否说过不可能在基于 UTF-8 的 Windows 上编写软件？我不明白你的意思。或者也许有人删除了他的评论。