1. 程式人生 > >GZIP壓縮原理分析(19)——第五章 Deflate演算法詳解(五10) 演算法分析(04) 格式說明(03) 靜態哈夫曼編碼

GZIP壓縮原理分析(19)——第五章 Deflate演算法詳解(五10) 演算法分析(04) 格式說明(03) 靜態哈夫曼編碼

靜態哈夫曼編碼(Compression with fixed Huffman codes),這部分內容只要看格式就好,出現在這裡的碼錶只是為了說明,細節此時可能不懂,但是後面會鋪開來講,不用擔心。

靜態哈夫曼編碼使用一張固定的literal/length碼錶,碼錶如下,

                  Lit Value                Bits                     Codes

                  ---------                 ----                      -----

                    0 - 143                   8                        00110000   through 10111111

                  144 - 255                 9                        110010000 through 111111111

                  256 - 279                 7                        0000000     through 0010111

                  280 - 287                 8                        11000000   through 11000111

Lit Value代表literal/length值,0-255是ASCII碼,256-287代表另外的含義,後面再介紹,286和287永遠不會用到;Bits是碼字長度,Codes就是對應的碼字。

靜態哈夫曼編碼還使用一張固定的distance碼錶,直接用5bits(五位元)對0-31這三十二個數編碼,擴充套件位的編碼方式與動態哈夫曼編碼中的distance表相同,該表會在下面講動態哈夫曼編碼的時候給出。

由於使用靜態哈夫曼編碼的碼錶是固定的,所以每塊使用靜態哈夫曼編碼的壓縮塊只有塊首部,而沒有類似儲存方式(store)那樣的專門的格式。塊首部後面緊跟著就是經過靜態哈夫曼編碼的二進位制碼流,即位元流。由於塊首部後面就是二進位制碼流,所以不會出現上面儲存型別中為了補齊一個位元組而浪費幾位元的情況。例如,

上圖所示是對原始檔案fix_huffman.txt進行gzip壓縮之後的結果,檔案內容為“aaaaaaaaaaaaaaaaa”,剝掉gzip頭和尾之後,deflate壓縮資料以(00000010h,3)開頭,以(00000010h,6)結尾。(00000010h,3)處的資料為“0x4B”,轉換為二進位制就是“01001011”,第二個位元組“0x44”轉換為二進位制就是“0100 0100”。

先分析“0100 1011”。從右往左讀,1表示這是最後一個壓縮塊;再往左讀兩位,是BTYPE,BTYPE內部不能從右往左讀,就是實實在在的二進位制“01”,代表靜態哈夫曼編碼。現在塊首部已經讀完,再往左讀就是實際的壓縮位元流了。將“0100 1”從右往左讀作“1 0010”。

再分析“0100 0100”,由於已經讀完塊首部,那麼這個位元組就是實際壓縮位元流的一部分,所以將其從右往左讀作“0010 0010”。拼上上一個位元組的那五位(五位元),我們現在分析的這部分位元流就是“1 00100010 0010”,對照靜態哈夫曼編碼的literal/length碼錶(為什麼要對照這張碼錶而不是那張固定的distance碼錶,看到後面就知道了,這裡暫且不表),發現從左往右的8bits(八位元),即“1 0010001”,就是字元a在該表中的碼字!!!後面的位元流就不解碼了,之後還會有更詳盡的例子。

總結,靜態哈夫曼編碼的格式就是:塊首部 + 經過編碼的位元流。