有什么理由比 UTF-8 更喜欢 UTF-16？

Question

检查 UTF-16 和 UTF-8 的属性，我找不到任何更喜欢 UTF-16 的理由。

但是，检查 Java 和 C#，它看起来像那里的字符串和字符默认为 UTF-16。 我在想这可能是出于历史原因，也可能是出于性能原因，但找不到任何信息。

有谁知道为什么这些语言选择 UTF-16？ 我是否也有任何正当理由这样做？

编辑：同时，我也找到了这个答案，它似乎相关并且有一些有趣的链接。

Answer 1

与 UTF-8（通常需要 3 个字节）相比，东亚语言通常需要更少的 UTF-16 存储空间（2 个字节足以容纳 99% 的东亚语言字符）。

当然，对于西方语言，UTF-8 通常更小（1 个字节而不是 2 个字节）。 对于像 HTML 这样的混合文件（其中有很多标记），这是非常多的。

处理用户模式应用程序的 UTF-16 比处理 UTF-8稍微容易一些，因为代理对的行为方式与组合字符的行为方式几乎相同。 所以UTF-16通常可以作为固定大小的编码来处理。

Answer 2

@Oak：评论太长了...

我不了解 C#（我真的很惊讶：这意味着他们只是过多地复制了 Java）但是对于 Java 来说很简单：Java 是在 Unicode 3.1 出现之前构思出来的。

因此只有不到 65537 个代码点，因此每个 Unicode 代码点仍然适合 16 位，因此 Java字符诞生了。

当然，这导致了今天仍然影响 Java 程序员（如我）的疯狂问题，其中有一个方法charAt在某些情况下既不返回 Unicode 字符也不返回 Unicode 代码点和一个方法（在 Java 5 中添加） codePointAt接受一个参数，它不是您想要跳过的代码点数！ （您必须向codePointAt提供要跳过的 Java字符数，这使其成为 String 类中最难理解的方法之一）。

所以，是的，这绝对是大多数 Java 程序员的疯狂和困惑（大多数人甚至不知道这些问题），是的，这是历史原因。 至少，这是人们在这个问题后生气时想出的借口：但这是因为 Unicode 3.1 还没有出来。

:)

Answer 3

我想象使用 UTF-16 的 C# 派生自在内部使用 UTF-16 的 Windows NT 操作系统系列。

我想 Windows NT 在内部使用 UTF-16 有两个主要原因：

• 对于内存使用：UTF-32 浪费大量空间进行编码。
• 对于性能：UTF-8 比 UTF-16 更难解码。 在 UTF-16 中，字符是基本多语言平面字符（2 个字节）或代理对（4 个字节）。 UTF-8 字符可以是 1 到 4 个字节之间的任意位置。

与其他人的回答相反 - 您不能将 UTF-16 视为UCS-2 。 如果要正确迭代字符串中的实际字符，则必须使用 unicode 友好的迭代函数。 例如，在 C# 中，您需要使用StringInfo.GetTextElementEnumerator() 。

有关更多信息，维基上的这个页面值得一读： http : //en.wikipedia.org/wiki/Comparison_of_Unicode_encodings

Answer 4

这取决于预期的字符集。 如果您希望大量使用 7 位 ASCII 范围之外的 Unicode 代码点，那么您可能会发现 UTF-16 将比 UTF-8 更紧凑，因为某些 UTF-8 序列的长度超过两个字节。

此外，出于效率原因，Java 和 C# 在索引字符串时不考虑代理对。 当使用由占用奇数字节的 UTF-8 序列表示的代码点时，这将完全失效。

Answer 5

UTF-16 可以更有效地表示某些语言（例如中文、日语和韩语）中的字符，其中大多数字符可以用一个 16 位字表示。 一些很少使用的字符可能需要两个 16 位字。 UTF-8 通常在表示来自西欧字符集的字符时效率更高——UTF-8 和 ASCII 在 ASCII 范围 (0-127) 上是等效的——但在亚洲语言中效率较低，需要三个或四个字节来表示字符可以用 UTF-16 中的两个字节表示。

UTF-16 作为 Java/C# 的内存格式具有优势，因为基本多语言平面中的每个字符都可以用 16 位表示（请参阅 Joe 的回答）以及 UTF-16 的一些缺点（例如，依赖在 \\0 终止符上）不太相关。

Answer 6

对于许多（大多数？）应用程序，您将只处理Basic Multilingual Plane中的字符，因此可以将 UTF-16 视为固定长度的编码。

因此，您可以避免像 UTF-8 这样的可变长度编码的所有复杂性。

Answer 7

如果我们单独谈论纯文本，UTF-16 在某些语言中可以更紧凑，日语（约 20%）和中文（约 40%）是主要例子。 一旦比较 HTML 文档，优势就会完全相反，因为 UTF-16 会为每个 ASCII 字符浪费一个字节。

至于简单性还是效率：如果您在编辑器应用程序中正确实现 Unicode，复杂性将类似，因为无论如何 UTF-16 并不总是将代码点编码为单个数字，并且单个代码点通常不是分割文本的正确方法。

鉴于在最常见的应用程序中，UTF-16 不那么紧凑，而且实现起来同样复杂，因此更喜欢 UTF-16 而不是 UTF-8 的唯一原因是，如果您有一个完全封闭的生态系统，您经常存储或传输纯文本完全在复杂的书写系统中，没有压缩。

用zstd或LZMA2压缩后，即使是100%中文纯文本，优势也完全消失； 使用 gzip 时，UTF-16 的优势大约是中文文本的 4%，大约有 3000 个独特的字素。