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

Question

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

但是当与StreamWriter保存时:

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

我见过这个样本(删除了断开的链接):

在此输入图像描述

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

那么为什么.net utf16在utf8保存文件时使用字符串的默认编码？

谢谢.

ps我已经读过这篇着名的文章了

Answer 1

Jon*_*eet 50

如果你很高兴忽略代理对(或等同地,你的应用程序需要在Basic Multilingual Plane之外的字符的可能性),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个角色也有"问题".文字很难...)

@RoyiNamir:不,UTF-16代码单元的大小总是*2字节.Unicode字符采用一个代码单元(对于基本多语言平面)或两个代码单元(对于字符U + 10000及以上). (10认同)
UTF-8 的要点在于，如果每个字符需要 6 个字节来真正表示所有可能性，那么任何小于 UTF-32 的问题都是需要特殊情况和额外代码的问题。所以 UTF-16 和 UTF-8 都是不完美的。但是，由于 UTF-8 是大小的一半，您不妨使用它。在它上面使用 UTF-16 没有任何好处（除了增加的文件/字符串大小）。当然，有些人会使用 UTF-16 并无知地认为它可以处理所有字符。 (2认同)
我已经读过14次了.我仍然不理解这一行:_每个代码单元的大小是常数_.AFAIK的大小可以是2,3,4字节(在utf-16中)所以这里有什么不变？ (2认同)

Answer 2

Han*_*ant 27

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

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

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

Answer 3

小智 10

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

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

归档时间：	12 年，6 月前
查看次数：	34817 次
最近记录：	9 年，1 月前