9 
#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>

int main()
{
    FILE* bmp = NULL;
    uint32_t offset;
    uint8_t* temp = NULL;
    size_t read;
    unsigned int x_dim = 600, y_dim = 388;

    bmp = fopen("test_colour.bmp", "r");

    if (!bmp)
        return -1;

    /* Get the image data offset */
    fseek(bmp, 10, SEEK_SET);
    fgets((char*)&offset, 4, bmp);

    printf("Offset = %u\n", offset);

    temp = malloc(3*x_dim*y_dim*sizeof(uint8_t));

    if (!temp)
        return -1;

    /* Go the the position where the image data is stored */
    fseek(bmp, offset, SEEK_SET);

    /* Copy image data to array */
    printf("%u bytes requested!\n", 3*x_dim*y_dim);
    read = fread((void*)temp, sizeof(uint8_t), 3*x_dim*y_dim, bmp);
    printf("%Iu bytes read!\n", read);

    fclose(bmp);
    free(temp);

    return 0;
}

我正在使用上面的代码将每像素 24 位 BMP 图像的 RGB 数据读取到数组中。根据 BMP 规范，从图像数据开始（在 BMP 标头之后）的文件开头的偏移量在偏移量 10 处给出。执行上述代码时，我得到以下输出。

Offset = 54
698400 bytes requested!
33018 bytes read!

偏移量输出似乎是正确的，因为文件大小为 698454 字节（=698400+54）。但是，返回的值fread()似乎表明无法读取整个图像数据。但是，我随后使用temp数组中的数据将 RGB 数据转换为灰度数据并将此数据再次写入 BMP 文件。目视检查输出图像并不表示任何错误，即似乎我实际上首先阅读了整个输入图像，尽管fread()似乎表明不同。

有人可以解释这种行为吗？

4

1 回答 1

31

（我敢打赌你在 Windows 上）

bmp = fopen("test_colour.bmp", "r");

应该

bmp = fopen("test_colour.bmp", "rb");

如果文件在 Windows 上以文本模式打开，运行时将在碰巧碰到 0x1a (Ctrl-Z) 字节时停止读取，Windows 将其视为文本文件的 EOF 标记。即使它没有按 Ctrl-Z，当 Windows 将 CR/LF 序列转换为单个 LF 字符时，您也会得到损坏的数据。

但是，我无法解释为什么您能够从读取的部分文件中获得良好的图像（只是幸运？）。

您可以从缓冲区渲染图像，因为该fread()实现确实将您请求的字节数（或几乎如此 - 数字被四舍五入到某个块大小的倍数）读入缓冲区，然后它扫描缓冲区寻找要转换的 CR/LF 序列和 Ctrl-Z EOF 标志。

所以即使fread()返回33018，缓冲区实际上已经几乎完全写入了文件中的数据。数据不是 100% 正确（例如，一些 CR 字符可能被丢弃）或完整，但在这种情况下，它足够接近以呈现看起来像您预期的图像。

当然，这只是对这个特定运行时当前行为方式的观察——它在未来（甚至在今天的所有系统上）可能并​​不总是这样。

于 2012-07-30T07:53:13.097 回答