我正在研究 Gzip 的内部工作原理，我知道它使用了 Huffman Coding 和 LZ77 的组合。
我还意识到Gzip文件被分成块，每个块都有一个为其构建的字典。然后，频繁出现的相似数据将被指向字典中位置的指针所取代。
因此，短语“horses race other horses”会将单词 horses 替换为指针。
但是，如果我有一个 32 位整数数组，但它最多只能存储 24 位数字怎么办？为了论证起见，我们假设这些 24 位数字非常随机，难以压缩，也很难找到重复。
这将使每个整数的前 8 位成为易于压缩的 0 字符串，但每个字符串都需要一个指针，并且每个指针仍然占用一定量的数据。即使是 1 位指针（我知道比实际可能的小）仍然会占用原始空间的 12.5%。
当数组可以很容易地简化为具有基本模式识别功能的“24 位”数组时，这似乎有点多余。
所以我的问题是：
Gzip 是否包含比字典指针更好地压缩文件的机制？
Gzip 压缩少量重复数据以及少量难以压缩数据的效果如何？
每个 deflate 块都没有“为其构建的字典”。为每个 deflate 块构建的是一组用于文字/长度符号和距离符号的霍夫曼代码。
您引用的字典只是紧邻当前正在压缩的字节之前的 32K 字节未压缩输入。就是这样。每个长度/距离对可以引用最后 32K 中 3 到 258 个字节的字符串。这与 deflate 块无关，并且此类引用通常会返回一个或多个块。
Deflate 无法很好地尝试压缩三个随机字节、零字节、三个随机字节、零字节的序列...不会有有用的重复字符串，其中 deflate 只能对文字进行霍夫曼编码，其中包含零更加频繁。它将 0 编码为两位，因为它们出现的时间略多于 25%，而其余的文字每个至少编码为 8.25 位。对于该数据，平均每个字节大约有 6.7 位，或者压缩率为 0.85。事实上，gzip 给出的数据约为 0.86。
如果您想压缩该序列，只需删除零字节即可！然后就完成了，无法以 0.75 的比率进一步压缩。
在很多情况下，数据看似随机，但存在潜在结构。在这种情况下，一般的位压缩器会表现得很糟糕，但预处理可以产生惊人的结果。
例如，如果你有一堆 x,y 坐标，这些数字看起来都相当随机，但如果它们代表车辆的轨迹，那么增量将不是随机的。因此，增量编码和其他更复杂的曲线拟合以及减去已知部分可以显着减少存储大小。