为什么.net对string使用UTF16编码，但使用utf8作为保存文件的默认值？
从这里
本质上，string使用UTF-16字符编码forms
但是，当保存vs StreamWriter时 ：
这个构造函数创build一个没有字节顺序标记（BOM）的UTF-8编码的StreamWriter，
我已经看到这个样本（断开的链接删除）：
它看起来像utf8是一些string较小而utf-16在一些其他string较小。
- 那么为什么.net使用
utf16作为string的默认编码，而utf8保存文件？
谢谢。
我已经阅读了这篇着名的文章
如果你很高兴忽略代理对（或等价地，你的应用程序需要在基本多语言平面以外的字符的可能性），UTF-16有一些很好的属性，基本上是因为总是要求每个代码单元有两个字节并且代表所有BMP字符每个单独的代码单元。
考虑原始typeschar 。 如果我们使用UTF-8作为内存中的表示，并且想要处理所有的 Unicode字符，那应该是多大？ 它可能高达4个字节…这意味着我们总是要分配4个字节。 那么我们不妨使用UTF-32！
当然，我们可以使用UTF-32作为char表示，但UTF-8在string表示中转换。
UTF-16的两个缺点是：
- 每个Unicode字符的代码单元数是可变的，因为不是所有字符都在BMP中。 直到表情符号变得stream行，这并没有影响到许多应用程序的日常使用。 现在，对于消息传递应用等，使用UTF-16的开发人员确实需要知道代理对。
- 对于普通的ASCII（至less在西方是很多文本），它需要两倍于等效UTF-8编码文本的空间。
（作为一个方面说明，我相信Windows使用UTF-16来处理Unicode数据，而.NET对于互操作性的理由是有道理的，这只是一步步推进的。
鉴于代理对的问题，我怀疑如果一个语言/平台是从头开始devise的，没有互操作性的要求（但是它的文本处理是以Unicode编码的），UTF-16将不是最好的select。 无论是UTF-8（如果你想要的内存效率，不介意一些处理复杂的方面到达第n个字符）或UTF-32（反过来）将是一个更好的select。 （即使到第n个字符由于不同规范化forms的东西而具有“问题”，文本很难…）
与许多“为什么select这个”问题一样，这是历史决定的。 在1993年，Windows成为了一个Unicode操作系统的核心。那时，Unicode仍然只有65535个码点的代码空间，现在被称为UCS。 直到1996年，Unicode才获得了辅助平面，以将编码空间扩展到一百万个码点。 和代理对，以适应他们到16位编码，从而设置utf-16标准。
.NETstring是utf-16，因为它非常适合操作系统编码，不需要转换。
utf-8的历史更加阴暗。 绝对超过了Windows NT，RFC-3629的date从1993年11月开始。需要一段时间才能获得足够的支持，互联网是有用的。
UTF-8是文本存储和传输的默认设置，因为它对于大多数语言来说是一个相对紧凑的格式（有些语言在UTF-16中比在UTF-8中更紧凑）。 每种特定语言都有更高效的编码。
UTF-16用于内存string，因为每个字符的parsing速度更快，并且直接映射到Unicode字符类和其他表。 Windows中的所有string函数都使用UTF-16并且有多年的历史。
