第一部分为位图文件头BITMAPFILEHEADER，是一个结构，其定义如下：
typedef struct tagBITMAPFILEHEADER
{
 WORD    bfType;//什么类型的文件 .bmp文件的头2个字节为“BM” 0x424D
 DWORD   bfSize;//整个文件大小，包含文件头
 WORD    bfReserved1;//保留字，不考虑
 WORD    bfReserved2;//保留字
 DWORD   bfOffBits;//从文件开头需要偏移多少字节才是实际的图像数据
}BITMAPFILEHEADER;

   这个结构的长度是固定的，为14个字节（WORD为无符号16位整数，DWORD为无符号32位整数），各个域的说明如下：
bfType
   指定文件类型，必须是0x424D，即字符串"BM"，也就是说所有.bmp文件的头两个字节都是"BM"
bfSize
   指定文件大小，包括这14个字节
bfReserved1，bfReserved2    
   为保留字，不用考虑
bfOffBits
   为从文件头到实际的位图数据的偏移字节数，即图3中前三个部分的长度之和。

第二部分为位图信息头BITMAPINFOHEADER，也是一个结构，其定义如下：
typedef struct tagBITMAPINFOHEADER
{
 DWORD    biSize;//该信息头结构体的长度
 LONG     biWidth;//图像宽度（像素）
 LONG     biHeight;//图像高度（像素）
 WORD     biPlanes;//必须为1，不考虑
 WORD     biBitCount;//表示颜色的位数（1,4,8,24）
 DWORD    biCompression;//是否压缩，一般是BI_RGB（不压缩）
 DWORD    biSizeImage;//图像的大小 biWidth‘*biHeight (biWidth‘为大于等于biWidth的4的倍数)
 LONG     biXPelsPerMeter;//目标设备水平分辨率（每米的像素个数）
 LONG     biYPelsPerMeter;//垂直分辨率
 DWORD    biClrUsed;//图像用到的颜色数（为0则为2^biBitCount的颜色数）
 DWORD    biClrImportant;//图像中重要的颜色数（为0则都重要）
}BITMAPINFOHEADER;

   这个结构的长度是固定的，为40个字节（WORD为无符号16位整数，DWORD无符号32位整数,LONG为32位整数），各个域的说明如下：
biSize
   指定这个结构的长度，为40
biWidth
   指定图象的宽度，单位是象素
biHeight
   指定图象的高度，单位是象素
biPlanes
   必须是1，不用考虑
biBitCount
   指定表示颜色时要用到的位数，常用的值为1（黑白二色图）,4（16色图）,8（256色）,24（真彩色图）（新的.bmp格式支持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，则该项可能为零

位图数据 
位图数据记录了位图的每一个像素值，记录顺序是在扫描行内是左到右,扫描行之间是从下到上。位图的一个像素值所占的字节数:  
   当biBitCount(每个像素所需的位数)=1时，8个像素占1个字节;
   当biBitCount=4时，2个像素占1个字节;
   当biBitCount=8时，1个像素占1个字节;
   当biBitCount=24时,1个像素占3个字节;
Windows规定一个扫描行所占的字节数必须是4的倍数(即以long为单位),不足的以0填充。
一个扫描行所占的字节数计算方法: DataSizePerLine= (biWidth* biBitCount+31)/8; 
我们后面定义了一个宏 #define WIDTHBYTES(i)    ((i+31)/32*4) 
每一行的字节数必须是4的整倍数，只要调用 
         WIDTHBYTES(bi.biWidth*bi.biBitCount)
就能完成这一换算。
    举一个例子，对于2色图，如果图象宽是31，则每一行需要31位存储，合3个字节加7位，因为字节数必须是4的整倍数，所以应该是4，而此时的       biWidth=31,biBitCount=1,每行，共有31个像素，换算成字节的话，要除以8（/32*4，即除以32再乘4），这里加31的原因在于后面的分母是32.

WIDTHBYTES(31*1)=4，和我们设想的一样。再举一个256色的例子，如果图象宽是31，则每一行需要31个字节存储，因为字节数必须是4的整倍数，所以应该是32，而此时的   biWidth=31,biBitCount=8,WIDTHBYTES(31*8)=32，
和我们设想的一样。你可以多举几个例子来验证一下。”
还有不清楚的吗？

biXPelsPerMeter
   指定目标设备的水平分辨率，单位是每米的象素个数，关于分辨率的概念，我们将在打印部分详细介绍。
biYPelsPerMeter
   指定目标设备的垂直分辨率，单位同上。
biClrUsed
   指定本图象实际用到的颜色数，如果该值为零，则用到的颜色数为2的biBitCount次方。
biClrImportant
   指定本图象中重要的颜色数，如果该值为零，则认为所有的颜色都是重要的。

第三部分为调色板(Palette)，当然，这里是对那些需要调色板的位图文件而言的。有些位图，如真彩色图，前面已经讲过，是不需要调色板的，BITMAPINFOHEADER后直接是位图数据。
调色板实际上是一个数组，共有biClrUsed个元素（如果该值为零，则有2的biBitCount次方个元素）。数组中每个元素的类型是一个RGBQUAD结构，占4个字节，其定义如下：
typedef struct tagRGBQUAD{
BYTE        rgbBlue;            //该颜色的蓝色分量
BYTE        rgbGreen;        //该颜色的绿色分量
BYTE        rgbRed;            //该颜色的红色分量
BYTE        rgbReserved;        //保留值
}    RGBQUAD; 

行对齐

由于Windows在进行行扫描的时候最小的单位为4个字节，所以当

图片宽 X 每个像素的字节数 ！= 4的整数倍

时要在每行的后面补上缺少的字节，以0填充（一般来说当图像宽度为2的幂时不需要对齐）。位图文件里的数据在写入的时候已经进行了行对齐，也就是说加载的时候不需要再做行对齐。

位图结构