为什么.net对字符串使用UTF16编码，但是使用utf8作为保存文件的默认值？

Question

From here

  

本质上，string使用UTF-16字符编码格式

但是在保存vs StreamWriter时：

  

此构造函数使用UTF-8编码创建StreamWriter而不使用   字节顺序标记（BOM），

我见过这个样本（删除了断开的链接）：

对于某些字符串，utf8看起来较小，而在其他字符串中utf-16较小。

• 那么为什么.net使用utf16作为字符串的默认编码，而utf8用于保存文件？

谢谢。

P.S。我已阅读the famous article

Answer 1

如果你很高兴忽略代理对（或等同地，你的应用程序需要在Basic Multilingual Plane之外的字符的可能性），UTF-16有一些不错的属性，主要是由于总是每个代码单元需要两个字节，并在每个代码单元中表示所有BMP字符。

考虑原始类型char。如果我们使用UTF-8作为内存中表示并想要处理所有 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个角色也有＃34;问题＆＃34;由于不同的规范化形式之类的东西。文字很难......）

Answer 2

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

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

utf-8的历史更为模糊。 RFC-3629绝对是过去的Windows NT，可以追溯到1993年11月。它需要一段时间才能占据一席之地，互联网起了作用。

Answer 3

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

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