简介：这份资源面向希望掌握位图底层原理与BMP文件格式的开发者，尤其适合正在学习图形图像处理、需要动手实现图像文件生成的中初级程序员。压缩包共32个文件，约1.81MB，以C++工程源码为主，包含cpp与h源文件、obj目标文件、pdb调试信息、dsp与dsw工程配置，以及rc资源脚本、ico图标和可直接运行的exe程序，构成一套完整的VC6工程示例。资源围绕位图结构、颜色深度、像素阵列、行填充对齐等关键知识点展开，示例程序演示了如何构造文件头与DIB头、按从下到上的顺序写入像素数据并生成BMP文件。已有1147人学习，读者可借助完整工程对照调试，理解BMP格式规范与二进制文件写入流程，为后续图形处理与图像分析任务打下基础。
1. 从一块内存到一张 BMP：为什么位图格式值得亲手写一遍
很多人第一次接触图像处理，是从cv2.imread或Image.open开始的，读进来就是一个数组，至于文件里到底存了什么，完全是个黑匣子。等到需要把算法生成的像素数据落盘、给嵌入式设备输出一张预览图、或者排查「为什么这张图在某些软件里打开是花的」时，才发现绕不开最原始的位图格式。BMP 就是那个最合适的练手对象：它没有压缩、没有熵编码、没有复杂的元数据容器，文件结构几乎是内存像素阵列的直接映射，把「创建位图」和「生成 BMP 文件」这两件事拆开做一遍，你对像素排布、行对齐、字节序这些概念的理解会扎实很多。
这份资源围绕的就是这条主线：在内存里按位图规则组织像素，再按 BMP 的文件头、信息头、像素数据三段结构写出一个能被系统看图工具正常打开的.bmp文件。适合两类人：一是刚学完数组和文件读写、想找个能看见结果的练手项目的初学者；二是需要在不依赖第三方图像库的环境里自己造一张图、或者要读懂二进制图像格式的从业者。下面按「结构原理 → 编码实现 → 参数调试 → 踩坑排查 → 验证与扩展」的顺序走一遍，代码可以直接抄。
2. BMP 文件结构拆解：三段式布局与行对齐规则
2.1 文件头、信息头、像素阵列各自管什么
BMP 文件从字节 0 开始，可以切成三块。第一块是文件头（BITMAPFILEHEADER），14 字节，管的是「这个文件是什么、像素数据从哪开始」；第二块是信息头（BITMAPINFOHEADER），40 字节，管的是「图像多宽多高、每像素多少位、用什么压缩方式」；第三块才是真正的像素数据。理解这个三段式，后面写代码时每个字段填什么就有依据，而不是照抄一段魔法数字。
文件头的字段排布如下，注意所有多字节整数都是小端序（低位字节在前），这是 Windows 系格式的传统，写文件时必须遵守，否则读图软件会把宽度读成一个天文数字。
| 偏移 | 长度 | 字段 | 说明 |
|---|---|---|---|
| 0 | 2 | bfType | 固定为0x4D42，即字符BM |
| 2 | 4 | bfSize | 整个文件字节数 |
| 6 | 2 | bfReserved1 | 保留，填 0 |
| 8 | 2 | bfReserved2 | 保留，填 0 |
| 10 | 4 | bfOffBits | 像素数据起始位置相对文件开头的偏移 |
信息头紧跟在文件头之后，常用字段如下：
| 偏移 | 长度 | 字段 | 说明 |
|---|---|---|---|
| 0 | 4 | biSize | 本结构大小，填 40 |
| 4 | 4 | biWidth | 图像宽度（像素） |
| 8 | 4 | biHeight | 图像高度（像素），正数表示自下而上存储 |
| 12 | 2 | biPlanes | 固定填 1 |
| 14 | 2 | biBitCount | 每像素位数，常见 24 或 32 |
| 16 | 4 | biCompression | 0 表示不压缩 |
| 20 | 4 | biSizeImage | 像素数据字节数，不压缩时可填 0 或实际值 |
| 24 | 4 | biXPelsPerMeter | 水平分辨率，可填 2835（约 72 DPI） |
| 28 | 4 | biYPelsPerMeter | 垂直分辨率，同上 |
| 32 | 4 | biClrUsed | 调色板颜色数，24/32 位填 0 |
| 36 | 4 | biClrImportant | 重要颜色数，填 0 |
这里有个容易被忽略的点：biHeight为正时，像素是按「最后一行在最前」的顺序存的，也就是图像底部先写。很多人第一次手写 BMP 打开发现图是上下颠倒的，根子就在这。想省事可以把高度写成负数表示自上而下，但兼容性不如老老实实倒序写。
2.2 每行 4 字节对齐：那个让文件大小算错的坑
BMP 规定每一行像素数据的字节数必须是 4 的倍数，不足的用 0 补齐。24 位色下每像素 3 字节，宽度为 3 时一行是 9 字节，要补到 12 字节；宽度为 4 时正好 12 字节不用补。这个规则叫行对齐（row padding），它直接决定了bfSize和bfOffBits怎么算，也是新手最容易算错文件大小的地方。
对齐后的行字节数公式是((width * bytesPerPixel + 3) / 4) * 4，整数除法。像素数据总大小就是「对齐行字节数 × 高度」。文件总大小等于 14 + 40 + 像素数据大小（24 位无调色板的情况）。把这两个数算对，文件头里填的值才不会自相矛盾，否则有的软件宽容能打开，有的严格解析器直接报错。
提示：调试阶段建议先用宽度不是 4 的倍数的尺寸（比如 3×3、5×7）来测，对齐逻辑对不对一眼就能看出来；用 4 的倍数宽度测，补零分支根本没被执行，等于没测。
3. 用 Python 从零生成 BMP：像素缓冲区与二进制写入
3.1 构造像素缓冲区：BGR 顺序与倒序写入
先明确颜色通道顺序。BMP 的 24 位像素按 B、G、R 三字节排列，不是 RGB。如果你从别处拿到的是 RGB 数组，写之前要换序，否则出来的图红蓝互换，人脸变蓝脸，这是血泪经验里最常见的一条。下面这段代码构造一个渐变位图并写出文件，结构清晰，可以直接跑。
import struct def create_bmp(width, height, filepath): bytes_per_pixel = 3 # 每行按 4 字节对齐，计算补齐后的行字节数 row_size = (width * bytes_per_pixel + 3) // 4 * 4 padding = row_size - width * bytes_per_pixel pixel_data_size = row_size * height file_size = 14 + 40 + pixel_data_size offset = 14 + 40 # 文件头：BM 标识、文件大小、保留位、像素偏移 file_header = struct.pack('<2sIHHI', b'BM', file_size, 0, 0, offset) # 信息头：结构大小、宽、高、平面数、位深、压缩、像素大小、分辨率、调色板 info_header = struct.pack('<IiiHHIIiiII', 40, width, height, 1, 24, 0, pixel_data_size, 2835, 2835, 0, 0) rows = [] # BMP 自下而上存储，所以从最后一行开始生成 for y in range(height - 1, -1, -1): row = bytearray() for x in range(width): b = (x * 255) // max(width - 1, 1) # 蓝色随列变化 g = (y * 255) // max(height - 1, 1) # 绿色随行变化 r = 128 # 红色固定 row += bytes((b, g, r)) # 注意顺序是 BGR row += b'\x00' * padding # 行尾补零对齐 rows.append(bytes(row)) with open(filepath, 'wb') as f: f.write(file_header) f.write(info_header) for row in rows: f.write(row) if __name__ == '__main__': create_bmp(37, 23, 'gradient.bmp')struct.pack的第一个参数是格式串，<表示小端序，后面的字母对应字段类型：2s是两字节字符串，I是无符号 4 字节整数，i是有符号 4 字节整数，H是无符号 2 字节整数。信息头里宽度和高度用i而不是I，是为了将来支持负高度（自上而下）时不用改格式串。row_size那行用整数除法实现向上取整到 4 的倍数，padding就是每行要补的零字节数。像素循环里先算 B 再算 G 再算 R，拼进bytearray的顺序必须和 BMP 约定一致。
3.2 参数怎么改：位深、尺寸与分辨率的取舍
上面是 24 位无压缩的写法，改参数时有几个边界要清楚。位深改成 32 时，每像素 4 字节，多出来的一字节是 alpha，但很多看图工具对 32 位 BMP 的 alpha 处理不一致，有的忽略、有的当透明，做通用输出时 24 位更稳。宽度或高度改成 0 或负数要单独处理，负数高度意味着自上而下存储，此时循环方向要反过来，biHeight填负值，其余不变。
分辨率字段biXPelsPerMeter填 2835 对应约 72 DPI，填 11811 对应约 300 DPI，它只影响打印时的物理尺寸提示，不影响屏幕显示。如果生成的图要进排版流程，把这个值按目标 DPI 换算填对，能省掉后期手动改尺寸的麻烦。像素数据大小字段在不压缩时填实际值或 0 都能被接受，但填实际值更利于严格解析器校验。
4. 常见问题排查：图打不开、颜色错、上下颠倒怎么定位
4.1 打开报「无效的图像文件」
现象是双击文件提示格式不支持，或者看图软件直接闪退。原因八成是文件头里的bfSize或bfOffBits和实际写入的字节数对不上，解析器读到越界就放弃。解决方法是写完后用os.path.getsize比对bfSize，再检查bfOffBits是否等于 54（14+40，无调色板时）。如果加了调色板，偏移要相应加上调色板字节数，这一点在改成 8 位色时特别容易漏。
4.2 图像上下颠倒
现象是打开后内容垂直翻转。原因是biHeight填了正值，但像素数据是按从上到下的顺序写的，而格式要求自下而上。解决方法是把生成循环改成从height-1递减到 0，或者把biHeight写成负值并保持自上而下写入。两种都行，但别只改一处，改一半会得到一张既颠倒又错位的图。
4.3 颜色整体偏蓝或偏红
现象是红色区域显示成蓝色。原因是通道顺序写成了 RGB，而 BMP 要 BGR。解决方法是在拼字节时交换首尾通道，或者在写入前对源数组做一次通道翻转。这个错误在从其他图像库导数据时高发，因为那些库内部多用 RGB 或 RGBA。
4.4 图像右侧出现斜向错位条纹
现象是每一行都比上一行偏移一点，形成斜纹。原因是行对齐补零没做，或者补零数量算错，导致解析器按对齐后的行宽读取时错位累积。解决方法是打印出row_size和width*3的差值，确认padding在 0 到 3 之间，并且每行确实写入了对应数量的零字节。
4.5 大尺寸图写入后文件损坏
现象是小图正常、大图打不开。原因可能是宽度乘每像素字节数在某个中间计算里溢出了 16 位，或者一次性把整个像素缓冲区拼成一个大bytes导致内存翻倍。解决方法是全程用 Python 的任意精度整数（默认就是），并且分块写入而不是先拼完整缓冲区，几十兆的图也不会有压力。
5. 验证与扩展：用解析器反读回来，再往 8 位调色板走一步
写完文件不能只看「能打开」，更靠谱的验证是写一个最小的解析器把文件读回来，逐字段比对，这样任何一处填错都会暴露。下面这段代码读回文件头和信息头，并抽样检查第一个像素的 BGR 值，适合放进单元测试里当回归用例。
import struct def inspect_bmp(filepath): with open(filepath, 'rb') as f: data = f.read() bf_type, bf_size, _, _, bf_off = struct.unpack('<2sIHHI', data[:14]) (bi_size, w, h, planes, bit_count, compression, img_size, _, _, _, _) = struct.unpack('<IiiHHIIiiII', data[14:54]) assert bf_type == b'BM', '文件标识不是 BM' assert bf_size == len(data), f'文件头大小 {bf_size} 与实际 {len(data)} 不符' assert bf_off == 54, '像素偏移异常' row_size = (w * 3 + 3) // 4 * 4 first_pixel = data[bf_off:bf_off + 3] # 自下而上，这是左下角像素 print(f'{w}x{h}, {bit_count}bit, 行字节 {row_size}, 首像素 BGR={tuple(first_pixel)}') return w, h inspect_bmp('gradient.bmp')断言里bf_off == 54只对 24 位无调色板成立，换成 8 位色时要按调色板大小调整。首像素取的是文件里第一个像素，由于自下而上存储，它对应图像的左下角，验证渐变方向时别搞反。
想再进一步，可以挑战 8 位调色板 BMP：信息头biBitCount填 8，biClrUsed填 256，在信息头之后、像素数据之前插入 1024 字节的调色板（每项 BGRA 四字节），像素数据每字节是一个调色板索引，行对齐规则不变。这一步做完，你对「索引色」和「真彩色」的区别会有实感，也能理解为什么老式图标文件那么小。我自己的习惯是每写一个新格式的编码器，都配一个反读解析器当后悔药，出问题时不用靠猜。从那以后我每次生成二进制文件都强制走一遍「写—读—断言」的闭环，希望这个习惯也能帮到你。
本文还有配套的精品资源，点击获取
