首页 文章

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

提问于
浏览 次
47

From here

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

但是当保存vs StreamWriter时：

此构造函数创建一个StreamWriter，其UTF-8编码没有字节顺序标记（BOM），

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

enter image description here

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

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

谢谢 .

附：我已经读过the famous article

c# .net string utf-8 utf-16

3 回答

  • 23

    如果你很高兴忽略代理对（或等同地，你的应用程序需要在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个角色也有“问题” . 文字很难...）

    回复于
  • 41

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

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

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

    回复于
  • 8

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

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

    回复于

相关问题