C++读取BMP需先校验文件头:bfType必须为0x4D42("BM"),bfOffBits≥头大小且不超文件长,biBitCount限1/4/8/16/24/32;像素数据自下而上存储、每行4字节对齐、BGR顺序。
直接读取 BMP 文件前,必须先校验文件头是否合法,否则后续解析会崩溃或读错数据。关键不是“能不能读”,而是“读到的到底是不是真 BMP”。
BITMAPFILEHEADER 前两个字节必须是 0x42 0x4D(即 ASCII "BM"),否则直接返回错误bfOffBits 字段决定像素数据起始位置,它必须 ≥ sizeof(BITMAPFILEHEADER) + sizeof(BITMAPINFOHEADER),且不能超过文件大小BITMAPINFOHEADER::biBitCount 必须是 1、4、8、16、24 或 32,其他值(如 15、30)虽在某些 Windows 版本中被容忍,但标准不支持,fread 后可能解码错乱fread 可用,但跨平台时需手动翻转字段(如 biWidth、biHeight)
FILE* fp = fopen("test.bmp", "rb");
if (!fp) { /* 错误处理 */ }
BITMAPFILEHEADER bmfh;
fread(&bmfh, sizeof(bmfh), 1, fp);
if (bmfh.bfType != 0x4D42) { // 'M' 'B',注意小端存储顺序
fclose(fp);
return -1;
}
BMP 的像素数据从图像左下角开始存储,逐行向上,且每行字节数必须是 4 的倍数——这是 Windows GDI 的硬性要求,不是可选行为。
biHeight 为正数表示“自下而上”存储;为负数表示“自上而下”(Windows NT+ 支持,但多数生成器仍用正值)((biWidth * biBitCount + 31) / 32) * 4,即向上对齐到 4 字节边界;原始宽度字节数不足时,末尾补 0x00
biWidth * 3 直接读 24 位图,遇到宽度为 101 像素时就会越界(实际每行占 304 字节,而非 303)biHeight 倒序拷贝行,或修改渲染逻辑24 位 BMP 最常见,但操作时最容易因对齐和顺序栽跟头。不要假设内存布局和磁盘布局一致。
rowSize = ((width * 24 + 31) / 32) * 4,别用 width * 3
rowSize * abs(height) 分配,而不是 width * height * 3
fseek(fp, bmfh.bfOffBits, SEEK_SET) 跳过头,再逐行 fread(lineBuffer, 1, rowSize, fp)
rowSize > width * 3,需补 0 到末尾(可用 memset 填充)blue、green、red;直接丢给 OpenGL / SDL 显示前必须交换 R/Bint width = bi.biWidth; int height = bi.biHeight; int rowSize = ((width * 24 + 31) / 32) * 4; std::vectorpixelData(rowSize * abs(height)); fseek(fp, bmfh.bfOffBits, SEEK_SET); for (int i = 0; i < abs(height); ++i) { int srcRow = (height > 0) ? (abs(height) - 1 - i) : i; // 自下而上 → 自上而下 fread(pixelData.data() + srcRow * rowSize, 1, rowSize, fp); }
手动生成 BMP 文件头时,90% 的失败源于这三个字段没算准,导致系统拒绝打开或显示为黑图。
bfSize 必须等于整个文件字节数:即 sizeof(BITMAPFILEHEADER) + sizeof(BITMAPINFOHEADER) + pixelDataSize,少 1 字节都不行biSizeImage 必须等于 rowSize * abs(height);设为 0 在部分旧工具中会被忽略,但新版本(如 Windows 10 Photo App)会直接报“损坏的图像”bfOffBits 必须等于 sizeof(BITMAPFILEHEADER) + sizeof(BITMAPINFOHEADER)(无调色板时);若有调色板(如 8 位图),还要加上调色板字节数(256 * sizeof(RGBQUAD))这些字段之间强耦合,改一个就得重算另外两个。建议封装成函数,传入 width/height/bits,自动填全。