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

考虑原始类型char。如果我们使用UTF-8作为内存中的表示，并希望科普 * 所有 * Unicode字符，那么它应该有多大？它可以是4个字节…这意味着我们总是要分配4个字节。在这一点上，我们不妨使用UTF-32！
当然，我们可以使用UTF-32作为char表示，但在string表示中使用UTF-8，并在我们进行转换。
UTF-16的两个缺点是：

• 每个Unicode字符的代码单元数是可变的，因为在BMP中并非所有字符都是 *。在emoji流行之前，这并没有影响到日常使用中的许多应用程序。如今，对于消息传递应用程序等，使用UTF-16的开发人员确实需要了解代理对。
• 对于纯ASCII（很多文本都是这样，至少在西方），它占用的空间是同等UTF-8编码文本的两倍。

(As顺便说一下，我相信Windows使用UTF-16作为Unicode数据，而.NET出于互操作的原因也是有意义的。这只是把问题推到了一步。）
考虑到代理对的问题，我怀疑如果一种语言/平台是从头开始设计的，没有互操作需求（但基于Unicode的文本处理），UTF-16不会是最好的选择。UTF-8（如果您想要内存效率，并且不介意处理第n个字符的复杂性）或UTF-32（反过来）将是更好的选择。（由于不同的规范化形式等原因，即使到达第n个字符也会有“问题”。文字很难……）

与许多“为什么选择这个”的问题一样，这是由历史决定的。Windows在1993年成为Unicode操作系统。当时，Unicode仍然只有65535个代码点的代码空间，现在称为UCS。直到1996年，Unicode才获得了补充平面，将编码空间扩展到了100万个码点。和代理项对，以使它们适合16位编码，从而制定utf-16标准。
.NET字符串是utf-16，因为它非常适合操作系统编码，不需要转换。
utf-8的历史则更加模糊。RFC-3629是1993年11月发布的。花了一段时间才站稳脚跟，互联网是工具。

UTF-8是文本存储和传输的默认格式，因为对于大多数语言来说，它是一种相对紧凑的格式（有些语言的UTF-16格式比UTF-8格式更紧凑）。每种特定的语言都有更有效的编码。
UTF-16用于内存中的字符串，因为它可以更快地解析每个字符，并直接Map到Unicode字符类和其他表。Windows中的所有字符串函数都使用UTF-16，并且已经使用了很多年。