69

从这里

本质上，字符串使用 UTF-16 字符编码形式

但是当保存 vs StreamWriter时：

此构造函数使用 UTF-8 编码创建一个没有字节顺序标记 (BOM) 的 StreamWriter，

我看过这个示例（已删除断开的链接）：

在此处输入图像描述

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

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

谢谢你。

ps 我已经阅读了著名的文章

4

3 回答 3

62

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

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

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

UTF-16 的两个缺点是：

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

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

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

于 2013-02-18T17:39:01.290 回答
34

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

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

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

于 2013-02-18T18:18:24.777 回答
12

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

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

于 2013-07-16T21:49:15.997 回答