查看Smaz：

Smaz是一個簡單的壓縮庫，適用于壓縮非常短的字符串。

霍夫曼表具有靜態成本，即霍夫曼表，因此我不同意這是一個不錯的選擇。

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

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

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

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

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

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

該算法的壓縮率不高，但是在內存和CPU資源方面卻非常節儉，并且還可以處理連續的數據流-解壓縮器在解壓縮時會維護自己的查找表副本，因此查找表調整為要壓縮的數據類型。