一种高效的短文本字符串压缩算法[closed]

Smaz :

串。

霍夫曼有一个静态成本,霍夫曼表,所以我不同意这是一个好的选择。

有了被压缩的是URL的信息,那么我建议,在压缩之前(使用任何容易获得的算法),先将它们合并。URL遵循定义良好的模式,其中一些部分是高度可预测的。通过利用这些知识,您可以将URL编码成更小的东西,霍夫曼编码背后的想法可以在这里为您提供帮助。

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

zlib .

但在URL的情况下,某些字符串(例如“ http://www “.”、“.com”、“.html”、“.aspx”通常会在每个输入文件中出现一次。因此,您需要以某种方式在文件之间共享它们,而不是每个文件只出现一次压缩。将它们放置在预设字典中可以实现这一点。

Huffman coding

Standard Compression Scheme for Unicode .

SQL Server 2008 R2在内部使用它,可以实现高达50%的压缩。

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