Essentially, string uses the UTF-16 character encoding form
但是当保存 vs StreamWriter 时:
This constructor creates a StreamWriter with UTF-8 encoding without a Byte-Order Mark (BOM),
我看过这个示例(已删除损坏的链接):
看起来 utf8 对于某些字符串来说更小，而 utf-16 在其他一些字符串中更小。
- 那么，为什么 .net 使用
utf16作为字符串的默认编码，而使用utf8来保存文件？
谢谢。
附注我已经读过 the famous article
最佳答案
如果您乐于忽略代理对(或者等效地，您的应用程序需要基本多语言平面之外的字符的可能性)，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 对 Unicode 数据使用 UTF-16，出于互操作的原因，.NET 效仿是有道理的。不过，这只是将问题推进了一步。)
考虑到代理对的问题，我怀疑如果一种语言/平台是从头开始设计的，没有互操作要求(但基于 Unicode 的文本处理)，UTF-16 将不是最佳选择。 UTF-8(如果您想要内存效率并且不介意在获取第 n 个字符方面的一些处理复杂性)或 UTF-32(反之亦然)将是更好的选择。 (由于不同的规范化形式，即使到达第 n 个字符也有“问题”。文本很难......)
关于c# - 为什么.net 对字符串使用 UTF16 编码，而保存文件却默认使用 UTF-8？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14942092/