引言

　　delphi是目前廣泛使用的可視化開發(fā)工具，它自身帶有一個圖片、圖標的編輯器——Image Editor，但是到delphi7為止，都不能進行真彩圖標的編輯，可以說是一個遺憾。筆者通過對圖標文件的研究，實現(xiàn)了產(chǎn)生24位真彩色圖標。

　　圖標文件的格式

　　首先，分析一個具體的圖標 。在CS1.6中有一個圖標game.ico（ ），如果用WinHex等可以進行16進制編輯的軟件打開這個圖標文件，我們可以看到如下數(shù)據(jù)：

00 00 01 00 04 00 10 10 00 00 00 00 00 00 68 05
00 00 46 00 00 00 10 10 00 00 00 00 00 00 68 03
00 00 AE 05 00 00 20 20 00 00 00 00 00 00 A8 08
00 00 16 09 00 00 20 20 00 00 00 00 00 00 A8 0C
00 00 BE 11 00 00 28 00 00 00 10 00 00 00 20 00
00 00 01 00 08 00 00 00 00 00 40 01 00 00 47 46
6C 65 6D 69 6E 67 00 01 00 00 00 00 00 00 00 00

　　下面我們就說一說，這些數(shù)據(jù)的具體含義。一個圖標文件(*.ICO),實際上可以含有多個圖標.通常,每個圖標都會被轉(zhuǎn)換為針對特定顯示設備的圖標圖像。圖標文件由文件頭和數(shù)據(jù)組成， ICO文件一開始，是一個叫做tagIconDir的記錄型的結(jié)構(gòu)，在delphi中這樣來描述（括號內(nèi)的數(shù)值，是針對CS圖標的具體數(shù)據(jù)）：

tagIconDir = packed record idReserved:WORD;// 保留域，目前始終為 0（開始的數(shù)據(jù) 00） idType:WORD; //定義為資源類型，圖標值為 01、光標是02(01) idCount:WORD; //idCount 表示的是這個文件里包含了幾個圖標(04) idEntries:array[0..0] of tagIconDirEntry; //不包括本數(shù)組，以上一共6個字節(jié) end;

　　這個記錄中的idEntries 是個數(shù)組結(jié)構(gòu)，這個結(jié)構(gòu)的大小不是始終為 1 的一個數(shù)組，它需要根據(jù)圖標數(shù)目 ( idCount ) 來確定真實的數(shù)組大小。它的類型為tagIconDirEntry記錄，定義如下：

tagIconDirEntry = packed record bWidth:BYTE;// 圖標圖片的顯示寬度，以像素為單位，最大值為255 (=16D) bHeight:BYTE;// 圖標圖片的顯示高度，以像素為單位，最大值為255 (=16D) bColorCount:BYTE;// 圖標圖片的顏色數(shù)() bReserved:BYTE;// 保留域總是 0 () wPlanes:WORD;// 圖標圖片的位面數(shù) ( 00) wBitCount:WORD;// 圖標圖片的顏色深度( 00) dwBytesInRes:DWORD;// 圖標圖片占用的數(shù)據(jù)量(000568) dwImageOffset:DWORD; // 圖標圖片的開始位置 (000046) end;.// 這個結(jié)構(gòu)是16個字節(jié)

　　上面說的idCount 表示圖標文件里包含的圖標個數(shù)，每個圖標都要有一個tagIconDirEntry結(jié)構(gòu)來表示圖標的具體信息。根據(jù)本結(jié)構(gòu)的dwBytesInRes和dwImageOffset我們就可以確定圖片（圖標）的位置了。在該位置的數(shù)據(jù)是一個稱為agIconImage的記錄，它是這樣定義的：

tagIconImage = packed record icHeader:TBitmapInfoHeader; //BMP文件的信息頭 icColors:array[0..0]of TRGBQuad; icXOR:array[0..0]of BYTE; icAND:array[0..0]of BYTE; end;

　　從這個定義中我們可以看出，這個內(nèi)容就是一個標準的位圖格式，只不過多了兩項，icXOR和icAND，普通的位圖信息里是沒有這2 個成員的。大家知道，圖標在被顯示時，是利用遮罩方法將 2 副位圖在同一個位置顯示才產(chǎn)生任意輪廓的，先使用 XOR 位 圖摳出需要顯示的區(qū)域，然后再在摳出的區(qū)域中顯示出需要顯示的圖形。由于這個緣故，圖標的位圖格式中的位圖信息頭 ( TBitmapInfoHeader ) 是 2 個位圖共用 的。它與普通位圖頭信息最大的不同是 TBitmapInfoHeader.biHeight 成員，顯然它是 2 副位圖高度的總和。講到這里，我們需要對位圖（BMP）文件的格式有些了解了。

　　位圖文件的格式

　　BMP文件由文件頭、位圖信息頭、顏色信息和圖形數(shù)據(jù)四部分組成。按照微軟的定義，在開始的文件頭由14個字節(jié)組成：

tagBITMAPFILEHEADER= packed record bfType:WORD; // 位圖文件的類型，必須為BM bfSize:DWORD; // 位圖文件的大小，以字節(jié)為單位 bfReserved1:WORD; // 位圖文件保留字，必須為0 bfReserved2:WORD; // 位圖文件保留字，必須為0 bfOffB its:DWORD; // 位圖數(shù)據(jù)的起始位置，以相對于位圖 // 文件頭的偏移量表示，以字節(jié)為單位 End;

　　緊接著上一記錄的是位圖信息頭tagBITMAPINFOHEADER，BMP位圖信息頭數(shù)據(jù)用于說明位圖的尺寸等信息。這個信息頭就是上文說的TBitmapInfoHeader，它的長度固定為40字節(jié)。

tagBITMAPINFOHEADER= packed record biSize:DWORD; // 本結(jié)構(gòu)所占用字節(jié)數(shù) biWidth:LONGINT // 位圖的寬度，以像素為單位 biHeight; :LONGINT // 位圖的高度，以像素為單位 biPlanes; :WORD // 目標設備的級別，必須為1 biBitCount :WORD // 每個像素所需的位數(shù)，必須是1(雙色), // 4(16色)，8(256色)或24(真彩色)之一 biCompression :DWORD; // 位圖壓縮類型，必須是 0(不壓縮), // 1(BI_RLE8壓縮類型)或2(BI_RLE4壓縮類型)之一 biSizeImage :DWORD; // 位圖的大小，以字節(jié)為單位 biXPelsPerMeter:LONGINT; // 位圖水平分辨率，每米像素數(shù) biYPelsPerMeter:LONGINT; // 位圖垂直分辨率，每米像素數(shù) biClrUsed:DWORD;// 位圖實際使用的顏色表中的顏色數(shù) biClrImportant:DWORD;// 位圖顯示過程中重要的顏色數(shù) End;

　　緊接著就是顏色表，用于說明位圖中的顏色，它有若干個表項，每一個表項是一個RGBQUAD類型的結(jié)構(gòu)，定義一種顏色。RGBQUAD結(jié)構(gòu)的定義如下:

tagRGBQUAD = packed record rgbBlue:BYTE;// 藍色的亮度(值范圍為0-255) rgbGreen:BYTE; // 綠色的亮度(值范圍為0-255) rgbRed:BYTE; // 紅色的亮度(值范圍為0-255) rgbReserved:BYTE;// 保留，必須為0 end;

　　顏色表中RGBQUAD結(jié)構(gòu)數(shù)據(jù)的個數(shù)有biBitCount來確定:

　　當biBitCount=1,4,8時，分別有2,16,256個表項;

　　當biBitCount=24時，沒有顏色表項。

　　位圖信息頭和顏色表組成位圖信息，BITMAPINFO結(jié)構(gòu)定義如下:

tagBITMAPINFO = packed record bmiHeader :BITMAPINFOHEADER; // 位圖信息頭 bmiColors[0..0] :RGBQUAD; // 顏色表 End;