C++将整型数据转换成大端或小端存储顺序

大端和小端的概念参考之前博客： 大端/小端，高字节/低字节，高地址/低地址，移位运算

昨晚帮导师从指令中恢复图像的时候，导师要我转换成raw格式，也就是记录图像像素的二进制序列，然后反复强调让我注意大端小端。当时我也没在意，用ofstream的write方法一个个地写进去，发现有部分数据存储顺序和其他的不一致。由于时间要紧，我立刻试了下FILE*然后用"wb"模式打开文件来写，刚好要求的也是小端（因为我的win7系统就是小端存储），结果对了当时也就没管为什么之前C++的ofstream只有部分正确了。

查看了官方文档 http://www.cplusplus.com/reference/fstream/ofstream/open/

open的第二个参数是打开模式的选项，其中有一个是ios_base::binary，代表二进制读写，我没有加上这个选项所以才会在写入二进制文件时出现问题。设置这个选项在写入二进制文件的时候就会和系统存储顺序一样了。

    ofstream fout;
    fout.open("image2.raw", ios_base::binary);

想起我之前也踩过fopen的坑，linux下不区分文本文件和二进制文件，所以"r"和"w"通用，但是windows下区分这两者，于是要用"rb"和"wb"。而C++为了便于跨平台，为了这种区分文本和二进制的系统加上了binary打开方式。

说起来这里我用的ios_base::binary是没问题的，但是官网ofstream::write()函数的示例代码用的是ofstream::binary，看了眼微软的实现，ofstream直接继承的ios_base的binary字段，所以两者是等价的。考虑设计者在设计的时候可能会认为继承自ios_base的类会做些修改吧，这里用ofstream::binary更为妥当。

 

再回到大端小端的问题，如果是要跨平台地按照小端顺序写入文件是怎样呢？因为可能你在小端机器上写入的，在大端机器上读取的就会是错误的数值。

网络编程中处理这个的手段是用htonl和htons库函数，通过隐藏底层细节的转换函数，把多字节整型统一按照网络字节序（大端）来存储。但是有时候仍然需要使用小端来存储，所以还是要会手写转换函数，这里以小端为例。

比如对4字节整型：0x11223344，转换成小端是：0x44 0x33 0x22 0x11。

0x44 = 0x11223344 & 0xFF

0x33 = (0x11223344 & 0xFF00) >> 8

0x22 = (0x11223344 & 0xFF0000) >> 16

0x11 = (0x11223344 & 0xFF000000) >> 24

另外，可以发现0xFF00即0xFF<<8，因此，可以很自然地用一个循环实现这个逻辑。

对于2字节和8字节的整型也是类似，所以可以用一个简单的函数模板来实现。

#include 

template  // T must be integer type
T to_little_endian(T x)
{
    size_t n = sizeof(T) / sizeof(uint8_t); // 2,4,8

    T res;
    uint8_t* p = (uint8_t*) &res;
    
    for (size_t i = 0; i < n; i++)
    {
        int offset = 8 * i;
        p[i] = (x & (0xFF << offset)) >> offset;
    }

    return res;
}

看似这个实现没什么问题，来写份测试代码看看

    uint16_t i1 = 0x1122;
    uint32_t i2 = 0x11223344;
    uint64_t i3 = 0x1122334455667788;
    printf("%04x => %04x\n", i1, to_little_endian(i1));
    printf("%08x => %08x\n", i2, to_little_endian(i2));
    printf("%016lx => %016lx\n", i3, to_little_endian(i3));

结果如下，8字节整型转换出错

1122 => 1122
11223344 => 11223344
1122334455667788 => 1100000055667788

调试发现原因是0xFF，这个整型字面值的默认类型是int，对于类型uint64_t（unsigned long long），int向左移位会造成溢出。所以需要显式地把0xFF转换为uint64_t类型。对于这个函数模板而言，0xFF << offset表示的是x将低位全部置为0，并舍弃高位，所以结果是不大于x的，那么这里0xFF只用转换成T即可。

修改后的代码：

template  // T must be integer type
T to_little_endian(T x)
{
    size_t n = sizeof(T) / sizeof(uint8_t); // 2,4,8

    T res;
    uint8_t* p = (uint8_t*) &res;
    T mask = static_cast(0xFF);
    
    for (size_t i = 0; i < n; i++)
    {
        int offset = 8 * i;
        p[i] = (x & (mask << offset)) >> offset;
    }

    return res;
}

至于大端，只需要把int offset = 8 * i改成int offset = 8 * (n - i - 1)即可。

OK，说实话C++的坑真是不少，类型方面的陷阱真不少。刚才用cout打印uint8_t类型的时候也是，必须强制转换成int，因为uint8_t和char都是1字节，所以operator<<模板会将类型识别成char，并用打印字符的方式来打印。

转载于:https://www.cnblogs.com/Harley-Quinn/p/7664904.html