Quicklz壓縮演算法

以前對壓縮演算法一無所知，只是知道哈弗曼編碼能做這種事情，但是感覺這樣的方法奇慢無比。昨天下午看了下號稱世界上最快的壓縮演算法quicklz，對壓縮的基本思路有了一定的了解。一般的壓縮程式的要求讀入檔案之後以便壓縮一邊輸出，而不是去先分析整個檔案中的情況之後才做決定採取哪種演算法。

quicklz也不例外也是爭取利用檔案中重複出現的位元組來進行壓縮，管理結構如下：

在壓縮的過程中不斷地讀入3個位元組，然後根據這3個位元組得到乙個hash值，根據這個hash值就可以找到offset，這個offset就是上次這個hash值出現的位置，而通過cache可以判斷出這次出現的和最近一次出現相同hash值的時候的3個位元組是不是相同（可能hash相同而實際的值不同）。

如果相同的長度在3到18之間，那麼這些情況可以用4個位來表示。而大於18小於255的情況則需要8位來表示，剛才用於表示長度的低4為則全部變為0，以區別兩種情況。在level=1的時候就只有這兩種情況了。在壓縮的過程中用4個位元組來記錄壓縮操作，如果有壓縮則為1，否則為0。下面是level=1時候的情況：

level=1的時候有個很明顯的問題是只記錄了乙個hash相同時候的cache，這樣的話只能等到與上次的值相同才能壓縮，而與以前的值相同也不行。在level=2和level=3的時候彌補了這個缺陷，但是代價就是壓縮的時間變長。在level=2的時候儲存了4個offset（相同hash的位置），然後在這四個中取到重複位元組長度最長的乙個作為壓縮選項（這個值儲存在最低的2位中），而重複的長度資訊儲存在接下來的3個位中（如果夠的話，不然初始化這3個位為0，在hash值後面的乙個位元組中儲存），其他的地方就和level=1的時候相同了。壓縮後檔案的格式如下：

在上面的情況中我們發現如果是3個位元組相同的話只能把它壓縮成2個位元組。而在level=3的時候彌補了這個缺陷，在level=3的時候與前兩個的不同之處是最低的兩位統一作為標誌，記錄進行了什麼操作，具體的**如下：

if(matchlen == 3 && offset <= 63)
else
if (matchlen == 3 && offset <= 16383)
else
if (matchlen <= 18 && offset <= 1023)
else
if(matchlen <= 33)
else

雖然最後的兩種情況的最低兩位都是11，但是從下面的格式圖中一眼就能看出區別（對應上面的**看）：

這裡知道了檔案被壓縮後儲存的儲存格式，下面考慮一下怎麼解壓。在level=3的時候解壓方法還是很好理解的。但是在level=1和level=2的時候怎麼解壓呢？畢竟壓縮檔案中只是儲存了hash值，而沒有指出重複的位元組串，甚至連offset都沒有給出。這裡其實很好理解，因為第一次遇到乙個hash的時候當然是不會去壓縮它的，那麼在解壓程式中我們就得到了offset的值，並且隨著解壓的進行，hash和offset的值與壓縮時候的變化是相同的，所有不必儲存這些值也能保證正確的解壓。

個人理解，歡迎拍磚。

Quicklz壓縮演算法

Quicklz壓縮演算法

quicklz 介面函式

使用quicklz縮小程式體積

Quicklz壓縮演算法

Quicklz壓縮演算法

quicklz 介面函式

使用quicklz縮小程式體積

相關推薦