DEFLATE方法推理答案

【问题标题】：DEFLATE method reasoningDEFLATE方法推理
【发布时间】：2016-09-28 23:36:09
【问题描述】：

为什么 LZ77 DEFLATE 在第二遍使用 Huffman 编码而不是 LZW？他们的组合有什么是最佳的吗？如果是这样，LZ77 输出的本质是什么使其比 LZW 或其他一些方法更适合 Huffman 压缩？

【问题讨论】：

他们本可以选择范围编码器作为后端（但速度较慢，而且将这些扩展位放入比特流中会有点烦人），或者今天可能是 ANS。

标签： compression huffman-code deflate lzw lz77

【解决方案1】：

LZW 试图利用重复的字符串，就像 LZ77 的第一个“阶段”一样。然后它在熵编码该信息方面做得很差。 LZW 已被更现代的方法完全取代。（除了它在 GIF 格式中的传统用途。）一旦 LZ77 生成一个文字和匹配列表，LZW 就没有什么可以利用的了，然后它将为该信息制作一个几乎完全无效的熵编码器。

【讨论】：

是否有其他压缩方法可以发挥与霍夫曼编码相同的作用，这意味着受益于高频字符？霍夫曼编码是否被证明是最优的？
是的，还有其他几个。例如。算术编码、范围编码和有限状态熵以速度为代价提供更好的压缩。
为什么压缩的性能比压缩的大小更有价值？性能差距这么大吗？另外，谢谢你，我会研究这些其他方法。
举个例子，您可以通过压缩来减少需要传输的数据量。但是，如果将数据减少一定数量所花费的时间超过了简单传输相同数量所花费的时间，那么进行压缩可能就不值得了。
但是您不能在不重复压缩/解压缩的情况下大量移动/存储压缩数据吗？大小仍然不是存储的最终决定因素吗？我也在两个不同的背景下考虑这些问题，第一个是开源库中的实现，第二个是理论压缩和事物的信息论方面。您是否只在第一个上下文中回答？

【解决方案2】：

Mark Adler could best answer this question.

LZ77 和霍夫曼如何协同工作的细节需要更仔细的研究。一旦原始数据被转换成字符串和特殊的长度、距离对，这些元素必须用霍夫曼代码表示。

虽然这不是标准术语，但重复一遍，不是标准术语，将我们开始读取位的点称为“拨号音”。毕竟，在我们的类比中，拨号音是您可以开始指定一系列号码的地方，这些号码最终将映射到特定的电话。因此，将开头称为“拨号音”。在该拨号音中，可能会出现以下三种情况之一：字符、长度-距离对或块的结尾。由于我们必须能够分辨出它是什么，所有可能的字符（“文字”）、指示可能长度范围的元素（“长度”）和特殊的块尾指示符都合并为一个字母表.然后该字母表成为霍夫曼树的基础。距离不需要包含在这个字母表中，因为它们只能直接出现在长度之后。一旦文字被解码，或者长度-距离对被解码，我们就在另一个“拨号音”点，我们再次开始阅读。如果我们得到块结束符号，当然，我们要么在另一个块的开头，要么在压缩数据的结尾。

长度代码或距离代码实际上可能是一个表示基值的代码，后跟额外的位，形成一个要添加到基值的整数。

...

Read the whole deal here.

长话短说。 LZ77 提供重复消除功能。霍夫曼编码提供比特减少。 It's also on the wiki.

【讨论】：