Compression 泄气：反向参考真的更好吗？

我正在制作我自己的放气压缩机，它几乎每次都能打败ZLIB库

在DEFLATE格式（LZ77）中，数据流要么包含一个字节文本，要么包含一个反向引用，表示我们应该从先前解码的字节复制一个字节序列。压缩器通常执行LZ77（找到尽可能多的引用），然后构建一个哈夫曼树并压缩该字节/引用流

可能存在一种极端情况：引用3个相同的字节，长度由15位编码，距离由15+13位编码，而编码的字节在我们的哈夫曼树中仅为1位。差异为43位与3位。使用引用使输出比直接编码字节大14倍

我的问题如下：我有一个10097918b的文本文件。ZLIB在其LZ77中通过引用覆盖9089334 B，而我的压缩机覆盖9305056 B。所以我想我可以说我的LZ77更好

---

但是ZLIB给出了一个1329309b文件，而我的程序给出了一个1381153 B文件（两者都构建了一个最优的哈夫曼树）。因此，更好的LZ77会导致更差的哈夫曼编码。有关于哈夫曼友好型LZ77的研究吗？

这是一个难题，因为在做出所有决定后，你只知道与这些决定相关的比特成本，不管是采用文字还是反向引用。但是您可以迭代并使用上一次运行的成本来做出这些决策，同时多次重新编码，直到您对结果满意为止

---

这是Zopfli在保持DEFLATE格式的同时，为了获得更好的压缩比所做的一件事，除了使用最短路径方法而不是贪婪的决策之外。

你也很了解ZLIB吗？我有一个文件，ZLIB压缩后比压缩后小。但是我的压缩通过反向引用覆盖了更多的字节（例如，我的3字节引用比ZLIB多2倍）。所以我想知道他们是怎么做到的。我不擅长阅读C代码。@IvanKuckir也许你没有实现惰性匹配？过于贪婪地使用火柴会妨碍找到更长的火柴。这可以解释为什么会有更多的小匹配我前面确实有两个位置的惰性匹配（即，如果下一个位置有更长的匹配，我只在这里写一个字节）。它减少了文件大小，但也减少了引用所覆盖的字节数。。。所以奇怪的是，也要确保你使用的是距离当前位置最短的反向参考。。。以帮助最大限度地减少由于相距较远的匹配而产生的额外位数。