分析未知文件数据结构格式时需要熟悉不同文件类型的一种或多种该类公开文件的数据存储格式，因为通常情况下未知文件数据结构格式很可能是在公开的文 件格式上建立起来的，或只稍微修改了一些地方。编程人员一般不会自己发明一种文件格式，因为编程人员大多数都很"懒"，他们通常的做法是参考一些公开文件 的格式，稍微修改一下。
例如，如果要分析的未知文件格式是属于图像类的，那么这个未知的图像文件格式必定与BMP文件格式有相似的地方。熟悉BMP格式对研究和分析这个未知的图像文件格式有极大的帮助，如果掌握了BMP图像文件存储格式就可以利用BMP格式去匹配和猜测未知图像文件格式。
例如，如要分析的未知文件格式是属于3D模型的，那么这个未知的3D模型文件格式必定与3DS和X文件格式有相似的地方，所以研究未知的3D模型文件前需要先参考和学习一些常见的公开格式的模型文件，这与解密某个加密算法之前需要研究一些公开的加密算法是同一个道理。
因为本书是针对游戏资源文件解密，所以下面将要介绍和分析游戏资源文件的常用文件存储格式。游戏资源文件大体上可以归到多媒体数据格式上，学习和研究这些多媒体文件格式对日后分析未知的游戏资源文件格式有很大帮助。
通过本章的学习读者可以掌握以下内容：
BMP图像文件格式；
PNG图像文件格式；
X模型文件格式；
md3模型文件格式。
BMP图像文件格式
BMP图像文件格式是游戏中常用的图像资源文件格式，BMP图像文件起源早，程序员对BMP都比较熟悉，再加上BMP格式简单，读取和写入非常容易实现，所以无论Windows的还是Driect X，都有支持读取和写入BMP文件格式的API函数。
针对BMP压缩的算法比较成熟，压缩效果也不差，而且都是无损压缩编码，即可以100%还原BMP图像质量。
虽然JPG格式压缩效果比较理想，但游戏编程人员一般极少使用，因为JPG要牺牲图像的质量来换取大的压缩率，加上JPG解码速度较慢和格式复杂， 所以游戏中使用JPG格式的图像的情况不多（笔者目前只发现一款网络游戏使用JPG格式作为游戏里的图像格式，并且使用额外的数据保存了图像中的透明通道 信息来让JPG支持透明色）。GIF格式虽然支持多帧动画效果，但GIF最大仅支持256色，不能表达色彩丰富的图像，所以对于对速度要求非常苛刻而且图 像质量要高的游戏来说，使用BMP格式存储图像是不错的选择。
BMP图像文件介绍
MP图像文件格式是微软公司发明的，BMP图像文件的后缀名通常是.BMP，但也有少数是.DIP。不过单凭文件的后缀名并不能惟一确定是不是BMP图像文件，要惟一确定BMP图像文件还需要分析文件的存储格式。
BMP图像文件和GIF图像文件不同，BMP图像文件只能存储一幅图像，即一帧。GIF图像文件能保存多帧图像，从而可以实现动画的效果。
BMP图像文件支持单色、16色、256色和真彩色4种颜色的图像。BMP图像的数据即可压缩也可以不压缩，如果选择了压缩数据，那么根据颜色的不同，BMP使用不同的RLE压缩方式。
RLE是一种无损压缩方法，使用RLE压缩的数据能完整还原。如果图像是16色，则可以采用RLE4压缩，如果图像是256色，则可以采用RLE8压缩，真彩色的图像不使用压缩。
BMP的图像数据排列方式有点特别，BMP的图像数据排列方式首先从图像的左下角第一个像素开始存储每一行数据，即BMP图像数据存储的最后一个像素等于实际图像的右上角第一个像素。
BMP图像文件存储结构（1）
BMP文件存储结构的格式可以在Windows中的WINGDI.h文件中找到定义。
BMP文件总体上由4部分组成，分别是位图文件头、位图信息头、调色板和图像数据，如表5-1所示。
表5-1 BMP文件的组成结构
| 位图文件头（bitmap-file header） |
| 位图信息头（bitmap-information header） |
| 彩色表/调色板（color table） |
| 位图数据（bitmap-data） |
位图文件头（bitmap-file header）
位图文件头（bitmap-file header）包含了图像类型、图像大小、图像数据存放地址和两个保留未使用的字段。
打开WINGDI.h文件，搜索"BITMAPFILEHEADER"就可以定位到BMP文件的位图文件头的数据结构定义。
typedef struct tagBITMAPFILEHEADER {
W
D
W
W
D
} BITMAPFILEHEADER, FAR *LPBITMAPFILEHEADER, *PBITMAPFILEHEADER;
列出了tagBITMAPFILEHEADER中各字段的含义。
tagBITMAPFILEHEADER结构
| 字 段 名 | 大小（单位：字节） | 描 述 |
| bfType | 2 | 位图类别，根据不同的操作 系统而不同，在Windows 中，此字段的值总为‘BM’ |
| bfSize | 4 | BMP图像文件的大小 |
| bfReserved1 | 2 | 总为0 |
| bfReserved2 | 2 | 总为0 |
| bfOffBits | 4 | BMP图像数据的地址 |
位图信息头（bitmap-information header）包含了位图信息头的大小、图像的宽高、图像的色深、压缩说明图像数据的大小和其他一些参数。
打开WINGDI.h文件，搜索"tagBITMAPINFOHEADER"就可以定位到BMP文件的位图信息头的数据结构定义。
typedef struct tagBITMAPINFOHEADER{
D
L
L
W
W
D
D
L
L
D
D
} BITMAPINFOHEADER, FAR *LPBITMAPINFOHEADER, *PBITMAPINFOHEADER;
列出了tagBITMAPFILEHEADER中各字段的含义。
tagBITMAPFILEHEADER结构
| 字 段 名 | 大小 （单位： 字节） | 描 述 |
| biSize | 4 | 本结构的大小，根据不同的操作系统而不同，在Windows中，此字段的值总为28h字节=40字节 |
| biWidth | 4 | BMP图像的宽度，单位像素 |
| biHeight | 4 | BMP图像的高度，单位像素 |
| biPlanes | 2 | 位图的位面数，总为1 |
| biBitCount | 2 | BMP图像的色深，即一个像素用多少位表示，常见有1、4、8、16、24和32，分别对应单色、16色、256色、16位高彩色、24位真彩色和32位增强型真彩色 |
| biCompression | 4 | 压缩方式，0表示不压缩，1表示RLE8压缩，2表示RLE4压缩，3表示每个像素值由指定的掩码决定 |
| biSizeImage | 4 | BMP图像数据大小，必须是4的倍数，图像数据大小不是4的倍数时用0填充补足 |
| biXPelsPerMeter | 4 | 水平分辨率，单位像素/m |
| biYPelsPerMeter | 4 | 垂直分辨率，单位像素/m |
| biClrUsed | 4 | BMP图像使用的颜色，0表示使用全部颜色，对于256色位图来说，此值为100h=256 |
| biClrImportant | 4 | 重要的颜色数，此值为0时所有颜色都重要，对于使用调色板的BMP图像来说，当显卡不能够显示所有颜色时，此值将辅助驱动程序显示颜色 |
彩色表/调色板（color table）
彩色表/调色板（color table）是单色、16色和256色图像文件所特有的，相对应的调色板大小是2、16和256，调色板以4字节为单位，每4个字节存放一个颜色值，图像的数据是指向调色板的索引。
可以将调色板想象成一个数组，每个数组元素的大小为4字节，假设有一256色的BMP图像的调色板数据为：
调色板[0]=黑、调色板[1]=白、调色板[2]=红、调色板[3]=蓝…调色板[255]=黄
图像数据01 00 02 FF表示调用调色板[1]、调色板[0]、调色板[2]和调色板[255]中的数据来显示图像颜色。
在早期的计算机中，显卡相对比较落后，不一定能保证显示所有颜色，所以在调色板中的颜色数据应尽可能将图像中主要的颜色按顺序排列在前面，位图信息头的biClrImportant字段指出了有多少种颜色是重要的。
每个调色板的大小为4字节，按蓝、绿、红存储一个颜色值。
打开WINGDI.h文件，搜索"tagRGBTRIPLE"就可以定位到BMP文件的调色板的数据结构定义。
typedef struct tagRGBQUAD {
B
B
B
B
} RGBQUAD;
列出了tagRGBTRIPLE中各字段的含义。
tagRGBTRIPLE结构
| 字 段 名 | 大小（单位：字节） | 描 述 |
| rgbBlue | 1 | 蓝色值 |
| rgbGreen | 1 | 绿色值 |
| rgbRed | 1 | 红色值 |
| rgbReserved | 1 | 保留，总为0 |
如果图像是单色、16色和256色，则紧跟着调色板的是位图数据，位图数据是指向调色板的索引序号。
如果位图是16位、24位和32位色，则图像文件中不保留调色板，即不存在调色板，图像的颜色直接在位图数据中给出。
16位图像使用2字节保存颜色值，常见有两种格式：5位红5位绿5位蓝和5位红6位绿5位蓝，即555格式和565格式。555格式只使用了15位，最后一位保留，设为0。
24位图像使用3字节保存颜色值，每一个字节代表一种颜色，按红、绿、蓝排列。
32位图像使用4字节保存颜色值，每一个字节代表一种颜色，除了原来的红、绿、蓝，还有Alpha通道，即透明色。
如果图像带有调色板，则位图数据可以根据需要选择压缩与不压缩，如果选择压缩，则根据BMP图像是16色或256色，采用RLE4或RLE8压缩算法压缩。
RLE4是压缩16色图像数据的，RLE4采用表5-5所示方式压缩数据。
表5-5 RLE4压缩方法
| 方案 | 1字节 | 2字节 | 3字节 | 4字节 | N字节 |
| A | 重复次数 | 颜色索引 | |||
| B | 设为0 | 后面有效的 颜色索引数 | 颜色索引 | 颜色索引 | 颜色索引… |
05 00 04 05 00 08 09 05 04 00 04 05 08 09 04 08 07 01 00 00
数据解压时首先读取05，因为05不等于0，所以选择A方案，根据A方案，05表示后面数据重复的次数，接着读取00，00表示有两个颜色索引，每 个索引占4位，第一个像素在高4位，第二个像素在低4位，即在一个字节中低像素在高位，高像素在低位。05 00解压后等于00 00 0。
读取04，选择A方案，按照上面的操作解析，04是后面数据重复的次数，05是两个颜色索引，第3个颜色索引为5，第4个颜色索引为0。04 05解压后等于05 05。
读取00，选择B方案，读取08，08表示后面有效的颜色索引数。00 08解压后等于09 05 04 00。
读取04，选择A方案，按照上面的操作解析，04是后面数据重复的次数，05是两个颜色索引。04 05解压后等于05 05。
读取08，选择A方案，按照上面的操作解析，08是后面数据重复的次数，09是两个颜色索引。08 09解压后等于09 09 09 09。
读取04，选择A方案，按照上面的操作解析，04是后面数据重复的次数，08是两个颜色索引。04 08解压后等于08 08。
读取07，选择A方案，按照上面的操作解析，07是后面数据重复的次数，01是两个颜色索引。07 01解压后等于01 01 01 0。
读取00，选择B方案，读取00，00表示后面有效的颜色索引数，0表示无，即解压完一行数据。
综合上面的操作，解压后的数据为：
00 00 00 50 50 90 50 40 00 50 50 90 90 90 90 80 80 10 10 10
看上去和原来的数据大小一样，没有体现到压缩效果，这是因为上面的例子只选择了20字节数据，而且这20字节数据中重复的数据不多，使用RLE压缩 重复数据不多的数据时，有时可能压缩后的大小反而比原来的数据还大。其实一般情况下当数据比较多而且重复的时候，使用RLE压缩效果还是比较理想的。
RLE8的压缩方式可以参考上面的RLE4解压方法，惟一的区别是RLE8使用1个字节存放颜色索引，而RLE4使用4位存放颜色索引。
分析BMP图像文件结构（1）
结合上面对BMP文件的分析，下面分别对256色和24位色的BMP图像进行十六进制分析，通过在十六进制编辑器中分析文件结构，能够增加分析文件的经验。
如图5-1和图5-2所示，分别为256色BMP图像和24位色BMP图像。其中图像的分辨率为200×153，文件大小为31 680字节。图像的分辨率为200×150，文件大小为90 056字节。
| 图图像 |
| 图图像 |
| （点击查看大图）图5-3 在Winhex中打开图像文件 |
| （点击查看大图）图图像文件的位图文件头 |
| 十六进制值 | 描 述 |
| 42 4D： | BM的ASCII值，在Windows中的BMP文件标识符 |
| C0 7B 00 00 | 7B C0h=31680，是cat2文件的大小 |
| 00 00 00 00 | 保留值，总为0 |
| 36 04 00 | 436h=1078，是图像数据的地址，即文件头+信息头+调色板的长度 |
继续分析接下来的数据，根据BMP文件结构的定义，接下来的数据是位图信息头，图像文件的位图信息头的内容如图5-5所示。
| （点击查看大图）图图像的位图信息头 |
表图像文件中位图信息头各字段的含义
| 十六进制值 | 描 述 |
| 28 00 00 00： | 图像的位图信息头大小 |
| C8 00 00 00 | 00 00 00 C8 = 200，是cat2图像的宽度，单位像素 |
| 99 00 00 00 | 00 00 00 99 = 153，是cat2图像的高度，单位像素 |
| 01 00 | 总是1 |
| 08 00 | 00 08 = 8，cat2图像的色深，即2的8次幂等于256色 |
| 00 00 00 00 | 压缩方式，0表示不压缩 |
| 8A 77 00 00 | 00 00 77 8A = 30602，是cat2图像的图像数据大小，单位字节 |
| 12 0B 00 00 | 00 00 0B 12 = 2834，cat2图像的水平分辨率，单位像素/m |
| 12 0B 00 00 | 00 00 0B 12 = 2834，cat2图像的垂直 分辨率，单位像素/m |
| 00 00 00 00 | cat2图像使用的颜色数，0表示使用全部颜色 |
| 00 00 00 00 | cat2图像中重要的颜色数，0表示所有颜色都重要 |
| （点击查看大图）图图像的调色板地址从00000036h开始存储 |
| （点击查看大图）图图像的调色板数据结束地址是00000435h |
如果想查看cat2图像的调色板对应的实际显示颜色，可以使用Adobe Photoshop CS打开，在Adobe Photoshop CS的菜单栏中选择"图像"→"模式"→"颜色表"，即可观看cat2的调色板，如图5-8所示。
| 图5-8 在Adobe Photoshop CS中查看cat2的调色板 |
图5-8所示的调色板颜色和图5-6中的十六进制数据是一一对应的。在Adobe Photoshop CS的调色板上单击任何一个像素的颜色即可弹出一个拾色器对话框显示该像素颜色的详细组成信息。调色板和的十六进制数据 的对应关系如图5-9所示。
继续分析接下来的数据，根据BMP文件结构的定义，如果一个图像有调色板，那么紧跟在调色板后面的是图像的数据，这些数据不是实际的颜色值，而是指向调色板数组的索引，根据索引来获取调色板中的颜色，如图5-10所示。
| （点击查看大图）图调色板和的十六进制数据的对应关系 |
| （点击查看大图）图的图像数据 |
图像是24位色图像，根据BMP文件结构定义得知，图像没有调色板，图像数据存储的是实际的颜色数据，每个像素用 3字节表示，分别是红绿蓝。由于和的位图文件头和位图信息头结构一样，所以的位图文件头和位图信息头可 以参考上面对的分析，下面从的位图信息头结束的位置开始分析，如图5-11所示。
| （点击查看大图）图图像的图像数据 |
通过上面对BMP文件存储结构的分析发现，BMP文件的位图文件头和位图信息头存在着大量的重复数据。如果存储大量同一色深的BMP位图，必然会浪 费大量存储空间，所以很多时候游戏编程人员都会去掉BMP文件头和信息头，只保留几个必要的信息和图像数据，那么BMP文件头和信息头中哪几个字段是必须 保留的呢？
使用Winhex的文件比较功能比较两个24位色深的BMP图像文件，观察两个文件的文件头和信息头有什么不同的地方，如图5-12所示。
| （点击查看大图）图5-12 使用Winhex比较两个24位色深的BMP图像文件 |
所以很多时候，游戏编程人员只保留图像文件的文件大小、图像宽度、图像高度和图像数据大小信息，甚至有时不需要保留文件大小这个数值，使用图像数据大小数值即可。
在分析未知文件存储格式时，如果遇到去掉了文件头的文件时，如上面所说的BMP文件，会给分析未知文件格式带来一定的困难。这时需要使用十六进制编 辑器的文件比较功能，观察两个同类的未知文件格式寻找某些潜在的规律，如果实在观察不出规律的，那只能使用白盒分析方法，对调用此未知文件格式的程序进行 反汇编跟踪调试了。当然，有时灵感和运气也很重要。
CreateDIBSection
理解分辨率
我们常说的屏幕分辨率为0×480，刷新频率为70Hz，意思是说每行要扫描0个象素，一共有480行，每秒重复扫描屏幕70次。
理解调色板
有一个长宽各为200个象素，颜色数为16色的彩色图，每一个象素都用R、G、B三个分量表示。因为每个分量有 256个级别，要用8位(bit)，即一个字节(byte)来表示，所以每个象素需要用3个字节。整个图象要用200×200×3，约120k字节，可不 是一个小数目呀！如果我们用下面的方法，就能省的多。
因为是一个16色图，也就是说这幅图中最多只有16种颜色，我们可以用一个表：表中的每一行记录一种颜色的R、G、B值。这样当我们表示一个象素的颜色时，只需要指出该颜色是在第几行，即该颜色在表中的索引值。举个例子，如果表的第0行为255，0，0(红色)，那么当某个象素为红色时，只需要标明0即可。
让我们再来计算一下：16种状态可以用4位(bit)表示，所以一个象素要用半个字节。整个图象要用200×200×0.5，约20k字节，再加上表占用的字节为3×16=48字节.整个占用的字节数约为前面的1/6，省很多吧？
这张R、G、B的表，就是我们常说的调色板(Palette)，另一种叫法是颜色查找表LUT(Look Up Table)，似乎更确切一些。Windows位图中便用到了调色板技术。其实不光是Windows位图，许多图象文件格式如pcx、tif、gif等都用到了。所以很好地掌握调色板的概念是十分有用的。
有一种图，它的颜色数高达256×256×256种，也就是说包含我们上述提到的R、G、B颜色表示方法中所有的颜色，这种图叫做真彩色图(true color)。真彩色图并不是说一幅图包含了所有的颜色，而是说它具有显示所有颜色的能力，即最多可以包含所有的颜色。表示真彩色图时，每个象素直接用R、G、B三个分量字节表示，而不采用调色板技术。原因很明显：如果用调色板，表示一个象素也要用24位，这是因为每种颜色的索引要用24位(因为总共有224种颜色，即调色板有224行)，和直接用R，G，B三个分量表示用的字节数一样，不但没有任何便宜，还要加上一个256×256×256×3个字节的大调色板。所以真彩色图直接用R、G、B三个分量表示，它又叫做24位色图。
bmp文件格式
介绍完位图和调色板的概念，下面就让我们来看一看Windows的位图文件文件)的格式是什么样子的。
bmp文件大体上分成四个部分，如图1.3所示。
| 位图文件头BITMAPFILEHEADER |
| 位图信息头BITMAPINFOHEADER |
| 调色板Palette |
| 实际的位图数据ImageDate |
第一部分为位图文件头BITMAPFILEHEADER，是一个结构，其定义如下：
typedef struct tagBITMAPFILEHEADER {
W bfType;
DWORD bfSize;
W bfReserved1;
W bfReserved2;
DWORD bfOffBits;
} BITMAPFILEHEADER;
这个结构的长度是固定的，为14个字节(WORD为无符号16位整数，DWORD为无符号32位整数)，各个域的说明如下：
bfType
指定文件类型，必须是0x424D，即字符串“BM”，也就是说所有文件的头两个字节都是“BM”。
bfSize
指定文件大小，包括这14个字节。
bfReserved1，bfReserved2
为保留字，不用考虑
bfOffBits
为从文件头到实际的位图数据的偏移字节数，即图1.3中前三个部分的长度之和。
第二部分为位图信息头BITMAPINFOHEADER，也是一个结构，其定义如下：
typedef struct tagBITMAPINFOHEADER{
DWORD biSize;
L biWidth;
L biHeight;
W biPlanes;
W biBitCount
DWORD biCompression;
DWORD biSizeImage;
L biXPelsPerMeter;
L biYPelsPerMeter;
DWORD biClrUsed;
DWORD biClrImportant;
} BITMAPINFOHEADER;
这个结构的长度是固定的，为40个字节(LONG为32位整数)，各个域的说明如下：
biSize
指定这个结构的长度，为40。
biWidth
指定图象的宽度，单位是象素。
biHeight
指定图象的高度，单位是象素。
biPlanes
必须是1，不用考虑。
biBitCount
指定表示颜色时要用到的位数，常用的值为1(黑白二色图), 4(16色图), 8(256色), 24(真彩色图)(新的格式支持32位色，这里就不做讨论了)。
biCompression
指定位图是否压缩，有效的值为 BI_RGB，BI_RLE8，BI_RLE4，BI_BITFIELDS(都是一些Windows定义好的常量)。要说明的是，Windows位图可以 采用RLE4，和RLE8的压缩格式，但用的不多。我们今后所讨论的只有第一种不压缩的情况，即biCompression为BI_RGB的情况。
biSizeImage
指定实际的位图数据占用的字节数，其实也可以从以下的公式中计算出来：
biSizeImage=biWidth’ × biHeight
要注意的是：上述公式中的biWidth’必须是4的 整倍数(所以不是biWidth，而是biWidth’，表示大于或等于biWidth的，最接近4的整倍数。举个例子，如果biWidth=240，则 biWidth’=240；如果biWidth=241，biWidth’=244)。
如果biCompression为BI_RGB，则该项可能为零
biXPelsPerMeter
指定目标设备的水平分辨率，单位是每米的象素个数，关于分辨率的概念，我们将在第4章详细介绍。
biYPelsPerMeter
指定目标设备的垂直分辨率，单位同上。
biClrUsed
指定本图象实际用到的颜色数，如果该值为零，则用到的颜色数为2biBitCount。
biClrImportant
指定本图象中重要的颜色数，如果该值为零，则认为所有的颜色都是重要的。
第三部分为调色板Palette，当然，这里是对那些需要调色板的位图文件而言的。有些位图，如真彩色图，前面已经讲过，是不需要调色板的，BITMAPINFOHEADER后直接是位图数据。
调色板实际上是一个数组，共有biClrUsed个元素(如果该值为零，则有2biBitCount个元素)。数组中每个元素的类型是一个RGBQUAD结构，占4个字节，其定义如下：
typedef struct tagRGBQUAD {
B 该颜色的蓝色分量
B 该颜色的绿色分量
B 该颜色的红色分量
B 保留值
} RGBQUAD;
第四部分就是实际的图象数据了。对于用到调色板的位图，图象数据就是该象素颜在调色板中的索引值。对于真彩色图，图象数据就是实际的R、G、B值。下面针对2色、16色、256色位图和真彩色位图分别介绍。
对于2色位图，用1位就可以表示该象素的颜色(一般0表示黑，1表示白)，所以一个字节可以表示8个象素。
对于16色位图，用4位可以表示一个象素的颜色，所以一个字节可以表示2个象素。
对于256色位图，一个字节刚好可以表示1个象素。
对于真彩色图，三个字节才能表示1个象素，哇，好费空间呀！没办法，谁叫你想让图的颜色显得更亮丽呢，有得必有失嘛。
要注意两点：
(每一行的字节数必须是4的整倍数，如果不是，则需要补齐。这在前面介绍biSizeImage时已经提到了。
(一般来说，.bMP文件的数据从下到上，从左到右的。也就是说，从文件中最先读到的是图象最下面一行的左边第一个象素，然后是左边第二个象素……接下来是倒数第二行左边第一个象素，左边第二个象素……依次类推 ，最后得到的是最上面一行的最右一个象素。
下面的函数将pBuffer指向的内存块中的位图数据写入文件中，lBufferLen参数为pBuffer指向的内存块的大小，注意必须先指定位图的BITMAPFILEHEADER结构和BITMAPINFOHEADER结构。
STDMETHODIMP CSampleGrabberCallback::BufferCB(double time,BYTE* pBuffer,long lBufferLen)
{
if(!g_bSnap)
return E_FAIL;
BOOL bWrite=FALSE;
FILE_SHARE_READ, NULL, CREATE_ALWAYS, NULL, NULL);
if (hFile == INVALID_HANDLE_VALUE)
{
return E_FAIL;
}
//首先初始化位图文件头结构（BITMAPFILEHEADER），并将其写入文件。
BITMAPFILEHEADER bmpFileHeader;
//memset(&bmpFileHeader,0,sizeof(bmpFileHeader));
ZeroMemory(&bmpFileHeader,sizeof(bmpFileHeader));
bmpFileHeader.bfType='MB';
bmpFileHeader.bfSize=sizeof(bmpFileHeader)+lBufferLen+sizeof(BITMAPINFOHEADER);
bmpFileHeader.bfOffBits=sizeof(BITMAPFILEHEADER)+sizeof(BITMAPINFOHEADER);
DWORD dwWritten=0;
bWrite=WriteFile(hFile,&bmpFileHeader,sizeof(bmpFileHeader),&dwWritten,NULL);
if(!bWrite)
{
MessageBox(0,TEXT("fail to write"),TEXT("Error"),MB_OK);
}
//初始化BITMAPINFOHEADER结构并将其写入文件。
//VIDEOINFOHEADER*viInfoHeader=(VIDEOINFOHEADER*) g_media_type.pbFormat;
//FreeMediaType(g_media_type);
BITMAPINFOHEADER bmpInfoHeader;
ZeroMemory(&bmpInfoHeader,sizeof(bmpInfoHeader));
//memset(&bmpInfoHeader,0,sizeof(bmpInfoHeader));
bmpInfoHeader.biSize=sizeof(bmpInfoHeader);
bmpInfoHeader.biWidth=lWidth;
bmpInfoHeader.biHeight=lHeight;
bmpInfoHeader.biPlanes=1;
bmpInfoHeader.biBitCount=16;//?24 8
dwWritten=0;
bWrite=WriteFile(hFile,&bmpInfoHeader,sizeof(bmpInfoHeader),&dwWritten,NULL);
if(!bWrite)
{
MessageBox(0,TEXT("fail to write"),TEXT("Error"),MB_OK);
}
//最后将位图的主要数据写入文件。
dwWritten=0;
bWrite=WriteFile(hFile,pBuffer,lBufferLen,&dwWritten,NULL);
if(!bWrite)
{
MessageBox(0,TEXT("fail to write"),TEXT("Error"),MB_OK);
}
CloseHandle(hFile);
CWnd* pMainWnd=theApp.GetMainWnd();
CDfgDlg* pDfg=(CDfgDlg*)pMainWnd;
HWND hwnd=pDfg->m_picture.GetSafeHwnd();
RECT rc;
::GetWindowRect(hwnd,&rc);
long lStillWidth=rc.right-rc.left;
long lStillHeight=rc.bottom-rc.top;
HDC hdcStill=GetDC(hwnd);
PAINTSTRUCT ps;
BeginPaint(hwnd,&ps);
SetStretchBltMode(hdcStill,COLORONCOLOR);
StretchDIBits(hdcStill,0,0,lStillWidth,lStillHeight,0,0,lWidth,lHeight,pBuffer,(BITMAPINFO*)&bmpInfoHeader,DIB_RGB_COLORS,SRCCOPY);
EndPaint(hwnd,&ps);
ReleaseDC(hwnd,hdcStill);
g_bSnap=!g_bSnap;
return S_OK;
}
关于CreateDIBSection函数：
HBITMAP CreateDIBSection(
HDChdc, // handle to DC
CONST BITMAPINFO*pbmi, // bitmap data
UINTiUsage, // data type indicator
VOID**ppvBits, // bit values
HANDLEhSection, // handle to file mapping object
DWORDdwOffset // offset to bitmap bit values
);
CreateDIBSection函数会根据位图结构信息（pbmi）分配内存空间，你不用为它分配内存，这块内存也不需要你释放，系统会自己释放的。
然后将位图中的图像数据读入这个内存地址，显示即可。
LPBYTE lpBits;
HBITMAP hBmp=::CreateDIBSection(dcMem.m_hDC,lpBitmap,DIB_PAL_COLORS, &lpBits,NUL L,0);
//将图像数据填充到得到的内存地址中
file.ReadHuge(lpBits,dwBitlen);
pDC->StretchBlt(0,0,bmp.bmWidth,bmp.bmHeight,&dcMem,0,0, bmp.bmWidth,bmp.bmHeight,SRCCOPY);
首先让我们检查一下如何简化CreateDIBSection，并正确地使用它。首先，把最後两个参数hSection和dwOffset，分别设定为NULL和0，我将在本章最後讨论这些参数的用法。第二，仅在fColorUse参数设定为DIB_ PAL_COLORS时，才使用hdc参数，如果fColorUse为DIB_RGB_COLORS（或0），hdc将被忽略（这与CreateDIBitmap不同，hdc参数用於取得与DDB相容的设备的色彩格式，CreateDIBitmap创建的是DDB（设备相关位图，CreateDIBSection创建设备无关位图），因此必须指定与位图所关联的设备，即hdc，位图根据hdc所代表的设备来取得位图的色彩格式）。
因此，CreateDIBSection最简单的形式仅需要第二和第四个参数。第二个参数是指向BITMAPINFO结构的指标，
BITMAPINFOHEADER bmih ;
BYTE * pBits ;
HBITMAP hBitmap ;
现在初始化BITMAPINFOHEADER结构的栏位
bmih->biSize = sizeof (BITMAPINFOHEADER) ;
bmih->biWidth = 384 ;
bmih->biHeight = 256 ;
bmih->biPlanes = 1 ;
bmih->biBitCount = 24 ;
bmih->biCompression = BI_RGB ;
bmih->biSizeImage = 0 ;
bmih->biXPelsPerMeter = 0 ;
bmih->biYPelsPerMeter = 0 ;
bmih->biClrUsed = 0 ;
bmih->biClrImportant = 0 ;
在基本准备後，我们呼叫该函式：
hBitmap = CreateDIBSection (NULL, (BITMAPINFO *) &bmih, 0, &pBits, NULL, 0) ;
这是函式呼叫所做的：CreateDIBSection检查BITMAPINFOHEADER结构并配置足够的记忆体块来载入DIB图素位元。（在这个例子里，记忆体块的大小为384×256×3位元组。）它在您提供的pBits参数中储存了指向此记忆体块的指标。
然而，我们还没有做完，点阵图图素是未初始化的。如果正在读取DIB档案，可以简单地把pBits参数传递给ReadFile函式并读取它们。或者可以使用一些程式码「人工」设定。
注意：使用CreateDIBSection函数获得的内存块指针（输出的第四个参数）所指向的地址中是没有内容的，我们必须向里面写入图像数据，然后才能够显示图像。
位图数据
这部分逐个像素表示图像。像素是从下到上、从左到右保存的。每个像素使用一个或者多个字节表示。如果一个图像水平线的字节数不是4的倍数，这行就使用空字节补齐，通常是ASCII码0。
範例： 有一張5*5的圖片，應該會有25個pixels，但是因為5不是4的倍數所以會顯示成： @@@@@@xxxxx000xx
xxx000xxxxx000xx
xxx000xxxxx000
x代表調色盤的編號 0代表Null_character @代表調色盤最後幾筆資料
有一張4*4的圖片，應該會有16個pixels，但是因為是4的倍數所以會顯示成：
@@@@@@xxxxxxxxxx
Xxxxxx
BMP（Bitmap_File）图形文件是Windows采用的图形文件格式，在Windows环境下运行的所有图像处理软件都支持BMP图像文件格式。Windows系统内部图像绘制操作都是以BMP为基础的。Windows 3.0以前的BMP文件格式与显示设备有关，因此把这种BMP图像文件格式成为设备相关位图DDB(device-dependent bitmap)文件格式。Windows 3.0以后的BMP图像文件与显示设备无关，因此把这种BMP图像文件格式称为设备无关位图DIB（device-independent bitmap）格式，目的是为了让Windows能够在任何类型的显示设备上显示所存储的图像。BMP位图文件默认的文件扩展名为BMP或者bmp（有时它也会以.DIB或者.RLE作为扩展名）。
文件结构：
位图文件可看成有4个部分组成：位图文件头（bitmap-file header）,位图信息头（bitmap-information header），彩色表（color table）和定义位图的字节阵列。
1．位图文件头：
包含信息：文件类型，文件大小，存放位置等信息。C中定义为如下结构体：
typedef struct tagBITMAPFILEHEADER {
UINT bfType; //说明文件的类型必须是‘BM’。
DWORD bfSize; //说明文件的大小，用字节为单位
UINT bfReserved1; //保留，但必须为0
UINT bfReserved2; //保留，但必须为0
DWORD bfOffBits; //说明从文件头开始到实际的图像数据之间的字节的偏移量。这个参数是非常有用的，因为位图信息头和调色板的长度会根据不同情况而变化，所以你可以用这个偏移值迅速的从文件中读取到数据位。
}BITMAPFILEHEADER;
2．位图信息头：
位图信息头（BITMAPINFO）包含位图信息头(BITMAPINFOHEADER)和彩色表(RGBQUAD)
Typedef struct tagBITMAPINFO{
BITMAPINFOHEADER bmiHeader; //包含了有关位图的尺寸及位图格式等信息
RGBQUAD bmiColors[1];//包含索引图像的真实RGB值。
} BITMAPINFO;
Typedef struct tagBITMAPINFOHEADER {
DWORD biSize; //说明BITMAPINFOHEADER结构所需要的字数。
LONG biWidth; //说明图像的宽度，以像素为单位
LONG biHeight; //说明像素的高度，以像素为单位
WORD biPlanes; //为目标设备说明位面数，其值将总是被设为1
WORD biBitCount; //说明比特数/像素，其值为1，4，8，16，24，32
DWORD biCompression; //说明压缩方式
DWORD biSizeImage; //说明图像大小，以字节为单位
LONG biXPelsPerMeter; //说明水平分辨率，用象素/米
LONG biYPelsPerMeter; //说明垂直分辨率，用象素/米
DWORD biClrUsed; //说明位图实际使用的彩色表中的颜色索引数
DWORD biClrImportant; //说明对图像显示有重要影响的颜色索引的数目，如果是0，表示都重要。
} BITMAPINFOHEADER;
现就BITMAPINFOHEADER结构作如下说明：
(1)彩色表的定位
应用程序可使用存储在biSize成员中的信息来查找在BITMAPINFO结构中的彩色表，如下所示：
pColor = ((LPSTR) pBitmapInfo (WORD) (pBitmapInfo->bmiHeader.biSize))
(2) biBitCount
biBitCount=1表示位图最多有两种颜色，缺省情况下是黑色和白色，你也可以自己定义这两种颜色。图像信息头装调色板中将有两个调色板项，称为索引0和索引1。图象数据阵列中的每一位表示一个象素。如果一个位是0，显示时就使用索引0的RGB值，如果位是1，则使用索引1的RGB值。
biBitCount=4表示位图最多有16种颜色。每个象素用4位表示，并用这4位作为彩色表的表项来查找该象素的颜色。 例如，如果位图中的第一个字节为0x1F，它表示有两个象素，第一象素的颜色就在彩色表的第2表项中查找，而第二个象素的颜色就在彩色表的第16表项中查找。此时，调色板中缺省情况下会有16个RGB项。对应于索引0到索引15。
biBitCount=8表示位图最多有256种颜色。每个象素用8位表示，并用这8位作为彩色表的表项来查找该象素的颜色。例如，如果位图中的第一个字节为0x1F，这个象素的颜色就在彩色表的第32表项中查找。此时，缺省情况下，调色板中会有256个RGB项，对应于索引0到索引255。
biBitCount=16表示位图最多有216种颜色。每个色素用16位（2个字节）表示。这种格式叫作高彩色，或叫增强型16位色，或K色。它的情况比较复杂，当biCompression成员的值是BI_RGB时，它没有调色板。16位中，最低的5位表示蓝色分量，中间的5位表示绿色分量，高的5位表示红色分量，一共占用了15位，最高的一位保留，设为0。这种格式也被称作555 16位位图。如果biCompression成员的值是BI_BITFIELDS，那么情况就复杂了，首先是原来调色板的位置被三个DWORD变量占据，称为红、绿、蓝掩码。分别用于描述红、绿、蓝分量在16位中所占的位置。在Windows 95（或98）中，系统可接受两种格式的位域：555和565，在555格式下，红、绿、蓝的掩码分别是：0x7C00、0x03E0、0x001F，而在565格式下，它们则分别为：0xF800、0x07E0、0x001F。你在读取一个像素之后，可以分别用掩码“与”上像素值，从而提取出想要的颜色分量（当然还要再经过适当的左右移操作）。在NT系统中，则没有格式，只不过要求掩码之间不能有重叠。（注：这种格式的图像使用起来是比较麻烦的，不过因为它的显示效果接近于真彩，而图像数据又比真彩图像小的多，所以，它更多的被用于游戏软件）。
biBitCount=24表示位图最多有224种颜色。这种位图没有调色板（bmiColors成员尺寸为0），在位数组中，每3个字节代表一个象素，分别对应于颜色R、G、B。
biBitCount=32表示位图最多有232种颜色。这种位图的结构与16位位图结构非常类似，当biCompression成员的值是BI_RGB时，它也没有调色板，32位中有24位用于存放RGB值，顺序是：最高位—保留，红8位、绿8位、蓝8位。这种格式也被成为888 32位图。如果 biCompression成员的值是BI_BITFIELDS时，原来调色板的位置将被三个DWORD变量占据，成为红、绿、蓝掩码，分别用于描述红、绿、蓝分量在32位中所占的位置。在Windows 95(or 98)中，系统只接受888格式，也就是说三个掩码的值将只能是：0xFF0000、0xFF00、0xFF。而在NT系统中，你只要注意使掩码之间不产生重叠就行。（注：这种图像格式比较规整，因为它是DWORD对齐的，所以在内存中进行图像处理时可进行汇编级的代码优化（简单））。
(3) ClrUsed
BITMAPINFOHEADER结构中的成员ClrUsed指定实际使用的颜色数目。如果ClrUsed设置成0，位图使用的颜色数目就等于biBitCount成员中的数目。请注意，如果ClrUsed的值不是可用颜色的最大值或不是0，则在编程时应该注意调色板尺寸的计算，比如在4位位图中，调色板的缺省尺寸应该是16＊sizeof(RGBQUAD)，但是，如果ClrUsed的值不是16或者不是0，那么调色板的尺寸就应该是ClrUsed＊sizeof(RGBQUAD)。
(4)图象数据压缩
① BI_RLE8：每个象素为8比特的RLE压缩编码，可使用编码方式和绝对方式中的任何一种进行压缩，这两种方式可在同一幅图中的任何地方使用。
编码方式：由2个字节组成，第一个字节指定使用相同颜色的象素数目，第二个字节指定使用的颜色索引。此外，这个字节对中的第一个字节可设置为0，联合使用第二个字节的值表示：
第二个字节的值为0：行的结束。
第二个字节的值为1：图象结束。
第二个字节的值为2：其后的两个字节表示下一个象素从当前开始的水平和垂直位置的偏移量。
绝对方式：第一个字节设置为0，而第二个字节设置为0x03～0xFF之间的一个值。在这种方式中，第二个字节表示跟在这个字节后面的字节数，每个字节包含单个象素的颜色索引。压缩数据格式需要字边界(word boundary)对齐。下面的例子是用16进制表示的8-位压缩图象数据：
03 04 05 06 00 03 45 56 67 00 02 78 00 02 05 01 02 78 00 00 09 1E 00 01
这些压缩数据可解释为：
| 压缩数据 | 扩展数据 |
| 03 04 | 04 04 04 |
| 05 06 | 06 06 06 06 06 |
| 00 03 45 56 67 00 | 45 56 67 |
| 02 78 | 78 78 |
| 00 02 05 01 | 从当前位置右移5个位置后向下移一行 |
| 02 78 | 78 78 |
| 00 00 | 行结束 |
| 09 1E | 1E 1E 1E 1E 1E 1E 1E 1E 1E |
| 00 01 | RLE编码图象结束 |
编码方式：由2个字节组成，第一个字节指定象素数目，第二个字节包含两种颜色索引，一个在高4位，另一个在低4位。第一个象素使用高4位的颜色索引，第二个使用低4位的颜色索引，第3个使用高4位的颜色索引，依此类推。
绝对方式：这个字节对中的第一个字节设置为0，第二个字节包含有颜色索引数，其后续字节包含有颜色索引，颜色索引存放在该字节的高、低4位中，一个颜色索引对应一个象素。此外，BI_RLE4也同样联合使用第二个字节中的值表示：
第二个字节的值为0：行的结束。
第二个字节的值为1：图象结束。
第二个字节的值为2：其后的两个字节表示下一个象素从当前开始的水平和垂直位置的偏移量。
下面的例子是用16进制数表示的4-位压缩图象数据：
03 04 05 06 00 06 45 56 67 00 04 78 00 02 05 01 04 78 00 00 09 1E 00 01
这些压缩数据可解释为：
| 压缩数据 | 扩展数据 |
| 03 04 | 0 4 0 |
| 05 06 | 0 6 0 6 0 |
| 00 06 45 56 67 00 | 4 5 5 6 6 7 |
| 04 78 | 7 8 7 8 |
| 00 02 05 01 | 从当前位置右移5个位置后向下移一行 |
| 04 78 | 7 8 7 8 |
| 00 00 | 行结束 |
| 09 1E | 1 E 1 E 1 E 1 E 1 |
| 00 01 | RLE图象结束 |
typedef struct tagRGBQUAD { /* rgbq */
BYTE rgbBlue;
BYTE rgbGreen;
BYTE rgbRed;
BYTE rgbReserved;
} RGBQUAD;
位图数据
长度由图像尺寸,象素位数,压缩方式等共同决定.
由于存储要求,图像的列数必须为4的整数倍
BMP文件的数据格式可以分为两大类:使用颜色表型和直接数据区型
biBitCount值为1，4，8时数据区存放颜色索引，24时为直接数据
一，文件格式定义：
BMP(Bitmap-File)图形文件是Windows采用的图形文件格式，在Windows环境下运行的所有图象处理软 件都支持BMP图像文件格式。Windows系统内部各图像绘制操作都是以BMP为基础的。Windows 3.0以前的BMP图文件格式与显示设备有 关，因此把这种BMP图像文件格式称为设备相关位图DDB(device-dependent bitmap)文件格式。Windows 3.0以后的 BMP图像文件与显示设备无关，因此把这种BMP图像文件格式称为设备无关位图DIB(device-independent bitmap)格式（注： Windows 3.0以后，在系统中仍然存在DDB位图，像BitBlt()这种函数就是基于DDB位图的，只不过如果你想将图像以BMP格式保存到磁盘文件中时，微软极力推荐你以DIB格式保存），目的是为了让Windows能够在任何类型的显示设备上显示所存储的图像。BMP位图文件默认的文件扩展 名是BMP或者bmp（有时它也会以.DIB或.RLE作扩展名）。
文件结构
位图文件可看成由4个部分组成：位图文件头(bitmap-file header)、位图信息头(bitmap-information header)、彩色表(color table)和定义位图的字节阵列，它具有如下所示的形式。
位图文件的组成 结构名称 符号
位图文件头(bitmap-file header) BITMAPFILEHEADER bmfh
位图信息头(bitmap-information header) BITMAPINFOHEADER bmih
彩色表(color table) RGBQUAD aColors[]
图像数据阵列字节 BYTE aBitmapBits[]
位图文件结构可综合在表6-01中。
表01位图文件结构内容摘要
偏移量 域的名称 大小 内容
图象文件
头 0000h文件标识 2 bytes两字节的内容用来识别位图的类型：
‘BM’： Windows 3.1x, 95, NT, …
‘BA’：OS/2 Bitmap Array
‘CI’：OS/2 Color Icon
‘CP’：OS/2 Color Pointer
‘IC’： OS/2 Icon
‘PT’：OS/2 Pointer
注：因为OS/2系统并没有被普及开，所以在编程时，你只需判断第一个标识“BM”就行。
0002h File Size 1 dword用字节表示的整个文件的大小
0006h Reserved 1 dword保留，必须设置为0
000Ah Bitmap Data Offset 1 dword从文件开始到位图数据开始之间的数据(bitmap data)之间的偏移量
000Eh Bitmap Header Size 1 dword位图信息头(Bitmap Info Header)的长度，用来描述位图的颜色、压缩方法等。下面的长度表示：
28h - Windows 3.1x, 95, NT, …
0Ch - OS/2 1.x
F0h - OS/2 2.x
注： 在Windows95、98、2000等操作系统中，位图信息头的长度并不一定是28h，因为微软已经制定出了新的BMP文件格式，其中的信息头结构变化 比较大，长度加长。所以最好不要直接使用常数28h，而是应该从具体的文件中读取这个值。这样才能确保程序的兼容性。
0012h Width 1 dword位图的宽度，以象素为单位
0016h Height 1 dword位图的高度，以象素为单位
001Ah Planes 1 word位图的位面数（注：该值将总是1）
图像信息头
001Ch Bits Per Pixel 1 word每个象素的位数
1 -单色位图（实际上可有两种颜色，缺省情况下是黑色和白色。你可以自己定义这两种颜色）
4 - 16色位图
8 - 256色位图
16 - 16bit高彩色位图
24 - 24bit真彩色位图
32 - 32bit增强型真彩色位图
001Eh Compression 1 dword压缩说明：
0 -不压缩 (使用BI_RGB表示)
1 - RLE 8-使用8位RLE压缩方式(用BI_RLE8表示)
2 - RLE 4-使用4位RLE压缩方式(用BI_RLE4表示)
3 - Bitfields-位域存放方式(用BI_BITFIELDS表示)
0022h Bitmap Data Size 1 dword用字节数表示的位图数据的大小。该数必须是4的倍数
0026h HResolution 1 dword用象素/米表示的水平分辨率
002Ah VResolution 1 dword用象素/米表示的垂直分辨率
002Eh Colors 1 dword位图使用的颜色数。如8-比特/象素表示为100h或者 256.
0032h Important Colors 1 dword指定重要的颜色数。当该域的值等于颜色数时（或者等于0时），表示所有颜色都一样重要
调色板数据 根据BMP版本的不同而不同 Palette N * 4 byte调色板规范。对于调色板中的每个表项，这4个字节用下述方法来描述RGB的值：
1字节用于蓝色分量
1字节用于绿色分量
1字节用于红色分量
1字节用于填充符(设置为0)
图像数据 根据BMP版本及调色板尺寸的不同而不同 Bitmap Data xxx bytes该域的大小取决于压缩方法及图像的尺寸和图像的位深度， 它包含所有的位图数据字节，这些数据可能是彩色调色板的索引号，也可能是实际的RGB值，这将根据图像信息头中的位深度值来决定。
构件详解
1.位图文件头
位图文件头包含有关于文件类型、文件大小、存放位置等信息，在Windows 3.0以上版本的位图文件中用BITMAPFILEHEADER结构来定义：
typedef struct tagBITMAPFILEHEADER { /* bmfh */
UINT bfType;
DWORD bfSize;
UINT bfReserved1;
UINT bfReserved2;
DWORD bfOffBits;
} BITMAPFILEHEADER;
其中：
bfType说明文件的类型.（该值必需是0x4D42，也就是字符'BM'。我们不需要判断OS/2的位图标识，这么做现在来看似乎已经没有什么意义了，而且如果要支持OS/2的位图，程序将变得很繁琐。所以，在此只建议你检察'BM'标识）
bfSize说明文件的大小，用字节为单位
bfReserved1保留，必须设置为0
bfReserved2保留，必须设置为0
bfOffBits说明从文件头开始到实际的图像数据之间的字节的偏移量。这个参数是非常有用的，因为位图信息头和调色板的长度会根据不同情况而变化，所以你可以用这个偏移值迅速的从文件中读取到位数据。
2.位图信息头
位图信息用BITMAPINFO结构来定义，它由位图信息头(bitmap-information header)和彩色表(color table)组 成，前者用BITMAPINFOHEADER结构定义，后者用RGBQUAD结构定义。BITMAPINFO结构具有如下形式：
typedef struct tagBITMAPINFO { /* bmi */
BITMAPINFOHEADER bmiHeader;
RGBQUAD bmiColors[1];
} BITMAPINFO;
其中：bmiHeader说明BITMAPINFOHEADER结构，其中包含了有关位图的尺寸及位格式等信息
bmiColors说明彩色表RGBQUAD结构的阵列，其中包含索引图像的真实RGB值。
BITMAPINFOHEADER结构包含有位图文件的大小、压缩类型和颜色格式，其结构定义为：
typedef struct tagBITMAPINFOHEADER { /* bmih */
DWORD biSize;
LONG biWidth;
LONG biHeight;
WORD biPlanes;
WORD biBitCount;
DWORD biCompression;
DWORD biSizeImage;
LONG biXPelsPerMeter;
LONG biYPelsPerMeter;
DWORD biClrUsed;
DWORD biClrImportant;
} BITMAPINFOHEADER;
其中：
biSize说明BITMAPINFOHEADER结构所需要的字数。注：这个值并不一定是BITMAPINFOHEADER结构的尺寸，它也可能是sizeof (BITMAPV4HEADER)的值，或是sizeof(BITMAPV5HEADER)的值。这要根据该位图文件的格式版本来决定，不过，就现在的情况来看，绝大多数的BMP图像都是BITMAPINFOHEADER结构的。biWidth说明图像的宽度，以象素为单位；biHeight 说明图像的高度，以象素为单位。
注：这个值除了用于描述图像的高度之外，它还有另一个用处，就是指明该图像是倒向的位图，还是正向的位图。如果该值是一个正数，说明图像是倒向的，如果该值是一个负数，则说明图像是正向的。大多数的BMP文件都是倒向的位图，也就是，高度值是一个正数。（注：当高度值是一个负数时（正向图像），图像将不能被压缩（也就是说biCompression成员将不能是BI_RLE8或BI_RLE4）。
biPlanes为目标设备说明位面数，其值将总是被设为1
biBitCount说明比特数/象素，其值为1、4、8、16、24、或32
biCompression说明图像数据压缩的类型。其值可以是下述值之一：
BI_RGB：没有压缩；
BI_RLE8：每个象素8比特的RLE压缩编码，压缩格式由2字节组成(重复象素计数和颜色索引)；
BI_RLE4：每个象素4比特的RLE压缩编码，压缩格式由2字节组成
BI_BITFIELDS：每个象素的比特由指定的掩码决定。
biSizeImage说明图象的大小，以字节为单位。当用BI_RGB格式时，可设置为0
biXPelsPerMeter说明水平分辨率，用象素/米表示
biYPelsPerMeter说明垂直分辨率，用象素/米表示
biClrUsed说明位图实际使用的彩色表中的颜色索引数（设为0的话，则说明使用所有调色板项）
biClrImportant说明对图象显示有重要影响的颜色索引的数目，如果是0，表示都重要。
现就BITMAPINFOHEADER结构作如下说明：
(1)彩色表的定位
应用程序可使用存储在biSize成员中的信息来查找在BITMAPINFO结构中的彩色表，如下所示：
pColor = ((LPSTR) pBitmapInfo + (WORD) (pBitmapInfo->bmiHeader.biSize))
(2) biBitCount
biBitCount =1表示位图最多有两种颜色，缺省情况下是黑色和白色，你也可以自己定义这两种颜色。图像信息头装调色板中将有两个调色板项，称为索引0和索引1。图像数据阵列中的每一位表示一个象素。如果一个位是0，显示时就使用索引0的RGB值，如果位是1，则使用索引1的RGB值。
biBitCount=4表示位图最多有16（24）种颜色。每个象素用4位表示，并用这4位作为彩色表的表项来查找该象素的颜色。例如，如果位图中的第一个字节为0x1F，它表示有两个象素，第一象素的颜色就在彩色表的第2表项中查找，而第二个象素的颜色就在彩色表的第16表项中查找。此时，调色板中缺省情况下会有16个RGB项。对应于索引0到索引15。
biBitCount=8表示位图最多有256种颜色。每个象素用8位表示，并用这8位作为彩色表的表项来查找该象素的颜色。例如，如果位图中的第一个字节为0x1F，这个象素的颜色就在彩色表的第32表项中查找。此时，缺省情况下，调色板中会有256个RGB项，对应于索引0到索引255。
biBitCount=16表示位图最多有216种颜色。每个色素用16位（2个字节）表示。这种格式叫作高彩色，或叫增强型16位色，或K色。它的情况比较复杂，当biCompression成员的值是BI_RGB时，它没有调色板。16位中，最低的5位表示蓝色分量， 中间的5位表示绿色分量，高的5位表示红色分量，一共占用了15位，最高的一位保留，设为0。这种格式也被称作555 16位位图。如果 biCompression成员的值是BI_BITFIELDS，那么情况就复杂了，首先是原来调色板的位置被三个DWORD变量占据，称为红、绿、蓝掩码。分别用于描述红、绿、蓝分量在16位中所占的位置。在Windows 95（或98）中，系统可接受两种格式的位域：555和565，在555格式下，红、绿、蓝的掩码分别是：0x7C00、0x03E0、0x001F，而在565格式下，它们则分别为：0xF800、0x07E0、0x001F。 你在读取一个像素之后，可以分别用掩码“与”上像素值，从而提取出想要的颜色分量（当然还要再经过适当的左右移操作）。在NT系统中，则没有格式，只不过要求掩码之间不能有重叠。（注：这种格式的图像使用起来是比较麻烦的，不过因为它的显示效果接近于真彩，而图像数据又比真彩图像小的多，所以，它更多的被用于游戏软件）。
biBitCount=24表示位图最多有224种颜色。这种位图没有调色板（bmiColors成员尺寸为0），在位数组中，每3个字节代表一个象素，分别对应于颜色R、G、B。
biBitCount =32表示位图最多有232种颜色。这种位图的结构与16位位图结构非常类似，当biCompression成员的值是BI_RGB时，它也没有调色板，32位中有24位用于存放RGB值，顺序是：最高位—保留，红8位、绿8位、蓝8位。这种格式也被成为888 32位图。如果 biCompression成员的值是BI_BITFIELDS时，原来调色板的位置将被三个DWORD变量占据，成为红、绿、蓝掩码，分别用于描述红、绿、蓝分量在32位中所占的位置。在Windows 95(or 98)中，系统只接受888格式，也就是说三个掩码的值将只能是： 0xFF0000、0xFF00、0xFF。而在NT系统中，你只要注意使掩码之间不产生重叠就行。（注：这种图像格式比较规整，因为它是DWORD对齐 的，所以在内存中进行图像处理时可进行汇编级的代码优化（简单））。
(3) ClrUsed
BITMAPINFOHEADER结构中的成 员ClrUsed指定实际使用的颜色数目。如果ClrUsed设置成0，位图使用的颜色数目就等于biBitCount成员中的数目。请注意，如果 ClrUsed的值不是可用颜色的最大值或不是0，则在编程时应该注意调色板尺寸的计算，比如在4位位图中，调色板的缺省尺寸应该是16＊sizeof (RGBQUAD)，但是，如果ClrUsed的值不是16或者不是0，那么调色板的尺寸就应该是ClrUsed＊sizeof(RGBQUAD)。
(4)图像数据压缩
① BI_RLE8：每个象素为8比特的RLE压缩编码，可使用编码方式和绝对方式中的任何一种进行压缩，这两种方式可在同一幅图中的任何地方使用。
编码方式：由2个字节组成，第一个字节指定使用相同颜色的象素数目，第二个字节指定使用的颜色索引。此外，这个字节对中的第一个字节可设置为0，联合使用第二个字节的值表示：
第二个字节的值为0：行的结束。
第二个字节的值为1：图像结束。
第二个字节的值为2：其后的两个字节表示下一个象素从当前开始的水平和垂直位置的偏移量。
绝对方式：第一个字节设置为0，而第二个字节设置为0x03～0xFF之间的一个值。在这种方式中，第二个字节表示跟在这个字节后面的字节数，每个字节包含 单个象素的颜色索引。压缩数据格式需要字边界(word boundary)对齐。下面的例子是用16进制表示的8-位压缩图像数据：
03 04 05 06 00 03 45 56 67 00 02 78 00 02 05 01 02 78 00 00 09 1E 00 01
这些压缩数据可解释为 ：
压缩数据 扩展数据
03 04 04 04 04
05 06 06 06 06 06 06
00 03 45 56 67 00 45 56 67
02 78 78 78
00 02 05 01从当前位置右移5个位置后向下移一行
02 78 78 78
00 00行结束
09 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E
00 01 RLE编码图象结束
② BI_RLE4：每个象素为4比特的RLE压缩编码，同样也可使用编码方式和绝对方式中的任何一种进行压缩，这两种方式也可在同一幅图中的任何地方使用。这两种方式是：
编码方式：由2个字节组成，第一个字节指定象素数目，第二个字节包含两种颜色索引，一个在高4位，另一个在低4位。第一个象素使用高4位的颜色索引，第二个使用低4位的颜色索引，第3个使用高4位的颜色索引，依此类推。
绝对方式：这个字节对中的第一个字节设置为0，第二个字节包含有颜色索引数，其后续字节包含有颜色索引，颜色索引存放在该字节的高、低4位中，一个颜色索引对应一个象素。此外，BI_RLE4也同样联合使用第二个字节中的值表示：
第二个字节的值为0：行的结束。
第二个字节的值为1：图象结束。
第二个字节的值为2：其后的两个字节表示下一个象素从当前开始的水平和垂直位置的偏移量。
下面的例子是用16进制数表示的4-位压缩图象数据：
03 04 05 06 00 06 45 56 67 00 04 78 00 02 05 01 04 78 00 00 09 1E 00 01
这些压缩数据可解释为 ：
压缩数据 扩展数据
03 04 0 4 0
05 06 0 6 0 6 0
00 06 45 56 67 00 4 5 5 6 6 7
04 78 7 8 7 8
00 02 05 01从当前位置右移5个位置后向下移一行
04 78 7 8 7 8
00 00行结束
09 1E 1 E 1 E 1 E 1 E 1
00 01 RLE图像结束
3.彩色表
彩色表包含的元素与位图所具有的颜色数相同，象素的颜色用RGBQUAD结构来定义。对于24-位真彩色图像就不使用彩色表（同样也包括16位、和32位位 图），因为位图中的RGB值就代表了每个象素的颜色。彩色表中的颜色按颜色的重要性排序，这可以辅助显示驱动程序为不能显示足够多颜色数的显示设备显示彩色图像。RGBQUAD结构描述由R、G、B相对强度组成的颜色，定义如下：
typedef struct tagRGBQUAD { /* rgbq */
BYTE rgbBlue;
BYTE rgbGreen;
BYTE rgbRed;
BYTE rgbReserved;
} RGBQUAD;
其中：
rgbBlue指定蓝色强度
rgbGreen指定绿色强度
rgbRed指定红色强度
rgbReserved保留，设置为0
4.位图数据
紧 跟在彩色表之后的是图像数据字节阵列。图像的每一扫描行由表示图像象素的连续的字节组成，每一行的字节数取决于图像的颜色数目和用象素表示的图像宽度。扫 描行是由底向上存储的，这就是说，阵列中的第一个字节表示位图左下角的象素，而最后一个字节表示位图右上角的象素。（只针对与倒向DIB，如果是正向 DIB，则扫描行是由顶向下存储的），倒向DIB的原点在图像的左下角，而正向DIB的原点在图像的左上角。同时，每一扫描行的字节数必需是4的整倍数， 也就是DWORD对齐的。如果你想确保图像的扫描行DWORD对齐，可使用下面的代码：
(((width*biBitCount)+31)>>5)<<2
5.参考书目
《图像文件格式(上、下)—Windows编程》
《图像文件格式大全》
《Programming Windows by Charles Petzold》
二，实例分析
BMP格式图像文件详析
首先注意所有的数值在存储上都是按“高位放高位、低位放低位”的原则，（如12345678h放在存储器中就是7856 3412）。下图是导出来的开机动画的第一张图加上文件头后的16进制数据，以此为例进行分析。T408中的图像有点怪，图像是在电脑上看是垂直翻转的。在分析中为了简化叙述，以一个字（两个字节，如424D就是一个字）为序号单位进行，“h”表示是16进制数。
424D 4690 0000 0000 0000 4600 0000 2800 0000 8000 0000 9000 0000 01001000 0300
0000 0090 0000 A00F 0000 A00F 0000 0000 0000 0000 000000F8 0000 E007 0000 1F00
0000 0000 000002F1 84F1 04F1 84F1 84F1 06F2 84F1 06F2 04F2 86F2 06F2 86F2 86F2
．．．．．．
BMP文件可分为四个部分：位图文件头、位图信息头、彩色板、图像数据阵列，在上图中已用*分隔。
一、图像文件头
1）1：图像文件头。424Dh=‘BM’，表示是Windows支持的BMP格式。
2）2-3：整个文件大小。4690 0000，为00009046h=36934。
3）4-5：保留，必须设置为0。
4）6-7：从文件开始到位图数据之间的偏移量。4600 0000，为00000046h=70，上面的文件头就是35字=70字节。
5）8-9：位图信息头长度。
6）10-11：位图宽度，以像素为单位。8000 0000，为00000080h=128。
7）12-13：位图高度，以像素为单位。9000 0000，为00000090h=144。
8）14：位图的位面数，该值总是1。0100，为0001h=1。
二、位图信息头
9）15：每个像素的位数。有1（单色），4（16色），8（256色），16（K色，高彩色），24（16M色，真彩色），32（4096M色，增强型真彩色）。T408支持的是16位格式。1000为0010h=16。
10） 16-17：压缩说明：有0（不压缩），1（RLE 8，8位RLE压缩），2（RLE 4，4位RLE压缩，3（Bitfields，位域存放）。 RLE简单地说是采用像素数+像素值的方式进行压缩。T408采用的是位域存放方式，用两个字节表示一个像素，位域分配为r5b6g5。图中 0300 0000为00000003h=3。
11）18-19：用字节数表示的位图数据的大小，该数必须是4的倍数，数值上等于位图宽度×位图高度×每个像素位数。0090 0000为00009000h=80×90×2h=368。
12）20-21：用象素/米表示的水平分辨率。A00F 0000为0000 0FA0h=4000。
13）22-23：用象素/米表示的垂直分辨率。A00F 0000为0000 0FA0h=4000。
14）24-25：位图使用的颜色索引数。设为0的话，则说明使用所有调色板项。
15）26-27：对图象显示有重要影响的颜色索引的数目。如果是0，表示都重要。
三、彩色板
16）28-35：彩色板规范。对于调色板中的每个表项，用下述方法来描述RGB的值：
1字节用于蓝色分量
1字节用于绿色分量
1字节用于红色分量
1字节用于填充符(设置为0)
对于24-位真彩色图像就不使用彩色表，因为位图中的RGB值就代表了每个象素的颜色。但是16位r5g6b5位域彩色图像需要彩色表，看前面的图，与上面的解释不太对得上，应以下面的解释为准。
图中彩色板为00F8 0000 E007 0000 1F00 0000 0000 0000，其中：
00F8 0000为F800h=1111100000000000（二进制），是红色分量的掩码。
E007 0000为07E0h=0000011111100000（二进制），是绿色分量的掩码。
1F00 0000为001Fh=0000000000011111（二进制），是红色分量的掩码。
0000 0000总设置为0。
将掩码跟像素值进行“与”运算再进行移位操作就可以得到各色分量值。看看掩码，就可以明白事实上在每个像素值的两个字节16位中，按从高到低取5、6、5位 分别就是r、g、b分量值。取出分量值后把r、g、b值分别乘以8、4、8就可以补齐每个分量为一个字节，再把这三个字节按R、G、B组合，放入存储器（同样要反序），就可以转换为24位标准BMP格式了。
四、图像数据阵列
17)36-．．．：每两个字节表示一个像素。阵列中的第一个字节表示位图左下角的象素，而最后一个字节表示位图右上角的象素。
按照前述r5g6b5彩色板规范，我们对图像最左下角手机上图像的的像素在24位模式中的rgb值进行推算（由于垂直翻转，这个像素在手机上看来实际上在左上角）：
02F1为 F102h
r=（F102 AND F800）/ 800 × 8 h= F0h=240
g=（F102 AND 07E0）/ 20 × 4 h=20h=32
b=（F102 AND 001F）× 8 h= 10h=16
rgb=F02010h，放在存储器中为1020F0h。
在Photoshop中设一下颜色，rgb取240、32、16可以看到是近红色。
C中如何显示文件？
1. 文件结构
文件和大多数图形文件一样，分为文件描述区（头文件信息）和图象存储区（象素数据）两部分。而头文件信息中又包含了信息区和调色板区两部分，信息区又可以细分为文件信息区和图象信息区两部分。
这 里以256色320*200的bmp图象为例。头文件描述区的偏移长度是1078个字节，也就是说图象存储区是从文件偏移1078后开始读取的。在头文件 描述区中头信息区的偏移长度是54个字节，也就是说调色板数据区是从54-1078之间的1024字节。在头信息区中文件信息区占14个字节而图象信息区 占40字节。
（1） 文件信息区
文件类型
文件长度
文件描述区长度，16色为118，256色为1078
现在算一下，有3个int，2个long，正好3*2+2*4=14字节
（2） 图象信息区
现在算一下，2个int，9个long，正好是2+2*9*4=40字节。
（3）调色板区
说明：三原色+灰度，共4*256=1024字节。
下面是bmp文件的完整的结构定义：
RGB_BMP palette[256];
2. bmp文件的显示
（1）图象存储区的读取
由 于bmp图象是从下至上存储的，所以我们不能进行直接顺序读取。详细的说，bmp图象存储区数据是从1078偏移字节开始。文件内第一个图象点实际上是对 应图象（320*200）第200行的最左边的第一个点，而从1078开始的320个点则是图象最下面一行对应的点，之后的321个点是图象倒数第二行最 左边的第一个点。这样，bmp文件最后一个字节对应的点是第一行最后边的点了。
下面是实现bmp文件图象存储区数据读取到内存的代码：
read(fp,&bmp256->buffer[i*info.biWidth],info.biWidth);
（2）调色板的读取
除了图象存储区的存放规则是倒序的以外，bmp文件调色板内容也是以B,G,R,灰度的顺序存放的。所以读取时不要将文件中的三原色中的兰色对应给调色板结构体变量中的红色。
同时，由于三原色只使用种（6位）色阶，而三原色的存放空间是1字节（8位），所以要将bmp文件三原色的6位数据都放在1个字节的高位，则在读取调色板结构体变量的时候必须进行右移2位。
以下给出读取文件调色板数据的代码
.blue,1);
read(fp,&bmp256->palette.green,1);
.red,1);
read(fp,&bmp256->palette.reserved,1);
.blue=bmp256->palette.blue>>2;
.green=bmp256->palette.green>>2;
.red=bmp256->palette.red>>2;
以下给出写入调色板函数
确定调色板序号*/
设置该序号为红色*/
设置该序号为绿色*/
设置该序号为兰色*/
调用调色板的代码：
);
现在我们开始进行完整的读取
(1)申请内存空间
(2)检查头文件信息区
(3)读取调色板数据
(4)读取位图到内存
(5)显示图象
(6)内存释放
(1)申请内存：
由于320*200是K，而C程序允许用户申请的内存空间也只有K，为了防止一次申请不到，我们可以分几次申请。使用malloc()函数就可以。
(2)检查头文件信息区：
A：判断是不是bmp文件（若不是，则无法显示）
B：文件是否为压缩格式（若是，则无法处理）
C：文件是否为256色
以下给出读取头文件信息到内存的代码：
read(fp,&bmp256->file,sizeof(bitmapfile));
read(fp,&bmp256->info,sizeof(bitmapinfo));
以下是检测bmp文件格式的函数：
void Check_Bmp(bmp_picture_ptr bmp_ptr)
{
if(bmp_ptr->file.bfType!=0x4d42) /*检测是不是bmp文件*/
{
printf("Not a BMP file! ");
exit(1);
}
if(bmp_ptr->info.biCompression!=0) /*检测是不是压缩文件，1表示压缩，0表示没压缩*/
{
printf("Can not display a compressed bmp file! ");
exit(1);
}
if(bmp_ptr->info.biBitCount!=8) /*检测是不是256色*/
{
printf("Not a index 256color bmp file! ");
exit(1);
}
}
(3)和(4)前面有介绍，这儿省略。
(5)显示图象
假设bmp文件的调色板区已写入计算机调色板，bmp文件图象存储区也已写到内存，以下给出具体的显示到屏幕的函数
void BMP_Show_Buffer2(bmp_picture_ptr image)
{
memcpy((char far *)video_buffer,(char far *)image->buffer,(unsigned int)info->biWidth*info->biHight/2)
}
(6)释放内存
void BMP_Delete(bmp_picture_ptr image)
{
free(image->buffer);
}
好了，经过以上几步，基本上你的bmp文件就能在C中显示了。当然前提是你使用256色的图形驱动。也就是你的int gdrive=DETECT应该改为int gdrive=6;如果你仅仅显示16色的文件，就没有必要了。下载本文
