對於一個PNG文件來說，其文件頭總是由位固定的字節來描述的，HEX： 89 50 4E 47 0D 0A 1A 0A
使用ultra打開一個png圖片，結果如下：
其中第一個字節0x89超出了ASCII字符的范圍，這是為了避免某些軟件將PNG文件當做文本文件來處理。文件中剩余的部分由3個以上的PNG的數據塊（Chunk）按照特定的順序組成，因此，一個標准的PNG文件結構應該如下：
| PNG文件標志 |
PNG數據塊 |
…… |
PNG數據塊 |
PNG數據塊（Chunk）
PNG定義了兩種類型的數據塊，一種是稱為關鍵數據塊(critical chunk)，這是標准的數據塊，另一種叫做輔助數據塊(ancillary chunks)，這是可選的數據塊。關鍵數據塊定義了4個標准數據塊，每個PNG文件都必須包含它們，PNG讀寫軟件也都必須要支持這些數據塊。你可以從“可選否”一欄查看是否必須支持的數據塊。雖然PNG文件規范沒有要求PNG編譯碼器對可選數據塊進行編碼和譯碼，但規范提倡支持可選數據塊。
下表就是PNG中數據塊的類別，其中，關鍵數據塊部分我們使用深色背景加以區分。
| PNG文件格式中的數據塊 |
||||
| 數據塊符號 |
數據塊名稱 |
多數據塊 |
可選否 |
位置限制 |
| IHDR |
文件頭數據塊 |
否 |
否 |
第一塊 |
| cHRM |
基色和白色點數據塊 |
否 |
是 |
在PLTE和IDAT之前 |
| gAMA |
圖像γ數據塊 |
否 |
是 |
在PLTE和IDAT之前 |
| sBIT |
樣本有效位數據塊 |
否 |
是 |
在PLTE和IDAT之前 |
| PLTE |
調色板數據塊 |
否 |
是 |
在IDAT之前 |
| bKGD |
背景顏色數據塊 |
否 |
是 |
在PLTE之后IDAT之前 |
| hIST |
圖像直方圖數據塊 |
否 |
是 |
在PLTE之后IDAT之前 |
| tRNS |
圖像透明數據塊 |
否 |
是 |
在PLTE之后IDAT之前 |
| oFFs |
(專用公共數據塊) |
否 |
是 |
在IDAT之前 |
| pHYs |
物理像素尺寸數據塊 |
否 |
是 |
在IDAT之前 |
| sCAL |
(專用公共數據塊) |
否 |
是 |
在IDAT之前 |
| IDAT |
圖像數據塊 |
是 |
否 |
與其他IDAT連續 |
| tIME |
圖像最后修改時間數據塊 |
否 |
是 |
無限制 |
| tEXt |
文本信息數據塊 |
是 |
是 |
無限制 |
| zTXt |
壓縮文本數據塊 |
是 |
是 |
無限制 |
| fRAc |
(專用公共數據塊) |
是 |
是 |
無限制 |
| gIFg |
(專用公共數據塊) |
是 |
是 |
無限制 |
| gIFt |
(專用公共數據塊) |
是 |
是 |
無限制 |
| gIFx |
(專用公共數據塊) |
是 |
是 |
無限制 |
| IEND |
圖像結束數據 |
否 |
否 |
最后一個數據塊 |
這里要補充一個iCCP
數據塊結構
PNG文件中，每個數據塊（比如IHDR，cHRM，IDAT等）由4個部分組成，如下：
| 名稱 |
字節數 |
說明 |
| Length (長度) |
4字節 |
指定數據塊中數據域的長度，其長度不超過(231－1)字節 |
| Chunk Type Code (數據塊類型碼) |
4字節 |
數據塊類型碼由ASCII字母(A-Z和a-z)組成 |
| Chunk Data (數據塊數據) |
可變長度 |
存儲按照Chunk Type Code指定的數據 |
| CRC (循環冗余檢測) |
4字節 |
存儲用來檢測是否有錯誤的循環冗余碼 |
CRC(cyclic redundancy check)域中的值是對Chunk Type Code域和Chunk Data域中的數據進行計算得到的。CRC具體算法定義在ISO 3309和ITU-T V.42中.
注意：Length值的是除：length本身，Chunk Type Code，CRC外的長度，也就是Chunk Data的長度。
下面，我們依次來了解一下各個【關鍵數據塊】的結構
IHDR
文件頭數據塊IHDR(header chunk)：它包含有PNG文件中存儲的圖像數據的基本信息，並要作為第一個數據塊出現在PNG數據流中，而且一個PNG數據流（文件）中只能有一個文件頭數據塊。
文件頭數據塊由13字節組成，它的格式如下表所示：
| 域的名稱 |
字節數 |
說明 |
| Width |
4 bytes |
圖像寬度，以像素為單位 |
| Height |
4 bytes |
圖像高度，以像素為單位 |
| Bit depth |
1 byte |
圖像深度： |
| ColorType |
1 byte |
顏色類型： |
| Compression method |
1 byte |
壓縮方法(LZ77派生算法) |
| Filter method |
1 byte |
濾波器方法 |
| Interlace method |
1 byte |
隔行掃描方法： |
由於我們研究的是手機上的PNG，因此，首先我們看看MIDP1.0對所使用PNG圖片的要求吧：
● 在MIDP1.0中，我們只可以使用1.0版本的PNG圖片。並且，所以的PNG關鍵數據塊都有特別要求：
IHDR
● 文件大小：MIDP支持任意大小的PNG圖片，然而，實際上，如果一個圖片過大，會由於內存耗盡而無法讀取。
● 顏色類型：所有顏色類型都有被支持，雖然這些顏色的顯示依賴於實際設備的顯示能力。同時，MIDP也能支持alpha通道，但是，所有的alpha通道信息都會被忽略並且當作不透明的顏色對待。
● 色深：所有的色深都能被支持。
● 壓縮方法：僅支持壓縮方式0（deflate壓縮方式），這和jar文件的壓縮方式完全相同，所以，PNG圖片數據的解壓和jar文件的解壓可以使用相同的代碼。（其實這也就是為什么J2ME能很好的支持PNG圖像的原因：））
● 濾波器方法：盡管在PNG的白皮書中僅定義了方法0，然而所有的5種方法都被支持！
● 隔行掃描：雖然MIDP支持0、1兩種方式，然而，當使用隔行掃描時，MIDP卻不會真正的使用隔行掃描方式來顯示。
● PLTE chunk：支持
● IDAT chunk：圖像信息必須使用5種過濾方式中的方式0 (None, Sub, Up, Average, Paeth)
● IEND chunk：當IEND數據塊被找到時，這個PNG圖像才認為是合法的PNG圖像。
● 可選數據塊：MIDP可以支持下列輔助數據塊，然而，這卻不是必須的。
bKGD cHRM gAMA hIST iCCP iTXt pHYs
sBIT sPLT sRGB tEXt tIME tRNS zTXt
關於更多的信息，可以參考www.w3.org
pHYs
物理像素數據塊，它表示了圖片的像素尺寸，或者是高寬比，它的結果如下
| Pixels per unit, X axis |
4 bytes (PNG unsigned integer) |
| Pixels per unit, Y axis |
4 bytes (PNG unsigned integer) |
| Unit specifier |
1 byte |
unit specifier的定義如下：
| 0 |
unit is unknown |
| 1 |
unit is the metre |
PLTE
調色板數據塊PLTE(palette chunk)包含有與索引彩色圖像(indexed-color image)相關的彩色變換數據，它僅與索引彩色圖像有關，而且要放在圖像數據塊(image data chunk)之前。
PLTE數據塊是定義圖像的調色板信息，PLTE可以包含1~256個調色板信息，每一個調色板信息由3個字節組成：
| 顏色 |
字節 |
意義 |
| Red |
1 byte |
0 = 黑色, 255 = 紅 |
| Green |
1 byte |
0 = 黑色, 255 = 綠色 |
| Blue |
1 byte |
0 = 黑色, 255 = 藍色
|
因此，調色板的長度應該是3的倍數，否則，這將是一個非法的調色板。
對於索引圖像，調色板信息是必須的，調色板的顏色索引從0開始編號，然后是1、2……，調色板的顏色數不能超過色深中規定的顏色數（如圖像色深為4的時候，調色板中的顏色數不可以超過2^4=16），否則，這將導致PNG圖像不合法。
真彩色圖像和帶α通道數據的真彩色圖像也可以有調色板數據塊，目的是便於非真彩色顯示程序用它來量化圖像數據，從而顯示該圖像。
IDAT
圖像數據塊IDAT(image data chunk)：它存儲實際的數據，在數據流中可包含多個連續順序的圖像數據塊。
IDAT存放着圖像真正的數據信息，因此，如果能夠了解IDAT的結構，我們就可以很方便的生成PNG圖像。
IEND
圖像結束數據IEND(image trailer chunk)：它用來標記PNG文件或者數據流已經結束，並且必須要放在文件的尾部。
如果我們仔細觀察PNG文件，我們會發現，文件的結尾12個字符看起來總應該是這樣的：00 00 00 00 49 45 4E 44 AE 42 60 82
不難理解，由於數據塊結構的定義，IEND數據塊的長度總是0（00 00 00 00，除非人為加入信息），數據標識總是IEND（49 45 4E 44），因此，CRC碼也總是AE 42 60 82。
IHDR cHRM pHYs IEND
