GZIP壓縮原理分析（06）——第三章 gzip文件格式詳解（三04） gzip文件格式實例分析以及本章總結

這裏簡單提一下字節順序的問題，爲了理解起來更快更清晰，我不說大小端的問題，只要各位看官記住分析套路先把gzip文件格式分析清楚，知道實際的二進制存儲方式即可。後續章節分析壓縮源碼的時候會結合代碼說明。

 

實例一：

原始文件的文件信息如下，

 使用UE打開將該文件經過gzip壓縮後的結果，如下圖所示，

 我們逐字節分析，開始的10個字節是固定頭部，即00000000h行0~9列就是這10個字節。

行                ，列

0000 0000h, 0~1，開始的兩個字節是標識符1F8B；

0000 0000h, 2，CM (Compression Method)，壓縮方式，08表示deflate算法；

0000 0000h, 3，FLG (FLaGs)，標誌位，十六進制08，即二進制0000 1000，從右往左分別是bit0~bit7，現在bit3置位，對應FNAME，即該gzip頭後面的擴展部分是帶着原始文件名的；

0000 0000h,4~7，這四個字節是時間，分別是十六進制“38 DA 71 57”，這是存儲的順序，我們轉換成人們正常讀取的順序“57 71 DA 38”，將其轉換成時間，先把5771DA38轉換成十進制即1467079224，再使用在線時間戳轉換工具得到如下圖所示結果

 該結果與實際的原始文件信息對應。

0000 0000h, 8，XFL (eXtra FLags)，十六進制02，這個地方我也有點糊塗，但我估計應該是用的XFL = 4 - compressorused fastest algorithm；

0000 0000h, 9，00，即0 - FAT filesystem (MS-DOS, OS/2,NT/Win32)，我用的是win7，也是對應的。

0000 0000h, a~00000010h, 1，共8個字節，存儲的是原始文件的文件名“abc.txt”，末尾還有個'\0'表示結束，從這裏可以看出，這個文件名只是個文件名，沒攜帶路徑信息。從這裏往後，就是實際的壓縮數據信息了；

0000 0030h, b~e，這四個字節是CRC32校驗碼，分別是十六進制“45 2D F1 80”，這是存儲的順序，我們轉換成人們正常讀取的順序“80 F1 2D 45”，原文件內容爲“abcabcabcdeabcdefghijklmnopqrstopqrstuvvvvabcabcabcdeabcdefghijklmnopqrstuv”，使用CRC計算器算得結果如下圖所示

 這個結果與我們解析出的結果是相同的。

0000 0030h, f~0000 0040h, 2，這四個字節是原始文件的大小，分別是十六進制“4B 00 00 00”，這是存儲的順序，我們轉換成人們正常讀取的順序“00 00 00 4B”，即十進制的75，原始文件大小75字節，這也與文件信息對應。

到此，實例一完成。GZIP文件的基本分析方法就是這樣，很簡單，照着格式一步一步來就好。需要注意的是，這裏對CRC32的分析、文件原始長度的分析以及相應工具的使用非常重要，後續章節要分析gzip源碼，調試過程中難免出現異常，到時候就要依靠類似的推理方法以及工具。

 

實例二：

上面我們分析了針對文件的壓縮，現在我們分析經過gzip壓縮的HTTP應答報文。使用wireshark抓包，請求報文的HOST是“finance.sina.com.cn”，如下圖所示，

這是經過壓縮的HTTP應答報文，HTTP數據長度908個字節（這是經過壓縮之後的數據長度），圖中固定長度的那10個字節已經被圈出來了，可以看出只有四個字節有效，具體含義參考實例一分析，這裏不再贅述。我們看下圖，

 末尾的八個字節，CRC32我們不分析了，主要看原始數據長度，這裏是“ED 0A 00 00”，使用人們習慣的方式是“00 00 0A ED”，轉換成10進制就是2797，即原始長度是2797個字節。從這裏我們可以初步看到壓縮對於網絡傳輸時減小帶寬的好處。如下圖所示，是wireshark的解壓結果，

 

本章總結

本章我們分析了gzip文件格式各個字段的含義，並用兩個實例進行實踐，其中用到了一些工具，這些工具都極易獲得，是我當初分析以及修改gzip1.2.4源碼時，調試代碼常用的工具。前文對RFC1952部分內容做了粗淺的翻譯，有些直譯有些意譯，不足之處還請大家海涵，如果能在評論中指出，小僧感激不盡。另，gzip壓縮不支持加密。