C# 小端还是大端?
在允许我们通过 UDP/IP 控制它的硬件文档中, 我找到了以下片段:
在此通信协议中,DWORD为4字节数据,WORD为2字节数据, BYTE 是单字节数据。 存储格式为little endian,即4个字节(32bits)数据存储为:d7-d0、d15-d8、d23-d16、d31-d24; 双字节(16位)数据存储为:d7-d0,d15-d8。
我想知道这如何转换为 C#? 在发送之前我必须先转换内容吗? 例如,如果我想发送一个 32 位整数,或者一个 4 个字符的字符串?
In the documentation of hardware that allows us to control it via UDP/IP,
I found the following fragment:
In this communication protocol, DWORD is a 4 bytes data, WORD is a 2 bytes data,
BYTE is a single byte data. The storage format is little endian, namely 4 bytes (32bits) data is stored as: d7-d0, d15-d8, d23-d16, d31-d24; double bytes (16bits) data is stored as: d7-d0 , d15-d8.
I am wondering how this translates to C#?
Do I have to convert stuff before sending it over?
For example, if I want to send over a 32 bit integer, or a 4 character string?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(6)
C# 本身没有定义字节序。 然而,每当您转换为字节时,您都在做出选择。 BitConverter 类有一个 IsLittleEndian 字段告诉您它将如何表现,但它没有提供选择。 BinaryReader/BinaryWriter 也是如此。
我的 MiscUtil 库有一个 EndianBitConverter 类,允许您定义字节序; BinaryReader/Writer 也有类似的等效项。 恐怕没有在线使用指南,但它们很简单:)
(EndianBitConverter 还具有普通 BitConverter 中不存在的一项功能,即在字节数组中就地进行转换。)
C# itself doesn't define the endianness. Whenever you convert to bytes, however, you're making a choice. The BitConverter class has an IsLittleEndian field to tell you how it will behave, but it doesn't give the choice. The same goes for BinaryReader/BinaryWriter.
My MiscUtil library has an EndianBitConverter class which allows you to define the endianness; there are similar equivalents for BinaryReader/Writer. No online usage guide I'm afraid, but they're trivial :)
(EndianBitConverter also has a piece of functionality which isn't present in the normal BitConverter, which is to do conversions in-place in a byte array.)
您还可以使用
Forshort、int 或 long。
You can also use
For short, int or long.
对于小端,简短的答案(我需要做任何事情)是“可能不需要,但这取决于你的硬件”。 您可以检查:
根据上面的内容,您可能想要反转缓冲区的部分内容。 或者,Jon Skeet 在此处提供了特定的字节序转换器(查找 EndianBitConverter)。
请注意,安腾(例如)是大端字节序。 大多数 Intel 都是小端字节序。
关于特定的 UDP/IP...?
Re little-endian, the short answer (to do I need to do anything) is "probably not, but it depends on your hardware". You can check with:
Depending on what this says, you might want to reverse portions of your buffers. Alternatively, Jon Skeet has specific-endian converters here (look for EndianBitConverter).
Note that itaniums (for example) are big-endian. Most Intels are little-endian.
Re the specific UDP/IP...?
您需要了解网络字节顺序以及 CPU 字节序。
通常,对于 TCP/UDP 通信,您始终使用 < code>htons 函数(和
ntohs
及其相关函数)。通常网络顺序是大端,但在这种情况下(由于某种原因!)通信是小端,所以这些函数不是很有用。 这很重要,因为你不能假设他们实现的 UDP 通信遵循任何其他标准,如果你有一个大端架构,它也会让生活变得困难,因为你不能像你一样用
htons
包装所有内容。应该:-(但是,如果您来自 intel x86 架构,那么您已经是小端字节序了,因此只需发送数据而不进行转换。
You need to know about network byte order as well as CPU endian-ness.
Typically for TCP/UDP comms, you always convert data to network byte order using the
htons
function (andntohs
, and their related functions).Normally network order is big-endian, but in this case (for some reason!) the comms is little endian, so those functions are not very useful. This is important as you cannot assume the UDP comms they have implemented follow any other standards, it also makes life difficult if you have a big-endian architecture as you just can't wrap everything with
htons
as you should :-(However, if you're coming from an intel x86 architecture, then you're already little-endian, so just send the data without conversion.
我正在处理 UDP 多播中的打包数据,我需要一些东西来重新排序 UInt16 八位字节,因为我注意到数据包标头(Wireshark)中存在错误,所以我做了这个:
In case of UInt32,
This is just for test
from which output is这:
I'm playing around with packed data in UDP Multicast and I needed something to reorder UInt16 octets since I noticed an error in packet header (Wireshark), so I made this:
In case of UInt32,
This is just for testing
from which output was this:
如果您正在解析并且性能并不重要,请考虑这个非常简单的代码:
If you're parsing and performance is not critical, consider this very simple code: