PNG文件格式分為PNG-24和PNG-8，其最大的區別是PNG-24是用24位來保存一個像素值，是真彩色，而PNG-8是用8位索引值來在調色盤 中索引一個顏色，因為一個索引值的最大上限為2的8次方既128，故調色盤中顏色數最多為128種，所以該文件格式又被叫做PNG-8 128仿色。PNG-24因為其圖片容量過大，而且在Nokia和Moto等某些機型上創建圖片失敗和顯示不正確等異常時有發生，有時還會嚴重拖慢顯示速度，故并不常 用，CoCoMo認為這些異常和平臺底層的圖像解壓不無關系。不過該格式最大的優點是可以保存Alpha通道，同事也曾有過利用該圖片格式實現Alpha 混合的先例，想來隨著技術的發展，手機硬件平臺的提升，Alpha混合一定會被廣泛的應用，到那時該格式的最大優勢才會真正發揮。?

8 bit PNGs use an indexed color palette like GIF. If you want variable transparency, use 32bit PNGs (24 bit color, 8 bit alpha). If you don't care about transparency, use 24 bit PNGs.

?

PNG-8文件是目前廣泛應用的PNG圖像格式，其主要有六大塊組成：

?1.PNG文件標志，為固定的64個字節：0x89504e47 0x0d0a1a0a

?2.文件頭數據塊IHDR(header chunk)

3.調色板數據塊PLTE(palette chunk)

4.sBIT,tRNS塊?等。。。

5.圖像數據塊IDAT(image data chunk)

6.圖像結束數據IEND(image trailer chunk)，固定的96個字節：0x00000000 0x49454e44 0xae426082

?這六大塊按順序排列，也就是說IDAT塊永遠是在PLTE塊之后，期間也會有許多其他的區塊用來描述信息，例如圖像的最后修改時間是多少，圖像的創建者是誰等，不過這些區塊的信息對我們來說都是可有可無的描述信息，故壓縮時一般先向這些區塊開刀。

?

??數據塊1-4：?

除了PNG文件標志，其中四大數據塊和文件尾都是由統一的數據塊文件結構描述的：????????

??????? Chunk Length: 4byte????????

? ? ? ? Chunk Type:???4byte????????

??????? Chunk Data:???Chunk Length的長度????????

??????? Chunk CRC:??? 4byte

?例如IHDR塊的數據長度為13，既????????

?????? Chunk Length = 13 ????????

?????? Chunk Type = "IHDR"

?

IHDR塊：

?用來描述圖像的基本信息，其格式為：????????

圖像寬：??? 4byte???????

圖像高：??? 4byte???????

圖像色深： 4byte???????

顏色類型：?1byte???????

壓縮方法： 1byte???????

濾波方法： 1byte???????

掃描方法： 1byte?

曾經有人問過我，撒叫濾波方法和掃描方法，汗，說實話我也不知道，不過我們是在做手機游戲，不是在搞圖形學不是嘛。

PLTE塊：?

這個就是傳說中放置調色盤數據的地方啦，其格式為：??????

???? 循環???????????

???????? RED：??? 1byte???????????

???????? GREEN：1byte???????????

???????? BLUE：? 1byte??????

???? END

?循環長度嘛，不就是Chunk Length / 3的長度嘛，而且Chunk Length一定為3的倍數。

tRNS塊：?

這個塊時有時無，主要是看你是否使用了透明色。該區塊的格式為：???????

?????? 循環???????????

??????????? if(對應調色盤顏色非透明)????????????????

?????????????????? 0xFF：? 1byte???????????

??????????? else???????????????

?????????????????? 0x00：? 1byte??????

?????? END?

循環長度為調色盤的顏色數，相當于調色盤顏色表的一個對應表，標識該顏色是否透明，0xFF不透明，0x00透明。故如果用UltraEdit查看PNG文件的二進制編碼，如果看到一大片FF，一般就是tRNS區塊啦，因為一個PNG文件一般只有一個透明色。

?

??IDAT塊：?這個就是存放圖像數據的地方啦，這里要注意的是一個PNG文件可能有多個IDAT區塊，而其他三大區塊只可能有一個。?IDAT 區塊是經過壓縮的，所以數據不可讀?，壓縮算法一般為LZ77滑動窗口算法，如果硬要看里面的數據的話，用zlib庫也是可以的，CoCoMo當年就見過 Windows Mobile上的帝國時代巨變態的用zlib庫壓縮和解壓該區塊來進一步減少PNG文件大小，真是寸K寸金啊。

IEND塊：?該區塊雖然也按照數據塊的結構，但Chunk Data是沒有的，所以是固定的96個字節：0x00000000 0x49454e44 0xae426082

IEND數據塊的長度總是0（00 00 00 00，除非人為加入信息），數據標識總是IEND（49 45 4E 44），因此，CRC碼也總是AE 42 60 82。

?

PNG圖像壓縮：?
??????? 了解了PNG的文件結構，壓縮就有的放矢了。壓縮有6個級別，可以根據需要選擇。
Level1：讀取PNG文件，將除六大塊之外的所有區塊都過濾掉
Level2：文件頭是固定的0x89504e47 0x0d0a1a0a，文件尾是固定的0x00000000 0x49454e44 0xae426082，去掉！
Level3：每個區塊的Chunk Type我們是否需要呢？很明顯，我們自己寫的壓縮格式自己應該清楚是按照什么樣的順序，去掉！
Level4：每個區塊的Chunk Length我們是否需要呢？
?????????? IHDR塊：定長13個字節，明顯不需要，去掉。
?????????? PLTE塊：最多128個顏色，為撒要用4byte來記錄區塊長度而不是用1byte來記錄顏色數呢？
?????????? tRNS塊：既然有顏色數，tRNS又是調色盤顏色表的對應表，既數量與顏色數相同，為撒還需要呢？
?????????? IDAT塊：我想這個是唯一需要4byte來記錄長度的區塊。
Level5：每個區塊的Chunk CRC是否需要呢？
?????????? 因為計算CRC需要一些時間，但對于字節較少的區塊一般可以忽略不計，所以對于這個問題還是由程序員自己決定吧。對于CRC的計算可以參看CoCoMo的另一篇Blog“PNG文件的CRC碼計算”
Level6：每個區塊我們是否要原封不動的保存期數據呢？
????????? IHDR塊：除了寬、高、色深是需要的，后面那4byte的信息是固定的0x03000000
????????? PLTE塊：為撒要用3byte來表示RGB而不是2byte的565格式？壓縮方法可以參看CoCoMo的另一篇Blog“關于PNG圖像壓縮的一點感悟”
????????? tRNS塊：我想tRNS塊是冗余最多的區塊了吧，大段大段的0xFF明顯沒有必要，一般的PNG文件只有一個透明色，為撒要用對應表的方法而不是一個索 引來記錄到底哪個是透明色呢？由于顏色數最多128，所以只需1byte就可以代替tRNS那么多0xFF啦。
????????? IDAT塊：么想法，如果你夠變態，把zlib加進來吧！

PNG圖像解壓：?
????????創建了自定義的文件，J2ME端讀取后，就面臨解壓的問題了。我們可以利用此函數來創建Image：
static?Image
createImage(byte[]?imageData, int?imageOffset, int?imageLength)
???? 前提是傳入的imageData與PNG未被壓縮前的一致。因為PNG文件格式是固定的，所以讀取自定義的壓縮文件后，開始將那些默認的數據再添加進去，實現解壓的目的。下面就開始解壓之旅吧!
首先要創建一個ByteArrayOutputStream out，

1.寫入文件頭：
out.writeInt(0x89504e47);
out.writeInt(0x0d0a1a0a);

2.寫入IHDR塊
out.writeInt(13);
out.writeInt(0x49484452);? //0x49484452為Chunk Type "IHDR"
out.writeInt(width);
out.writeInt(height);
out.writeByte(depth);
out.writeInt(0x03000000);? //壓縮時舍掉的4byte，默認0x03000000
out.writeInt(crc);
其他區塊方法一致，故略過。。。

3.寫入文件尾
out.writeInt(0x00000000);
out.writeInt(0x49454e44);
out.writeInt(0xae426082);

4.轉換成數組，創建Image
byte[] pngBuffer = out.toByteArray();
Image image = Image.createImage(pngBuffer, 0, pngBuffer.length);

哈哈，大功告成。這里注意如果中途數據寫入有錯誤，經常會出現創建Image失敗的異常，而且非常不好調試，不過只要自定的壓縮格式定下來后，對應的創建Image的函數只要寫一次，以后基本不會出問題哈。

PNG圖像加解密：?
??????? 很多人都擔心自己辛苦創作的漂亮的美術圖片很easy就被別人拿到了，究其原因是由于PNG文件格式是固定的，稍微了解的人用UltraEdit很容易就 能找到IHDR，PLTE等標識了。CoCoMo就經常看GameLoft的圖像文件，哈哈。一般是2byte的Length，然后緊接著圖片數據，都放 在一個文件里，直接拷貝2進制然后粘貼到一個新文件里就是一幅圖。后來的加密技術會把PNG分塊，例如前100個字節一塊，緊接著1K一塊，最后剩余字節 一塊，然后把塊順序打亂，用2byte來記錄總長度，1byte記錄順序，但是這并沒有從根本上消除IHDR，IEND這些顯眼的定位標識，好像在對破解 者說：嘿，看，我就在這里！
?????? 現在了解了之前的壓縮和解壓技術，這個問題也就迎刃而解了，因為Chunk Length，Chunk Type和Chunk CRC這些東西都消失了，甚至連數據塊本身的數據都修改了，我可以按照ImageWidth、ImageHeight、ImageDepth的順序寫數 據，也可以倒過來寫。我想再牛的PNG分析器也是無能為力的吧，唯一可以定位的就只有IDAT區塊了，不過就算得到該區塊的數據，也應該是一張黑白圖。

?

?

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

?

附錄

PNG文件結構分析(上：了解PNG文件存儲格式)

?

PNG的文件結構

對于一個PNG文件來說，其文件頭總是由位固定的字節來描述的：

十進制數	137 80 78 71 13 10 26 10
十六進制數	89 50 4E 47 0D 0A 1A 0A

其中第一個字節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	圖像結束數據	否	否	最后一個數據塊

為了簡單起見，我們假設在我們使用的PNG文件中，這4個數據塊按以上先后順序進行存儲，并且都只出現一次。

?

?

數據塊結構

PNG文件中，每個數據塊由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中，其值按下面的CRC碼生成多項式進行計算：

x³²?+x²⁶?+x²³?+x²²?+x¹⁶?+x¹²?+x¹¹?+x¹⁰?+x⁸?+x⁷?+x⁵?+x⁴?+x²?+x+1

下面，我們依次來了解一下各個關鍵數據塊的結構吧。

?

IHDR

文件頭數據塊IHDR(header chunk)：它包含有PNG文件中存儲的圖像數據的基本信息，并要作為第一個數據塊出現在PNG數據流中，而且一個PNG數據流中只能有一個文件頭數據塊。

文件頭數據塊由13字節組成，它的格式如下表所示。

域的名稱	字節數	說明
Width	4 bytes	圖像寬度，以像素為單位
Height	4 bytes	圖像高度，以像素為單位
Bit depth	1 byte	圖像深度：? 索引彩色圖像：1，2，4或8? 灰度圖像：1，2，4，8或16? 真彩色圖像：8或16
ColorType	1 byte	顏色類型： 0：灰度圖像, 1，2，4，8或16? 2：真彩色圖像，8或16? 3：索引彩色圖像，1，2，4或8? 4：帶α通道數據的灰度圖像，8或16? 6：帶α通道數據的真彩色圖像，8或16
Compression method	1 byte	壓縮方法(LZ77派生算法)
Filter method	1 byte	濾波器方法
Interlace method	1 byte	隔行掃描方法： 0：非隔行掃描? 1： Adam7(由Adam M. Costello開發的7遍隔行掃描方法)

由于我們研究的是手機上的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

關于更多的信息，可以參考http://www.w3.org/TR/REC-png.html

?

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。

?

實例研究PNG

以下是由Fireworks生成的一幅圖像，圖像大小為8*8，?為了方便大家觀看，我們將圖像放大：

?

使用UltraEdit32打開該文件，如下：
00000000~00000007：

可以看到，選中的頭8個字節即為PNG文件的標識。

?

?

接下來的地方就是IHDR數據塊了：

00000008~00000020：

• 00 00 00 0D 說明IHDR頭塊長為13
• 49 48 44 52 IHDR標識
• 00 00 00 08 圖像的寬，8像素
• 00 00 00 08 圖像的高，8像素
• 04 色深，2^4=16，即這是一個16色的圖像（也有可能顏色數不超過16，當然，如果顏色數不超過8，用03表示更合適）
• 03 顏色類型，索引圖像
• 00 PNG Spec規定此處總為0（非0值為將來使用更好的壓縮方法預留），表示使壓縮方法(LZ77派生算法)
• 00 同上
• 00 非隔行掃描
• 36 21 A3 B8 CRC校驗

?

?

00000021~0000002F：

可選數據塊sBIT，顏色采樣率，RGB都是256（2^8=256）

?

?

00000030~00000062：

這里是調色板信息

• 00 00 00 27 說明調色板數據長為39字節，既13個顏色數
• 50 4C 54 45 PLTE標識
• FF FF 00 顏色0
• FF ED 00 顏色1
• …… ……
• 09 00 B2 最后一個顏色，12
• 5F F5 BB DD CRC校驗

?

?

00000063~000000C5：

這部分包含了pHYs、tExt兩種類型的數據塊共3塊，由于并不太重要，因此也不再詳細描述了。

?

000000C0~000000F8：

以上選中部分是IDAT數據塊

• 00 00 00 27 數據長為39字節
• 49 44 41 54 IDAT標識
• 78 9C…… 壓縮的數據，LZ77派生壓縮方法
• DA 12 06 A5 CRC校驗

IDAT中壓縮數據部分在后面會有詳細的介紹。

?

?

000000F9~00000104：

IEND數據塊，這部分正如上所說，通常都應該是 00 00 00 00 49 45 4E 44 AE 42 60 82

?

?

至此，我們已經能夠從一個PNG文件中識別出各個數據塊了。由于PNG中規定除關鍵數據塊外，其它的輔助數據塊都為可選部分，因此，有了這個標準后，我們 可以通過刪除所有的輔助數據塊來減少PNG文件的大小。（當然，需要注意的是，PNG格式可以保存圖像中的層、文字等信息，一旦刪除了這些輔助數據塊后， 圖像將失去原來的可編輯性。）

刪除了輔助數據塊后的PNG文件，現在文件大小為147字節，原文件大小為261字節，文件大小減少后，并不影響圖像的內容。

其實，我們可以通過改變調色板的色值來完成一些又趣的事情，比如說實現云彩/水波的流動效果，實現圖像的淡入淡出效果等等，在此，給出一個鏈接給大家看也許更直接：http://blog.csdn.net/flyingghost/archive/2005/01/13/251110.aspx?，我寫此文也就是受此文的啟發的。

如 上說過，IDAT數據塊是使用了LZ77壓縮算法生成的，由于受限于手機處理器的能力，因此，如果我們在生成IDAT數據塊時仍然使用LZ77壓縮算法， 將會使效率大打折扣，因此，為了效率，只能使用無壓縮的LZ77算法，關于LZ77算法的具體實現，此文不打算深究，如果你對LZ77算法的JAVA實現 有興趣，可以參考以下兩個站點：

• http://jazzlib.sourceforge.net/
• http://www.jcraft.com/jzlib/index.html

?

?

?

PNG文件結構分析(下：在手機上生成PNG文件)

上面我們已經對PNG的存儲格式有了了解，因此，生成PNG圖片只需要按照以上的數據塊寫入文件即可。

(由于IHDR、PLTE的結構都非常簡單，因此，這里我們只是重點講一講IDAT的生成方法，IHDR和PLTE的數據內容都沿用以上的數據內容)

問題確實是這樣的，我們知道，對于大多數的圖形文件來說，我們都可以將實際的圖像內容映射為一個二維的顏色數組，對于上面的PNG文件，由于它用的是16色的調色板（實際是13色），因此，對于圖片的映射可以如下：

(調色板對照圖)

12	11	10	9	8	7	6	5
11	10	9	8	7	6	5	4
10	9	8	7	6	5	4	3
9	8	7	6	5	4	3	2
8	7	6	5	4	3	2	1
7	6	5	4	3	2	1	0
6	5	4	3	2	1	0	0
5	4	3	2	1	0	0	0

?

PNG Spec中指出，如果PNG文件不是采用隔行掃描方法存儲的話，那么，數據是按照行(ScanLine)來存儲的，為了區分第一行，PNG規定在每一行的前面加上0以示區分，因此，上面的圖像映射應該如下：

0	12	11	10	9	8	7	6	5
0	11	10	9	8	7	6	5	4
0	10	9	8	7	6	5	4	3
0	9	8	7	6	5	4	3	2
0	8	7	6	5	4	3	2	1
0	7	6	5	4	3	2	1	0
0	6	5	4	3	2	1	0	0
0	5	4	3	2	1	0	0	0

?

另外，需要注意的是，由于PNG在存儲圖像時為了節省空間，因此每一行是按照位(Bit)來存儲的，而并不是我們想象的字節（Byte），如果你沒有忘記的話，我們的IHDR數據塊中的色深就指明了這一點，所以，為了湊成PNG所需要的IDAT，我們的數據得改成如下：

0	203	169	135	101
0	186	152	118	84
0	169	135	101	67
0	152	118	84	50
0	135	101	67	33
0	118	84	50	16
0	101	67	33	0
0	84	50	16	0

?

最后，我們對這些數據進行LZ77壓縮就可以得到IDAT的正確內容了。

然而，事情并不是這么簡單，因為我們研究的是手機上的PNG，如果需要在手機上完成LZ77壓縮工作，消耗的時間是可想而知的，因此，我們得再想辦法加減少壓縮時消耗的時間。好在LZ77也提供了無壓縮的壓縮方法（奇怪吧？），因此，我們只需要簡單的使用無壓縮的方式寫入數據就可以了，這樣雖然浪費了空間，卻換回了時間！

?

好了，讓我們看一看怎么樣湊成無壓縮的LZ77壓縮塊：

字節	意義
0~2	壓縮信息，固定為0x78, 0xda, 0x1
3~6	壓縮塊的LEN和NLEN信息
壓縮的數據
最后4字節	Adler32信息

其 中的LEN是指數據的長度，占用兩個字節，對于我們的圖像來說，第一個Scan Line包含了5個字節（如第一行的0, 203, 169, 135, 101），所以LEN的值為5（字節/行） * 8（行） = 40（字節），生成字節為28 00（低字節在前），NLEN是LEN的補碼，即NLEN = LEN ^ 0xFFFF，所以NLEN的為 D7 FF，Adler32信息為24 A7 0B A4（具體算法見源程序），因此，按照這樣的順序，我們生成IDAT數據塊，最后，我們將IHDR、PLTE、IDAT和IEND數據塊寫入文件中，就可 以得到PNG文件了，如圖：
?
至此，我們已經能夠采用最快的時間將數組轉換為PNG圖片了

?

?

參考資料：

PNG文件格式白皮書：http://www.w3.org/TR/REC-png.html?
為數不多的中文PNG格式說明：http://dev.gameres.com/Program/Visual/Other/PNGFormat.htm?
RFC-1950(ZLIB Compressed Data Format Specification)：ftp://ds.internic.net/rfc/rfc1950.txt?
RFC-1950(DEFLATE Compressed Data Format Specification)：ftp://ds.internic.net/rfc/rfc1951.txt?
LZ77算法的JAVA實現：http://jazzlib.sourceforge.net/?
LZ77算法的JAVA實現，包括J2ME版本：http://www.jcraft.com/jzlib/index.html

總結

以上是生活随笔為你收集整理的png图片结构分析与加密解密原理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。