我正在搜索压缩小文本字符串的算法：50-1000字节（即URL）。哪种算法最适合这个？
答案 0 :(得分：56)
结帐Smaz：
Smaz是一个简单的压缩库，适合压缩很短 字符串。
答案 1 :(得分：28)
霍夫曼有静态成本，霍夫曼表，所以我不同意这是一个不错的选择。
有适应性版本可以消除这种情况，但压缩率可能会受到影响。 实际上，你应该问的问题是“压缩具有这些特征的文本字符串的算法”。例如，如果预期长时间重复，则简单的Run-Lengh编码可能就足够了。如果你能保证只有英文单词，空格，punctiation和偶然的数字，那么带有预定义Huffman表的Huffman可能会产生很好的结果。
通常，Lempel-Ziv系列的算法具有非常好的压缩和性能，并且它们的库很多。我会选择那个。
有了被压缩的信息是URL的信息，那么我建议在压缩之前（使用任何容易获得的算法），你可以对它们进行CODIFY。 URL遵循定义明确的模式，其中某些部分具有高度可预测性。通过利用这些知识，您可以将URL编码为较小的内容，并且霍夫曼编码背后的想法可以帮助您。
例如，将URL转换为比特流，您可以将“http”替换为位1，其他任何位置为“0”，后跟实际的procotol（或者使用表来获取其他常用协议，像https，ftp，file）。只要您可以标记协议的结尾，就可以完全删除“：//”。等等。阅读有关URL格式的内容，并考虑如何编写它们以减少占用空间。
答案 2 :(得分：22)
我没有代码可以处理，但我总是喜欢构建大小为256 * 256个字符（RFC 1978， PPP预测器压缩协议）的2D查找表的方法。要压缩字符串，您将遍历每个char并使用查找表来使用当前和前一个char作为表中的索引来获取“预测的”下一个char。如果匹配则写入1位，否则写入0，char并使用当前char更新查找表。这种方法基本上维护了数据流中最可能的下一个字符的动态（和粗略）查找表。
你可以从一个归零的查找表开始，但是如果用最可能的字符对每个字符对进行初始化（例如，对于英语语言），则很明显它在非常短的字符串上效果最好。只要初始查找表对于压缩和解压缩是相同的，您就不需要将其发送到压缩数据中。
这种算法不能提供出色的压缩比，但它对内存和CPU资源非常节俭，并且还可以处理连续的数据流 - 解压缩器在解压缩时维护自己的查找表副本，因此查找表调整为被压缩的数据类型。
答案 3 :(得分：11)
任何支持预设字典的算法/库，例如zlib
这样，您可以使用可能出现在输入中的相同类型的文本来填充压缩器。如果文件在某种程度上相似（例如所有URL，所有C程序，所有StackOverflow帖子，所有ASCII艺术图纸），那么某些子字符串将出现在大多数或所有输入文件中。
如果在一个输入文件中多次重复相同的子字符串，则每个压缩算法都会节省空间（例如，英文文本中的“the”或C代码中的“int”。）
但在URL的情况下，某些字符串（例如“http://www。”，“。com”，“。html”，“。aspx”通常会在每个输入文件中出现一次。所以你需要分享它们在文件之间以某种方式而不是每个文件都有一个压缩事件。将它们放在预设字典中就可以实现这一点。
答案 4 :(得分：5)
如果您正在谈论实际压缩文本而不仅缩短然后Deflate / gzip（gzip包装），zip可以很好地用于较小的文件和文本。其他算法对于bzip2等较大的文件非常有效。
Wikipedia有一个压缩时间列表。 （寻找效率的比较）
Name | Text | Binaries | Raw images
-----------+--------------+---------------+-------------
7-zip | 19% in 18.8s | 27% in 59.6s | 50% in 36.4s
bzip2 | 20% in 4.7s | 37% in 32.8s | 51% in 20.0s
rar (2.01) | 23% in 30.0s | 36% in 275.4s | 58% in 52.7s
advzip | 24% in 21.1s | 37% in 70.6s | 57& in 41.6s
gzip | 25% in 4.2s | 39% in 23.1s | 60% in 5.4s
zip | 25% in 4.3s | 39% in 23.3s | 60% in 5.7s
答案 5 :(得分：4)
Huffman coding通常可以正常使用。
答案 6 :(得分：2)
您可能需要查看Standard Compression Scheme for Unicode。
SQL Server 2008 R2在内部使用它，可以实现高达50％的压缩。