一种有效的短文本字符串压缩算法

我正在寻找一种压缩小文本字符串的算法：50-1000个字节（即URL）。哪种算法对此最有效？

查看Smaz：

Smaz是一个简单的压缩库，适用于压缩非常短的字符串。

霍夫曼表具有静态成本，即霍夫曼表，因此我不同意这是一个不错的选择。

有一些适应性版本可以解决此问题，但是压缩率可能会受到影响。实际上，您应该问的问题是“使用哪种算法压缩具有这些特征的文本字符串”。例如，如果需要长时间重复，则简单的运行长度编码就足够了。如果可以保证仅显示英文单词，空格，标点和偶数位，那么带有预定义霍夫曼表的霍夫曼可能会产生良好的结果。

通常，Lempel-Ziv系列的算法具有很好的压缩和性能，并且存在大量的库。我会去的。

有了要压缩的信息就是URL，那么我建议您在压缩之前（使用任何容易获得的算法）将它们编码。URL遵循定义明确的模式，并且其中的某些部分是高度可预测的。通过利用这些知识，您可以将URL编入较小的内容，而Huffman编码背后的想法可以为您提供帮助。

例如，将URL转换为位流，您可以将“ http”替换为位1，并将其他任何内容替换为“ 0”，再加上实际的procotol（或使用表格获取其他常见协议，例如https， ftp，文件）。只要可以标记协议的结尾，就可以完全删除“：//”。等阅读有关URL格式的内容，并思考如何将它们编成代码以减少空间。

我没有可用的代码，但是我一直喜欢构建大小为256 * 256个字符的2D查找表的方法（RFC 1978，PPP预测器压缩协议）。要压缩字符串，您可以遍历每个字符，并使用查找表使用当前和上一个字符作为表的索引来获取“预测的”下一个字符。如果匹配，则写入单个1位，否则写入0，即为char，并使用当前char更新查询表。这种方法基本上维护了数据流中最可能出现的下一个字符的动态（原始）查找表。

您可以从零查找表开始，但是如果用每个字符对（例如英语）中最有可能的字符初始化的话，那么它很适合在很短的字符串上使用。只要用于压缩和解压缩的初始查找表相同，就无需将其发送到压缩数据中。

该算法的压缩率不高，但是在内存和CPU资源方面却非常节俭，并且还可以处理连续的数据流-解压缩器在解压缩时会维护自己的查找表副本，因此查找表调整为要压缩的数据类型。

支持预设字典的任何算法/库，例如zlib。

这样，您可以使用可能在输入中出现的相同类型的文本为压缩器加注。如果文件在某种程度上是相似的（例如，所有URL，所有C程序，所有StackOverflow帖子，所有ASCII美术绘图），则某些子字符串将出现在大多数或所有输入文件中。

如果在一个输入文件中多次重复相同的子字符串（例如，英文文本中的“ the”或C代码中的“ int”），则每种压缩算法都会节省空间。

但是，对于URL，某些字符串（例如“ http：// www。”，“ .com”，“ .html”，“ .aspx”通常在每个输入文件中出现一次，因此需要在文件之间共享它们以某种方式而不是每个文件压缩一次，将它们放置在预设字典中即可达到目的。

霍夫曼编码通常可以正常工作。

如果您在谈论实际上压缩文本而不仅仅是缩短文本，则可以使用Deflate / gzip（围绕gzip的包装器），zip适用于较小的文件和文本。其他算法对于较大的文件（例如bzip2等）非常高效。

维基百科列出了压缩时间。（寻找效率比较）

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

您可能想看看Unicode的标准压缩方案。

SQL Server 2008 R2在内部使用它，并且可以实现高达50％的压缩。