为什么 fread 会弄乱我的字节顺序？

Question

我正在尝试使用fread() 解析一个 bmp 文件，当我开始解析时，它会颠倒我的字节顺序。

typedef struct{
    short magic_number;
    int file_size;
    short reserved_bytes[2];
    int data_offset;
}BMPHeader;
    ...
BMPHeader header;
    ...

十六进制数据为42 4D 36 00 03 00 00 00 00 00 36 00 00 00； 我正在通过fread(&header,14,1,fileIn); 将十六进制数据加载到结构中

我的问题是幻数应该是0x424d //'BM' fread() 它将字节翻转为0x4d42 // 'MB'

为什么 fread() 会这样做，我该如何解决它；

编辑：如果我不够具体，我需要将整块十六进制数据读取到结构中，而不仅仅是幻数。我只选择了幻数作为例子。

Answer 1

我认为这是一个字节序问题。即您将字节 42 和 4D 放入您的 short 值中。但是您的系统是小端（我可能有错误的名称），它实际上从左到右而不是从右到左读取字节（在多字节整数类型内）。

在此代码中演示：

#include <stdio.h>

int main()
{
    union {
        short sval;
        unsigned char bval[2];
    } udata;
    udata.sval = 1;
    printf( "DEC[%5hu]  HEX[%04hx]  BYTES[%02hhx][%02hhx]\n"
          , udata.sval, udata.sval, udata.bval[0], udata.bval[1] );
    udata.sval = 0x424d;
    printf( "DEC[%5hu]  HEX[%04hx]  BYTES[%02hhx][%02hhx]\n"
          , udata.sval, udata.sval, udata.bval[0], udata.bval[1] );
    udata.sval = 0x4d42;
    printf( "DEC[%5hu]  HEX[%04hx]  BYTES[%02hhx][%02hhx]\n"
          , udata.sval, udata.sval, udata.bval[0], udata.bval[1] );
    return 0;
}

给出以下输出

DEC[    1]  HEX[0001]  BYTES[01][00]
DEC[16973]  HEX[424d]  BYTES[4d][42]
DEC[19778]  HEX[4d42]  BYTES[42][4d]

因此，如果您想要便携，则需要检测系统的字节序，然后在需要时进行字节洗牌。互联网上有很多交换字节的例子。

后续问题：

我问只是因为我的文件大小是 3 而不是 196662

这是由于内存对齐问题。 196662 是字节 36 00 03 00，3 是字节 03 00 00 00。大多数系统需要像int 这样的类型，而不是在多个内存words 上拆分。如此直观地，您认为您的结构在内存中布局如下：

                          Offset
short magic_number;       00 - 01
int file_size;            02 - 05
short reserved_bytes[2];  06 - 09
int data_offset;          0A - 0D

但是在 32 位系统上，这意味着 files_size 在与 magic_number 相同的 word 中有 2 个字节，在下一个 word 中有两个字节。大多数编译器不会支持这一点，所以结构在内存中的布局方式实际上是这样的：

short magic_number;       00 - 01
<<unused padding>>        02 - 03
int file_size;            04 - 07
short reserved_bytes[2];  08 - 0B
int data_offset;          0C - 0F

因此，当您读取 36 00 中的字节流时，您的填充区域将让您的 file_size 得到 03 00 00 00。现在，如果您使用fwrite 创建此数据，它应该没问题，因为填充字节会被写出。但是，如果您的输入总是采用您指定的格式，那么将整个结构与 fread 一起读取是不合适的。相反，您需要单独阅读每个元素。

Answer 2

这不是fread 的错，而是你的CPU（显然）是小端的。也就是说，您的 CPU 将 short 值中的第一个字节视为 低 8 位，而不是（如您所料）高 8 位。

每当您读取二进制文件格式时，您必须将文件格式的字节序显式转换为 CPU 的原生字节序。您可以使用以下函数来做到这一点：

/* CHAR_BIT == 8 assumed */
uint16_t le16_to_cpu(const uint8_t *buf)
{
   return ((uint16_t)buf[0]) | (((uint16_t)buf[1]) << 8);
}
uint16_t be16_to_cpu(const uint8_t *buf)
{
   return ((uint16_t)buf[1]) | (((uint16_t)buf[0]) << 8);
}

您将fread 放入适当大小的uint8_t 缓冲区，然后手动将所有数据字节复制到BMPHeader 结构中，并根据需要进行转换。看起来像这样：

/* note adjustments to type definition */
typedef struct BMPHeader
{
    uint8_t magic_number[2];
    uint32_t file_size;
    uint8_t reserved[4];
    uint32_t data_offset;
} BMPHeader;

/* in general this is _not_ equal to sizeof(BMPHeader) */
#define BMP_WIRE_HDR_LEN (2 + 4 + 4 + 4)

/* returns 0=success, -1=error */
int read_bmp_header(BMPHeader *hdr, FILE *fp)
{
    uint8_t buf[BMP_WIRE_HDR_LEN];

    if (fread(buf, 1, sizeof buf, fp) != sizeof buf)
        return -1;

    hdr->magic_number[0] = buf[0];
    hdr->magic_number[1] = buf[1];

    hdr->file_size = le32_to_cpu(buf+2);

    hdr->reserved[0] = buf[6];
    hdr->reserved[1] = buf[7];
    hdr->reserved[2] = buf[8];
    hdr->reserved[3] = buf[9];

    hdr->data_offset = le32_to_cpu(buf+10);

    return 0;
}

您确实不假设CPU的字节顺序与文件格式的相同即使您知道现在它们是相同的；无论如何，您都要编写转换，以便将来您的代码无需修改即可在具有相反字节序的 CPU 上运行。

您可以通过使用固定宽度的<stdint.h> 类型、使用无符号类型（除非绝对需要能够表示负数）以及不在字符时使用整数来让自己的生活更轻松数组会做。我在上面的例子中做了所有这些事情。你可以看到你不需要对幻数进行字节序转换，因为你唯一需要做的就是测试magic_number[0]=='B' && magic_number[1]=='M'。

相反方向的转换，顺便说一句，如下所示：

void cpu_to_le16(uint8_t *buf, uint16_t val)
{
   buf[0] = (val & 0x00FF);
   buf[1] = (val & 0xFF00) >> 8;
}
void cpu_to_be16(uint8_t *buf, uint16_t val)
{
   buf[0] = (val & 0xFF00) >> 8;
   buf[1] = (val & 0x00FF);
}

32 位/64 位量的转换留作练习。

Answer 3

将结构写入文件是高度不可移植的——根本不尝试这样做是最安全的。只有在以下情况下才能保证使用这样的结构：a) 结构既作为结构写入又作为结构读取（从不是字节序列），并且 b) 它总是在同一（类型的）机器上写入和读取。不仅存在不同 CPU 的“字节序”问题（这似乎是您遇到的问题），还有“对齐”问题。不同的硬件实现对于仅将整数放置在偶数 2 字节甚至 4 字节甚至 8 字节边界上具有不同的规则。编译器完全了解这一切，并将隐藏的填充字节插入到您的结构中，因此它始终可以正常工作。但是由于隐藏的填充字节，假设结构的字节像你想象的那样布置在内存中是不安全的。如果你很幸运，你在一台使用 big-endian 字节顺序并且完全没有对齐限制的计算机上工作，所以你可以将结构直接放在文件上并让它工作。但你可能没那么幸运——当然，需要“可移植”到不同机器的程序必须避免尝试将结构直接放在任何文件的任何部分。