查看Smaz：

Smaz是一個(gè)簡(jiǎn)單的壓縮庫(kù)，適用于壓縮非常短的字符串。

霍夫曼表具有靜態(tài)成本，即霍夫曼表，因此我不同意這是一個(gè)不錯(cuò)的選擇。

有一些適應(yīng)性版本可以解決此問題，但是壓縮率可能會(huì)受到影響。實(shí)際上，您應(yīng)該問的問題是“使用哪種算法壓縮具有這些特征的文本字符串”。例如，如果需要長(zhǎng)時(shí)間重復(fù)，則簡(jiǎn)單的運(yùn)行長(zhǎng)度編碼就足夠了。如果可以保證僅顯示英文單詞，空格，標(biāo)點(diǎn)和偶數(shù)位，那么帶有預(yù)定義霍夫曼表的霍夫曼可能會(huì)產(chǎn)生良好的結(jié)果。

通常，Lempel-Ziv系列算法具有很好的壓縮和性能，并且有大量的庫(kù)供他們使用。我會(huì)去的。

有了被壓縮的是URL的信息，那么我建議您在壓縮之前（使用任何容易獲得的算法）對(duì)它們進(jìn)行編碼。URL遵循定義明確的模式，并且其中的某些部分是高度可預(yù)測(cè)的。通過利用這些知識(shí)，您可以將URL編入較小的內(nèi)容，而Huffman編碼背后的思想可以為您提供幫助。

例如，將URL轉(zhuǎn)換為位流，您可以將“ http”替換為位1，將其他任何內(nèi)容替換為“ 0”，再加上實(shí)際的procotol（或使用表格獲取其他常見協(xié)議，例如https， ftp，文件）。只要可以標(biāo)記協(xié)議的結(jié)尾，就可以完全刪除“：//”。等閱讀有關(guān)URL格式的內(nèi)容，并思考如何將它們編碼以減少空間。

我沒有可用的代碼，但是我一直喜歡構(gòu)建大小為256 * 256個(gè)字符的2D查找表的方法（RFC 1978，PPP Predictor壓縮協(xié)議）。要壓縮字符串，請(qǐng)遍歷每個(gè)字符，并使用查找表使用當(dāng)前和上一個(gè)字符作為表的索引來獲取“預(yù)測(cè)的”下一個(gè)字符。如果匹配，則寫入單個(gè)1位，否則寫入0，即為char，并使用當(dāng)前char更新查詢表。這種方法基本上維護(hù)了數(shù)據(jù)流中最可能出現(xiàn)的下一個(gè)字符的動(dòng)態(tài)（原始）查找表。

您可以從零查找表開始，但是如果它用每個(gè)字符對(duì)（例如英語）中最有可能出現(xiàn)的字符初始化，則很顯然，它在非常短的字符串上最有效。只要初始查找表對(duì)于壓縮和解壓縮是相同的，就不需要將其發(fā)送到壓縮數(shù)據(jù)中。

該算法的壓縮率不高，但是在內(nèi)存和CPU資源方面卻非常節(jié)儉，并且還可以處理連續(xù)的數(shù)據(jù)流-解壓縮器在解壓縮時(shí)會(huì)維護(hù)自己的查找表副本，因此查找表調(diào)整為要壓縮的數(shù)據(jù)類型。