哈弗曼編碼

首先說明一下涉及到的資料結構：

typedef struct ct_data {
    union {
        ush  freq;       /* frequency count */
        ush  code;       /* bit string */
    } fc;
    union {
        ush  dad;        /* father node in Huffman tree */
        ush  len;        /* length of bit string */
    } dl;
} ct_data;

（ush是

哈弗曼編碼的輸入

在gzip中，哈弗曼編碼可看作是LZ77的下一級壓縮，但哈弗曼編碼並不直接處理LZ77輸出的第一手材料，而是做了一步對映。

dyn_dtree對應d_buf，其資料的取值範圍在0到32K之間，gzip將這32K的範圍對映到

dyn_ltree對應l_buf。l_buf中literal和length是混雜的，且兩者的取值範圍都是0到255，完全重疊在一起，如果直接哈弗曼編碼，解壓時，除非參照flag_buf，否則無法區分。之前第二篇計算最小匹配長度時，曾假設（距離-長度）二元組在上下文中能自說明，不需要額外的描述符(如flag_buf）。為了讓假設成真，gzip將length對映到[257, 285]這29個節點（用256表示block結束），所以解壓時，值大於

那麼這個對映是怎麼做的呢？這樣多對一的對映，解壓時又該怎麼還原呢？

對映的方法就是將原數值的後幾位位元（稱為extra bit）截斷，這樣就對映到了比較小的值了。解壓時，先解碼對映後的小數值，被截斷的位元緊隨其後，直接拷貝就行了，具體要拷貝多少位元視小數值而定：

int extra_dbits[30] /* extra bits for each distance code */
   = {0,0,0,0,1,1,2,2,3,3,4,4,5,5,6,6,7,7,8,8,9,9,10,10,11,11,12,12,13,13};

這是距離extra bit長度的定義；

int extra_lbits[29] /* extra bits for each length code */
   = {0,0,0,0,0,0,0,0,1,1,1,1,2,2,2,2,3,3,3,3,4,4,4,4,5,5,5,5,0};

這是長度extra bit長度的定義。