为什么 .net 对字符串使用 UTF16 编码，但默认使用 UTF-8 来保存文件？

如果您乐于忽略代理对（或等效地，您的应用程序需要基本多语言平面之外的字符的可能性），UTF-16 有一些很好的属性，基本上是因为每个代码单元总是需要两个字节并代表所有 BMP 字符每个单个代码单元。

考虑原始类型 char。如果我们使用 UTF-8 作为内存中的表示并想要处理 all Unicode 字符，那应该有多大？它可能最多 4 个字节......这意味着我们总是必须分配 4 个字节。那时我们不妨使用 UTF-32！

当然，我们可以使用 UTF-32 作为 char 表示，但在 string 表示中使用 UTF-8，我们可以随时转换。

UTF-16 的两个缺点是：

每个 Unicode 字符的代码单元数是可变的，因为并非所有字符都在 BMP 中。在表情符号流行之前，这并没有影响许多日常使用的应用程序。如今，对于消息传递应用程序等，使用 UTF-16 的开发人员确实需要了解代理对。

对于纯 ASCII（至少在西方有很多文本），它占用的空间是等效 UTF-8 编码文本的两倍。

（作为旁注，我相信 Windows 使用 UTF-16 处理 Unicode 数据，出于互操作的原因，.NET 效仿是有意义的。不过，这只是将问题推向了一步。）

考虑到代理对的问题，我怀疑如果一种语言/平台是从头开始设计的，没有互操作要求（但基于 Unicode 的文本处理），UTF-16 不会是最佳选择。 UTF-8（如果您想要内存效率并且不介意在获取第 n 个字符方面的一些处理复杂性）或 UTF-32（反之亦然）将是更好的选择。 （由于不同的规范化形式，即使到达第 n 个字符也有“问题”。文本很难......）

---

与许多“为什么选择这个”问题一样，这是由历史决定的。 Windows 于 1993 年成为其核心的 Unicode 操作系统。当时，Unicode 仍然只有 65535 个代码点的代码空间，现在称为 UCS。直到 1996 年，Unicode 才获得了补充平面，将编码空间扩展到一百万个代码点。并使用代理对将它们放入 16 位编码中，从而设置 utf-16 标准。

.NET 字符串是 utf-16，因为它非常适合操作系统编码，不需要转换。

utf-8 的历史更加模糊。绝对超越 Windows NT，RFC-3629 始于 1993 年 11 月。它需要一段时间才能站稳脚跟，互联网发挥了重要作用。

---

UTF-8 是文本存储和传输的默认设置，因为它对于大多数语言来说是一种相对紧凑的形式（有些语言在 UTF-16 中比在 UTF-8 中更紧凑）。每种特定语言都有更有效的编码。

UTF-16 用于内存中的字符串，因为它可以更快地解析每个字符并直接映射到 unicode 字符类和其他表。 Windows 中的所有字符串函数都使用 UTF-16 并且已经使用了多年。

---