4字节序转换

六月刀

博文出处：http://blog.163.com/liu_jun_y/bl ... 631220125411739843/


什么是字节序？
一般而言，字节序指示大于一个字节类型的数据在内存中的存放顺序(一个字节的数据当然就无需谈顺序的问题了)。
a) Little-Endian就是低位字节排放在内存的低地址端，高位字节排放在内存的高地址端。
b) Big-Endian就是高位字节排放在内存的低地址端，低位字节排放在内存的高地址端。
举个例子：一个32位的整型数 0x12345678, 在内存中的长度是4个字节。假如他在内存中的首地址是 0x10000000.
在 Little-Endian 中
0x10000000 -> 0x78
0x10000001 -> 0x56
0x10000002 -> 0x34
0x10000003 -> 0x12
在 Big-Endian 中
0x10000000 -> 0x12
0x10000001 -> 0x34
0x10000002 -> 0x56
0x10000003 -> 0x78
哪些平台是Little-Endian，哪些是Big-Endian？
就目前我所知道的：
       Little-Endian： PC(x86), DreamCast
       Big-Endian:    MAC, GC, XBOX360, PS3
因此在涉及到这些平台间的移植时，需要考虑到字节序转换问题。
如何判断一个平台是什么字节序？
给个简单的例子:
enum ENDIAN_TYPE {
       ENDIAN_LITTLE,
       ENDIAN_BIG,
};
ENDIAN_TYPE GetCurrentEndianType()
{
       unsigned long data = 1;
       return (*(unsigned char*)(&data) == 1) ? ENDIAN_LITTLE : ENDIAN_BIG;
}
如何进行字节序转换？
字节序问题本身是个很简单的问题, 单独转换某个变量的字节序也是个很简单的问题，只需要一行代码就可以搞定，以32位长的整型为例, 这样一个函数就够了：
Uint32 SwapBytesUint32( Uint32 v )
{
       return (v >> 24) | ((v >> 8) & 0xff00) | ((v << 8) & 0xff0000) | (v << 24) ;
}
但是注意个函数其实有隐患, 当传入参数是浮点数时, 虽然也是32位, 但是编译器会做隐式类型转换，先将浮点数转化为整型, 再对这个整型进行字节序转换。 例如如果传入的是0.5, 会先被转换成0, 然后进行字节序转换后输出还是0。
安全的做法应该是这样：
void SwapBytesUint32_Ptr(Uint32* v)
{
       *v = (*v >> 24) | ((*v >> 8) & 0xff00) | ((*v << 8) & 0xff0000) | (*v << 24) ;
}
但在实际的移植项目中却往往非常麻烦。其根本原因是在于我们无法直接从一段内存中判断一个变量的长度。例如内存中一段数据0x12345678. 他可能是4个char, 也可能是2个short,也可能是1个long. 这3种情况下做字节序转换会得到3种不同的结果。
                  BigEndian                  LittleEndian
4个char         0x12345678         0x12345678
2个short        0x12345678         0x34127856
1个long         0x12345678         0x78563412
因此, 我们必须100%准确的知道他原来是什么类型, 才能做出正确的转换。
--------------------------------------------------------------------------------------
好了，以上其实都是老生常谈，google一搜一大把，但在实际工程应用中要比这个复杂。
首先，很少有项目能够提供完整的准确的数据结构的文档，多数情况我们只能靠猜=.=!
其次，当原始数据结构里面有指针时，单纯遍历容易出现重复转字节序的问题。
例如,这样的数据结构：
struct MapUnit { //地图单元定义
       list< MapUnit *> m_neighbors;
       //data ...
}；
在上面的例子中,如果没有完整的地图单元的列表,而只能通过遍历相邻的地图转字节序时,很容易出现重复转字节序的问题。而且这种问题非常难以debug.
那么在工程中我们如何避免这种问题？从需求出发，我们需要这样一个机制，能够识别出重复转的变量，跳过或者报一个警告。很显然，需要我们在转字节序的时候将转过的变量记录下来。
可以设计一个诸如下面的代码框架：
SWAPBYTES_BEGIN();
       SWAPBYTES_UINT16_VAR(a);
       SWAPBYTES_UINT16_VAR(b);
       SWAPBYTES_UINT16_VAR(c);
       SWAPBYTES_UINT16_VAR(a); //这个时候变量a不会再一次转字节序
       SWAPBYTES_UINT16_VAR(d);
SWAPBYTES_END()
其中SWAPBYTES_BEGIN() / SWAPBYTES_END() 定义了一个代码段,在这一段代码中,对于相同地址的变量,不会进行重复的字节序转换。
具体实现是在调用SWAPBYTES_BEGIN()的时候建立一个以变量地址为key的map, 每次对变量进行字节序转换时，先检测变量的地址是否已在map中, 是的话直接跳过,否则将变量的地址(以及其他辅助信息)添加进来，然后对该变量进行字节序转换。
说实话，做移植项目的字节序转换相当痛苦…… 需要极其细心, 因为任何一个变量的遗漏都会导致bug.
而且代码中会充斥着乱七八糟的SWAPBYTES_XXXX()的代码~~~~~~  我恨移植！！！
如果是原创项目, 就可以比较干净的解决了：）
这里介绍一种方法。 由于字节序问题的本质是在数据写入时丢失了数据长度的信息，因此我们可以在文件头中额外加入文件中每个变量的长度即可。
文件头定义如下：
struct FileHeader {
       char EndianType;
       Uint32 HeaderSize;
       char VarLen[1];
};
其中EndianType标示文件写入时是BigEndian还是LittleEndian, HeaderSize标示整个FileHeader的大小, 由于是32位的, 所以需要根据EndianType进行字节序转换。VarLen是每个变量的长度。 之后根据VarLen中的值,对文件扫描一遍就可以完全转换,不会有遗漏和重复。  这个过程可以是在运行时或者预先转好，取决于实际应用需要。
当然这个方法有一个明显的问题是数据文件会变大，通常会变为原大小的1.5倍。不过由于这种数据比较特殊(通常只是1,2,4这几个数字),有很多压缩方法可以缩小文件头,这里就不一一说明了。