1、lz77壓縮演算法
zlib壓縮使用lz77壓縮演算法的乙個變種，關於lz77壓縮演算法，可參考兩篇文章和這兩篇文章對lz77已經介紹得很詳細了。
本來想翻譯一下zlib-1.2.7中的doc/algorithm.txt，看完內容後發現它對演算法實現的介紹也是概述性的，站的角度比較高，沒有太多細節。
在網上搜到一篇文章《更多0
1、lz77壓縮演算法
zlib壓縮使用lz77壓縮演算法的乙個變種，關於lz77壓縮演算法，可參考兩篇文章和這兩篇文章對lz77已經介紹得很詳細了。
本來想翻譯一下zlib-1.2.7中的doc/algorithm.txt，看完內容後發現它對演算法實現的介紹也是概述性的，站的角度比較高，沒有太多細節。
在網上搜到一篇文章<2、識別純文字檔案
對於純文字檔案，zlib的壓縮過程可以加快（gzip頭部資訊的首個欄位即標記檔案是否為文字檔案）。這涉及到識別純文字檔案的問題。下面內容整理自zlib-1.2.7的doc/txtvsbin.txt。
給定乙個不知**的檔案，有時我們希望識別它是不是純文字格式。這看起來好像是一項簡單的任務，實際上對檔案型別的精確識別需要對檔案進行高強度的語義分析。然而，通過開發多種啟發式演算法，可以獲得比較滿意的識別結果。
以前的pkzip版本和其他一些相容zip的壓縮工具使用一種粗糙的識別方法：如果在某個緩衝區中有80%(4/5)以上的位元組在範圍[7..127]內，則檔案被認為是純文字的，否則被認為是二進位制格式。這種方法的乙個明顯侷限是只限制在拉丁字母範圍內。其他的字母，如希臘字母、斯拉夫字母或者亞洲語言字母等，其位元組廣泛使用[128...255]範圍的編碼。使用這些字元的文字通常會被前述識別方法錯判。也就是說，漏報率有時是非常高的，這意味著召回率很低。這種方法另外乙個缺點是識別的精確度比較低，因為誤報經常會發生，例如包含大量的文字型字元的二進位制檔案被誤報為文字檔案。
zlib使用一種新的、簡單的識別方法，它的識別精確度大大提高，且有幾乎100%的召回率。這種方法可以工作在ascii, unicode和其他源自ascii的字母表上，能夠處理單位元組的編碼（iso-8859, macroman, koi8等）和可變大小的編碼（iso-2022, utf-8等），但不能處理更廣泛的編碼（ucs-2/utf-16和ucs-4/utf-32）。
演算法描述：
識別演算法把位元組碼[0...255]分成三大類：
（1）白名單：文字型位元組碼，包括9(tab), 10(lf), 13(cr), 32(space)到255。
（2）灰名單：可容忍的位元組碼，包括7(bel), 8(bs), 11(vt), 12(ff), 26(sub), 27(esc)。
（3）黑名單：不能容忍的、非文字型位元組碼，包括0(nul)到6, 14到31。
如果檔案至少有乙個位元組屬於白名單且沒有位元組屬於黑名單，則檔案被認為是純文字的，否則是二進位制格式。（對於邊界條件，當檔案為空時，自動識別為二進位制格式）。
本演算法背後的思想源於兩個觀察。首先，雖然ascii標準使用了7-bit編碼的完整範圍[0...127]，但是大部分[0...31]範圍內的控制字元在實踐中並沒有使用，只有9(tab), 10(lf)和13(cr)被廣泛使用，且普遍可移植。還有幾個控制字元在一些小範圍的平台上使用：7(bel), 8(bs), 11(vt), 12(ff), 26(sub)和27(esc)，但是這些位元組碼很少單獨使用，一般只是混合於可列印的文字中。即使是更新的、可移植的文字格式如xml，都避免使用這兩個名單以外的控制字元。其次，許多二進位制檔案傾向於包含控制字元，特別是0(nul)。對於原來的文字檔案識別方法，即使把高階範圍[128...255]當作文字型字元，在觀測這個範圍的編碼出現時，其識別精確度也很難滿意，因為二進位制檔案都傾向於包含控制字元和高階範圍內的字元。另一方面，高階範圍確實需要當作文字，因為它實際上被所有的ascii擴充套件所使用，特別是用於非拉丁字元的編碼。
我們不涉及計算，只是觀察一些位元組碼的出現和不出現，無論使用什麼字符集，本演算法都產生一致的結果。如果涉及計算，則在乙個文字型字元上可能會產生不同的結果，例如使用iso-8859-16和utf-8來比較。
有一類被黑名單中的字元「汙染」的純文字檔案，要麼是因為錯誤，要麼是因為特殊的設計考慮。在這種情況下，容忍一小部分黑名單字元的識別方法將產生比較高的召回率（即正報而不是誤報），但是這樣會降低整個識別精確度，因為在包含大量文字資料的二進位制檔案上更有可能發生誤報。此外，通過通用的文字識別方法，「汙染」了的文字檔案應該被識別為二進位制檔案，但是通用的文字處理演算法可能不可用。在這樣的前提下，可以安全地說，我們的識別方法提供了幾乎100%的召回率。
本演算法已經在來自各種平台和應用程式的檔案上執行過，我們試驗過文字檔案、系統日誌、源**檔案、有格式的office文件、編譯後的obj檔案，等等。結果驗證了對本演算法能力的樂觀設想。
編譯 Lua 的 zlib 庫 lua zlib
最近需要使用 lua 給 wireshark 寫個外掛程式 dissector 苦於基於 c 的文件實在是太少了，乾脆就用 lua 來寫。但是 lua 也真是夠 輕量 的，官方都沒有個支援 zlib 壓縮 解壓的庫。最後終於找到了 lua zlib url 可以支援實時的流 stream 壓縮 解壓...
zlib庫的編譯和使用
windows下編譯有很多種方法。1 在contrib vstudio資料夾下，使用對應版本的vs開啟，執行。備註 1 如果編譯過程 現 fatal error lnk1281 無法生成 safeseh 映像 的錯誤，則將該項目的 屬性頁 鏈結器 高階 映像具有安全異常處理程式 選 否 2 此版本生...
zlib程式設計
一 簡介 zlib是提供資料壓縮用的函式庫，使用deflate演算法，最初是為libpng函式庫所寫的，後來普遍為許多軟體所使用，今天，zlib是一種事實上的業界標準。二 基本資訊 資料頭 header zlib能使用乙個gzip資料頭，zlib資料頭或者不使用資料頭壓縮資料。通常情況下，資料壓縮使...