Gzip / Deflate是否识别模式

Question

我正在研究Gzip的内部结构，并且我知道它使用了Huffman编码和LZ77的组合。

我还意识到，Gzip文件分为几个块，每个块都有一个专门为其构建的字典。 然后，将频繁出现的相似数据替换为指向字典中各个位置的指针。

因此，短语“马赛跑等马”将不得不通过指针一词改为马 。

但是，如果我有一个32位整数数组，但它最多只能存储24位数字怎么办？ 为了争辩，可以说这24位数字是非常随机的，很难压缩，很难在其中找到重复。

这将使每个整数的前8位易于压缩为0的字符串，但是每个字符串将需要一个指针，并且每个指针仍占用一定数量的数据。 即使是1位的指针（据我所知，它比实际可能的还要小）仍将占据原始空间的12.5％。

当阵列可以通过基本模式识别轻松地简化为“ 24位”阵列时，这似乎有些多余。

所以我的问题是：

Gzip是否包含任何比字典指针更好地压缩文件的机制？

Gzip压缩少量重复数据，然后压缩少量难压缩数据的性能如何？

Answer 1

每个deflate块都没有“为此构建的字典”。 为每个放气块构建的是一组用于文字/长度符号和距离符号的霍夫曼代码。

您引用的字典只是32K字节的未压缩输入，紧接在当前正在压缩的字节之前。 而已。 每个长度/距离对可以引用最后32K中3到258个字节的字符串。 这与放气块无关，并且此类引用通常返回一个或多个块。

Deflate尝试压缩三个随机字节，零字节，三个随机字节，零字节的序列时效果不佳...将没有有用的重复字符串，其中deflate仅能对霍夫曼编码文本，其中零为更频繁。 它将零编码为两位，因为它们发生的时间略超过25％，其余字面量至少每个为8.25位。 对于此数据，将平均每字节提供约6.7位或压缩比为0.85。 实际上，gzip给出的数据约为0.86。

如果要压缩该序列， 只需删除零字节！ 然后，您完成了操作，不再可能以0.75的比率进行压缩。