*構建literal/length樹

部落格http://www.cnblogs.com/esingchan/p/3958962.html中這樣說道：“ZIP之所以是通用壓縮，它實際上是針對位元組作為基本字元來編碼的，所以一個literal至多有256種可能”。Literal其實就是一個位元組所能表示的所有字元，包括可見與不可見的，從十進位制0到255，共256種。Length表示匹配串長度，匹配串最小長度為3，這點我們已經在LZ77章節中多次提到；匹配串長度不是無限的，最大長度為258，所以length共有256種，範圍對應閉區間[3, 258]。如果實際匹配長度超過258，後面的匹配部分就再用一個長度距離對兒表示。

為什麼literal和length的取值個數都是256，都可以用一個位元組表示，這是巧合嗎？雖然那個隱含假設告訴我們相同的內容總是扎堆兒出現，但為什麼length的最大值偏偏是258？一路分析過來，我們已經發現，壓縮中任何一個數據的設計都不是巧合，都是刻意為之，都是有實際意義的！這種設計可以讓literal和length共用同一棵哈夫曼樹，一次編碼同時得到literal和length的碼字。

Literal的範圍是閉區間[0, 255]，length的範圍是閉區間[3, 258]。壓縮將這兩個區間編到同一張表中，從而將其整合到一起。閉區間[0, 255]仍然表示literal，關係是一對一的，一個數對應一個literal；256代表本壓縮塊的結束（前面我們講過壓縮是分塊進行的）；length共有256種值，和distance一樣，為了優化，將這256個值分到不同的區間，共有29個區間，區間碼範圍為閉區間[257, 285]。如下表所示（length區間碼錶），

閉區間[0, 285]將literal和length全部整合在一起，哈夫曼編碼就是針對這個閉區間進行的。[0, 256]是一對一的關係，參與哈夫曼編碼過程；[257, 285]是length的區間碼，這29個值參與哈夫曼編碼過程而不是256個length值參與哈夫曼編碼過程（與distance的使用方法是相同的）。壓縮結果也需要記錄閉區間[0, 285]這286個數的碼字長度，記錄方法與distance相同，使用一個數列，每個數在數列中的順序（從0開始）代表該數在閉區間[0, 285]中對應的值，而這個數本身代表該值的碼字長度。例如數列

“0、0、0、0、0、0、0、0、1、0、0、2、0、0、0、0、4、0、0……”，

該數列共有286個數，第零個0，表示閉區間[0, 258]中的零的碼字長度是0；第一個0，表示閉區間[0, 258]中的一的碼字長度是0；第二個0，表示閉區間[0, 258]中的二的碼字長度是0……第八個1，表示閉區間[0, 258]中的八的碼字長度是1……第十一個2，表示閉區間[0, 258]中的十一的碼字長度是2……第十六個4，表示閉區間[0, 258]中的十六的碼字長度是4……

現在我們為字串“As mentioned above,there a(3,01)many kinds of wirelesssystem(3,0110)(4,100111) than cellular.”中的literal和length編碼。統計該字串中每個literal的出現頻率，並將[0, 258]中未在該字元出現的literal的頻率記為0；將閉區間[0, 258]中的256的出現頻率記為1，作為壓縮塊結束標記；該字串中的length為3、3、4，對應區間碼分別為257、257、258，其中，區間碼257出現兩次，區間碼258出現一次，其餘length區間碼出現頻率全部為0。

根據以上資訊，構造哈夫曼樹。因為原始哈夫曼樹各節點深度與正規化哈夫曼樹相同，所以簡單起見，我們這裡專門構造一棵正規化哈夫曼樹來說明。如下圖所示，

碼錶如下，

從這張碼錶可以看出很多東西，比如字首碼、正規化哈夫曼編碼的各個性質、每層的碼字長度、出現頻率越高的字元碼字長度越短等。

碼錶已經得到，現在就可以對著這兩張碼錶將字串“As mentioned above,there a(3,01)many kinds of wirelesssystem(3,0110)(4,100111) than cellular.”徹底從位元組流程式設計位元流。開始轉換：

“A(011011)s(1110) (000)m(10101)e(100)n(0110)t(0001)i(00101)o(01101)n(0110)e(100)d(01001) (000)a(0010)b(111011)o(01101)v(001111)e(100),(001011)t(0001)h(11001)e(100)r(11101)e(100)(000)a(0010) (3(10011),01)m(10101)a(0010)n(0110)y(00011)(000)k(010111)i(00101)n(0110)d(01001)s(1110)(000)o(01101)f(100111)(000)w(101111)i(00101)r(11101)e(100)l(1010)e(100)s(1110)s(1110)(000)s(1110)y(00011)s(1110)t(0001)e(100)m(10101) (3(10011),0110)(4(111111),100111) (000)t(0001)h(11001)a(0010)n(0110)(000)c(000111)e(100)l(1010)l(1010)u(110111)l(1010)a(0010)r(11101).(101011)”。

每個字元都已經找到了自己的碼字，但此時並不能直接用碼字把原碼替換掉！雖然現在已經是位元流，但在記憶體或儲存介質中，壓縮結果必須按照位元組的方式儲存，也就是說，這條位元流必須放到一個個的位元組中去！現在，每個碼字本身已經符合記憶體中的實際儲存方式（即原始計算結果的逆序），但是碼字與碼字之間還沒有符合實際的儲存方式。將碼字填入位元組時，要從該位元組的低位開始填起，比如，先將A填入一個位元組，再將s填入該位元組，那麼A的碼字佔據該位元組的低位而s的碼字佔據該位元組的高位，以此類推，只要保證從每個位元組的低位開始填起就沒有問題。如果一個位元組剩餘的位元位不足以放下整個碼字，則該碼字從右往左能放幾位元就放幾位元，這個碼字剩下那幾個位元就放到另外一個位元組中。一定要看懂這個地方，會直接影響到後面的原始碼分析的。

將A的碼字的低兩位放到另外一個位元組，原因我們後續分析。末尾要帶上256的碼字，如果不夠一個位元組，就用0補齊剩下的位元。不同的碼字用不同的顏色進行區分，填充開始：

11

11100110   10101000    10110100    00101000    11001101   10011000    00100000    01111011

01111011   10111000    01000100    01100110    00100111   01100100    01010110    11000101

00000110   10101110    01100010    11001001    11010001   01001110    10111100    10100101

01010011   11101001    00001110    00011111    00011110   10101100    11010011    11111110

00010011   10010001    11000101    01110000    01010000   11110101    01010110    11101001

11101011   00000111

每看一個位元組的時候，要從右往左看，就可以看出碼字，一個碼字可能會跨越兩個位元組。對應的十六進位制結果是（不看A讓出去的那兩位）：

E6    A8    B4    28    CD    98    20    7B

7B    B8    44    66    27     64    56    C5

06    AE    62    C9    D1    4E    BC    A5

53    E9    0E    1F     1E    AC    D3    FE

13    91    C5   70     50    F5     56    E9

EB    07

最後用256的碼字表示該壓縮塊的結束，但是還剩4bits才夠一個位元組，所以剩下的4bits就全部用0補齊（這一點很重要，原始碼分析要用）。

這就是實際的壓縮結果，這個過程是我們完全用人工計算出來的，現在看看壓縮工具的壓縮結果，如下圖所示，

對著上面的位元流，有沒有產生這樣一個問題：這個位元流由兩張碼錶構成（literal碼錶和length碼錶同屬literal/length碼錶，為了說明方便才分開。另一個碼錶是distance碼錶），怎麼知道一個碼字該用哪張碼錶去解碼？其實很簡單，開始解碼的時候就用literal碼錶解碼，當發現一個碼字無法解碼時，說明這個碼字肯定是length的碼字，用length碼錶解碼；length後面跟著的肯定是distance碼字，所以解完length，後面的那個碼字就用distance碼錶解碼；解完distance碼字，再接著用literal碼錶解後續的碼字，重複這個過程即可。

之所以能這樣解碼，與壓縮時每個碼字放到位元流中的順序是分不開的。前面講LZ77的時候說過，待壓縮資料的首個字元不參與匹配過程，也就是說，長度距離對兒肯定不會在壓縮塊的開始位置出現（用腳趾頭都能想明白），所以解碼整個壓縮塊的首個碼字就用literal碼錶；每個長度距離對兒，distance的碼字都在length碼字的後面，從上面的位元流就可以看出，壓縮時先把length的碼字扔到位元流裡，再把distance的碼字扔到位元流裡，distance碼字緊跟在length碼字後面。

再次提醒，literal碼錶和length碼錶同屬literal/length碼錶，literal/length碼錶是“一”張表，與distance碼錶並列。

現在LZ77之後的結果已經全部轉換成了位元流，但是壓縮遠沒有結束，別忘了，還要記錄生成literal/length樹的資訊。閉區間[0, 285]中各值的碼字長度數列如下，

0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、3、0、0、0、0、0、0、0、0、0、0、0、6、0、6、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、6、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、4、6、6、5、3、6、0、5、5、0、6、4、5、4、5、0、0、5、4、4、6、6、6、0、5、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、6、5、6、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0

Distance各區間碼的碼字長度數列如下，

0、0、0、2、0、0、0、0、1、0、2、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0、0

原始字串被壓縮之後的位元流如下，

11

11100110    10101000   10110100    00101000    11001101   10011000    00100000    01111011

01111011    10111000   01000100    01100110    00100111   01100100    01010110    11000101

00000110    10101110   01100010    11001001    11010001   01001110    10111100    10100101

01010011    11101001   00001110    00011111    00011110   10101100    11010011    11111110

00010011    10010001   11000101    01110000    01010000   11110101    01010110    11101001

11101011    00000111

這個時候的壓縮結果，已經基本具有了雛形，該有的基本都有了：碼字長度資訊+實際壓縮資料。但是壓縮並沒有結束，這並不是最優的壓縮結果，還有繼續壓縮的空間。