为什么UTF-16无法取代UTF-8？编码世界的权衡与选择

Java

我之前回答过类似问题，发现有些人对UTF-16存在误解，态度偏激，所以在这里再强调一次。UTF-16 适合内存中处理字符串，UTF-8 适用于传输和存储，且因与 ASCII 在二进制层面兼容而具备独特优势。两者各有用途，并非替代关系，均具有重要的存在价值。

我们来分析一下UTF-8和UTF-16在内存中用作字符串编码的优缺点：UTF-8 在字节级上与 ASCII 兼容，便于和使用 char * 的 C 库对接，尤其在类 Unix 系统中非常普遍。而 UTF-16 与 UCS-2 在字节级兼容，被广泛应用于 Win32 API、Qt、ICU、Java、C 和 JavaScript 等生态，成为这些平台首选的字符串编码方式，也因此形成了庞大的生态系统。从生态支持的角度来看，UTF-8 和 UTF-16 各有优势，难分伯仲。

不同类型字符使用 UTF-8 编码时，占用内存大致如下：使用 UTF-16 编码时，大致情况如下：UTF-8适合存储以ASCII字符为主的字符串，占用内存较少；UTF-16则更适合存储以中日韩常用字符为主的字符串，内存占用更低。编程语言通常处理更多 ASCII 字符串，因此 UTF-8 一般比 UTF-16 占用更低内存。不过，Java 和 JavaScript 当前使用了一种改进方案：字符串 API 依旧与 UTF-16 兼容，但内部根据内容选择用 Latin-1 或 UTF-16 存储，这种方式使内存占用情况发生了如下变化：这种混合方案存储 ASCII 字符串时与 UTF-8 表现相当，存储西欧语言字符或以中日韩常用字符为主的字符串时，内存占用低于 UTF-8。整体而言，该方案与 UTF-8 各有千秋，性能不相上下。UTF-16 的一个重要优点是，在很多情况下，它可以近似视为定长字符串进行处理。当我们对 Unicode 有一定了解后，或许会对此种用法不以为然，觉得它不太严谨。毕竟，UTF-16 编码一个 Unicode 字符可能需要由两个码位组成的代理对来表示，本质上仍是变长编码。需要明确的是，大众理解的字符并非 Code Point，而是 Unicode 中的字素簇（Grapheme Clusters），也可称为用户感知字符（User-perceived characters）。这是更贴近人们日常使用的概念，能够准确反映用户所见的字符形式。一个字素簇可由一个或多个 Unicode 代码点组成，例如字母 A 与组合变音符号 ??（U+030A）结合形成字符 ?。即使使用 UTF-32 存储，它依然包含两个代码点。一个字素簇可能包含十几个或更多的代码点，占用几十到几百字节，远超现代计算机通用寄存器的容量。要正确处理字素簇，必须对 Unicode 有深入的理解和掌握，才能确保处理的准确性与规范性。追求完善固然好，但代价过高而收益有限，因此在实际开发中，程序员大多仍需将 Code Unit 或 Code Point 视作字符来处理，自我安慰地简化问题。

大众

至此，UTF-16 的伪定长特性就容易理解了。大多数情况下，我们用 UTF-16 模拟 UCS-2，既能享受定长字符串带来的便利，又能应对 99.99% 的实际需求，总比勉强自己去处理复杂情况要轻松得多。即使不想简化，仅处理代码点，UTF-16 也比 UTF-8 更加便捷高效。UTF-8 是一种长度可变的编码方式，使用 1 至 4 个代码单元表示字符。UTF-16 是一种使用 1~2 个代码单元的可变长度编码方式：下面是将 UTF-8 和 UTF-16 字节数组解码为代码点的代码（错误处理已简化），从代码长度就能看出两者在处理复杂度上的差异。这是采用UTF-16编码格式：

以下这些工具方法非常通用，可轻松封装到工具类中，核心解码代码随意实现。关于UTF-8……

UTF-8 和 UTF-16 的复杂程度相差甚远，不能简单用都是变长编码来概括。虽然平时我们常用现成的库处理字符编码问题，但在需要手动操作时，会明显感到 UTF-16 更加直观易用，而 UTF-8 却容易出错，甚至照着写都可能搞错。若要进一步深入，认真处理字素簇时，UTF-8、UTF-16 和 UTF-32 之间差异不大。这种复杂性已远超手工处理的范畴，只能依赖领域专家提供的几个专业库来解决。总体而言，尽管 UTF-16 的存在源于复杂的历史原因，如果抛开历史包袱，我们确实有更优的选择（例如 Python 在底层自动选择 Latin-1/UCS2/UCS4）。然而，基于当前实际情况，UTF-16 并非像某些人认为的那样毫无价值。它在特定场景下仍具有一定意义和优势。