C＃big-endian UCS-2
我目前正在开发的项目需要与我们没有建立的客户端系统进行交互，因此我们无法控制数据的发送方式。 问题是在C＃中工作，它似乎对UCS-2没有任何支持，对big-endian的支持很少。 （据我所知）
我想知道的是，如果我在.net中查看过任何内容，或者其他人已经制作并发布了我们可以使用的内容。 如果不是，我将采用自定义方法对其进行编码/解码，如果可能的话。
但无论如何，谢谢你的时间。
编辑：BigEndianUnicode 确实正确解码字符串，问题是接收其他数据作为大端，到目前为止使用IPAddress.HostToNetworkOrder（）如其他地方建议允许我解码一半的字符串（Merli？是出现的和它应该是Merlin33069）
我梳理短代码，看看是否错过了另一个长度变量
解决方案：在确定了bigendian变量是主要问题后，我回过头来查看详细信息，似乎字符串的长度是以字符数发送的，而不是字节数（在utf中它似乎是char是两个所有我需要做的就是加倍，然后就解决了。 感谢大家的帮助。
编辑：现在我们知道问题不在于文本数据的编码，而在于长度的编码。 有几个选择：
- 反转字节然后使用内置的
BitConverter代码（我假设你现在正在使用它;那或BinaryReader） - 使用重复的“添加和移位”操作自行执行转换
- 使用来自MiscUtil的我的
EndianBitConverter或EndianBinaryReader类，它们类似于BitConverter和BinaryReader，但是允许您指定字节序。
您可能正在寻找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-0xFFFF范围内所有代码点的96.9％，包括当时已分配值的所有字符。
我发现客户端系统不太可能向你发送存在差异的字符（这基本上是代理对，无论如何都永久保留用于该用途）。
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是过时的术语，在代理代码点和UTF-16被添加到标准的2.0版之前，它指的是Unicode 1.1之前的Unicode实现。 现在应该避免使用这个术语。
UCS-2没有定义不同的数据格式，因为UTF-16和UCS-2在数据交换方面是相同的。 两者都是16位，并且具有完全相同的代码单元表示。
有时在过去，实现被标记为“UCS-2”以指示它不支持增补字符并且不将代理代码点对解释为字符。 这样的实现不会处理补充字符的字符属性，代码点边界，校对等的处理。
UCS-2非常接近UTF-16， Encoding.BigEndianUnicode 几乎总是足够的。
通过移位操作可以更正确地解决围绕读取长度前缀（作为big-endian）的问题（注释），这将在所有系统上做正确的事情。 例如：
Read4BytesIntoBuffer(buffer); int len =(buffer[0] << 24) | (buffer[1] << 16) | (buffer[2] << 8) | (buffer[3]);
这将在任何系统上工作相同（在解析大端4字节int时），无论本地字节顺序如何。