分享一个字节序方面的知识

分享一个字节序方面的知识

在项目中进行通信时遇到这样的问题,对于包的长度和类型在传输中商定为大端(网络字节序),但是在转换后读取到的数据显示出来却是小端(主机字节序)的数据。下面将具体的过程进行描述,便于大家能对数据在内存中的分布情况，数据读取，大端小端等方面的问题能够一目了然。

包类型
typedef struct {
unsigned short packet_len;
unsigned short packet_type;
message  Task; //google protoco buffer,不需要关心这个内部具体细节
}Task;


环境是windows，intel处理器，所以数据在内存的分布默认是小端的。
开始的时候我们在会对packet_len和packet_type进行htons将其转换为网络字节序(也就是大端)，然后将其用于网络传输
在解析到的时候我们获取到的数据显示出来是小端的，在查找原因后发现,在我们自己的库函数write_int和read_int中在写入和读取到的数据会改变字节序的问题,其实带有了ntohs和htons的功能。
具体行为如下：
packet_len = 15
16进制表示是0x000f，在内存中的表示是0f 00,这是由于小端的缘故会是低位在前.
而要将其从主机字节序改变为网络字节序,我们可以使用htons，在调用后big=htons(packet_len)
big的十六进制表示是0x0f00，在内存中的表示是00 0f
在我们转换为网络字节序和一些列数据获取后需要写入到buffer中,通过发送和接受该buffer来进行协议控制
写入到buffer中我们使用了write_int，该函数的功能是将数据按字节依次写入到buffer
那么packet_len在转换为网络字节序后在写入buffer,取前两个字节分析(packet_len)
第一个字节是：0x0f
第二个字节是: 0x00
那么在这个时候我们就可以看到，我们实际传输的packet_len在存储到buffer中已经变成了0x0f00,那么根据小端机器低位在前,读取的数据就是0x000f这个数据实际还是小端的数据，由此我们取消了对packet_len和packet_type调用htons

附:write_int函数
template <class T>
T write_int(int cb/*要写入buffer的长度*/, T w0/*指向buffer的指针*/, long long v/*要写入的数据*/)
{
unsigned char* w = reinterpret_cast<unsigned char*>(w0);
w += cb;
for (int i = 0; i < cb; i++)
{
*--w = v & 0xff;
v >>= 8;
}
return reinterpret_cast<T>(w + cb);
}