C#大端UCS-2

Question

我目前正在从事的项目需要与我们没有开发的客户端系统进行接口，因此我们无法控制数据的发送方式。问题是在C#中工作，它似乎没有任何对UCS-2的支持，对大端的支持非常少。(据我所知)

我想知道的是，如果我在.net中看到了什么，或者其他人已经制作并发布了一些我们可以使用的东西。如果没有，我将在定制方法中对其进行编码/解码，如果可能的话。

但无论怎样都谢谢你的时间。

编辑: BigEndianUnicode确实可以正确解码字符串，问题是在接收其他数据作为大端，到目前为止使用IPAddress.HostToNetworkOrder()的建议，其他地方已经允许我解码一半的字符串(Merli？出现的应该是Merlin33069)

我正在梳理短代码，以查看是否还有我遗漏的另一个长度变量

解决方案:在计算出bigendian变量是主要问题之后，我回头回顾了细节，似乎字符串的长度是以字符计数，而不是字节计数发送的(在utf中，一个字符似乎是两个字节)--我所需要做的就是加倍，然后它就完成了。谢谢你们的帮助。

Answer 1

编辑:现在我们知道问题不在于文本数据的编码，而在于长度的编码。有几种选择：

• 反转字节，然后使用内置的BitConverter代码(我假设这就是您现在正在使用的代码；即或BinaryReader)
• 使用重复的“添加和移位”操作自己执行转换
• 使用我的EndianBitConverter或MiscUtil中的EndianBinaryReader类，它们类似于BitConverter和BinaryReader，但让您指定endianness。

你可能在找Encoding.BigEndianUnicode。这是大端UTF-16编码，严格来说与UCS-2不同(正如Marc指出的那样)，但是应该很好，除非您给它字符串，包括BMP以外的字符(即U+FFFF)，它不能用UCS-2表示，而是用UTF-16表示。

来自维基百科页面

较早的UCS-2 (2字节通用字符集)是一种类似的字符编码，1996年7月在Unicode标准2.0版中被UTF-16所取代。2通过简单地使用代码点作为16位代码单元来产生固定长度的格式，并产生与UTF-16完全相同的结果，用于0-0xFFF范围内所有代码点的96.9%，包括当时分配的所有字符。

我发现客户端系统不太可能在有差异的地方向您发送字符(基本上是代理项对，无论如何都是永久保留的)。

Answer 2

string x = "abc";
byte[] data = Encoding.BigEndianUnicode.GetBytes(x);

在其他方面：

string decodedX = Encoding.BigEndianUnicode.GetString(data);

它并不完全是UCS-2，但对于大多数情况来说，它已经足够了。

UPD: Unicode常见问题

问: UCS-2和UTF-16有什么区别？ 答: UCS-2是过时的术语，它指的是Unicode实现，直到Unicode 1.1，然后才将代理代码点和UTF-16添加到标准的2.0版本中。现在应该避免使用这一术语。 UCS-2没有定义不同的数据格式，因为UTF-16和UCS-2在数据交换方面是相同的.两者都是16位的，并且具有完全相同的代码单元表示形式. 有时，在过去，实现被标记为"UCS-2“，以表明它不支持补充字符，并且不将代理代码点对解释为字符。这样的实现不会处理字符属性、代码点边界、排序规则等补充字符的处理。

Answer 3

UCS-2是如此接近UTF-16，以至于Encoding.BigEndianUnicode几乎总是足够的.

读取长度前缀(作为大端)的问题(注释)通过shift操作更正确地解决，这将在所有系统上做正确的事情。例如：

Read4BytesIntoBuffer(buffer);
int len =(buffer[0] << 24) | (buffer[1] << 16) | (buffer[2] << 8) | (buffer[3]); 

然后，这将在任何系统上同样工作(在解析大端4字节int时)，而不考虑本地endianness。