为什么C#Unicode范围覆盖有限的范围（最多0xFFFF）？

Question

我对C#UTF8编码感到困惑...

假设这些“事实”是正确的：

1. Unicode是定义每个字符的“协议”

根据C#参考，每个字符的可接受范围为0x0000到0xFFFF。我不明白另一个字符是什么，它在0xFFFF之上，在Unicode协议中定义的？

与C#相比，当我使用Python编写UTF8文本时-它涵盖了所有预期范围（0x0000到0x10FFFF）。例如：

u"\U00010000"  #WORKING!!!

这对C不起作用。此外，当我将Python中的字符串（单字符）写入文本文件，然后从C#中读取时，这个单字符文档变成了C#中的2个字符！

# Python (write):
import codecs                        
with codes.open("file.txt", "w+", encoding="utf-8") as f:                        
    f.write(text) # len(text) -> 1

// C# (read): 
string text = File.ReadAllText("file.txt", Encoding.UTF8); // How I read this text from file.
Console.Writeline(text.length); // 2

为什么？如何修复？

Answer 1

Unicode有所谓的平面（wiki）。

如您所见，C#schartype仅支持第一个平面，即平面0，即基本的多语言平面。

我知道C#使用UTF-16编码，所以我有点惊讶地看到，它不支持超出char数据类型第一个平面的代码点。（我自己没有遇到过这个问题……）。

这是char实现中的人为限制，但可以理解。的设计者。NET可能不想将自己的字符数据类型的抽象与Unicode定义的抽象联系起来，以防该标准无法生存（它已经取代了其他标准）。当然，这只是我的猜测。它只是“使用”UTF-16来表示内存。

UTF-16使用一种技巧将高于0xFFFF的代码点压缩为16位，您可以在这里阅读到。从技术上讲，这些代码点由2个“字符”组成，即所谓的代理项对。从这个意义上讲，它打破了“一个代码点=一个字符”的抽象。

您可以通过使用string和char数组来解决这个问题。如果您有更具体的问题，您可以在StackOverflow和其他地方找到大量关于在. NET中处理所有Unicode代码点的信息。

Answer 2

根据C#参考，每个字符的可接受范围为0x0000到0xFFFF。我不明白另一个字符是什么，它在0xFFFF之上，在Unicode协议中定义的？

不幸的是，C#/。NETchar不代表Unicode字符。

字符是0x0000到0xFFFF范围内的16位值，表示一个“UTF-16代码单元”。U 0000–U D7FF和U E000–U FFFF范围内的字符由相同数字的代码单元表示，因此在那里一切都很好。

通过将每个字符表示为两个UTF-16代码单元，将U 010000到U 10FFFF范围内使用频率较低的其他字符压缩到剩余空间0xD800–0xDFFF中，因此Python字符串“U00010000”的等价物是C#“\uD800\uDC00”。

为什么？

之所以如此疯狂，是因为Windows NT系列本身使用UTF-16LE作为本机字符串编码，以便于互操作。NET选择了相同的。WinNT选择了当时被认为是UCS-2的编码，并且没有任何令人讨厌的代理代码单元对，因为在早期，Unicode只有U-FFFF以下的字符，并且认为这将是所有人都需要的。

怎么修？

没有一个好的解决方案。其他一些不幸的语言将其字符串类型基于UTF-16代码单元（Java、JavaScript），开始向其字符串添加方法来对它们进行操作，一次计数一个代码点；但是目前在. NET中没有这样的功能。

通常情况下，您实际上并不需要使用适当的代码点项和索引来持续计算/查找/拆分/排序/etc字符串。但是当你真的这样做的时候，在. NET中，你就处于一个糟糕的时期。您最终不得不重新实现每个通常微不足道的方法，方法是手动遍历每个char并检查它是否是双字符代理对的一部分，或者将字符串转换为代码点整数数组并返回。无论如何，这都不是很有趣。

一个更优雅、更实用的选择是发明一台时间机器，这样我们就可以将UTF-8设计追溯到1988年，并阻止UTF-16的存在。