blocks|key|301288|text|马克·阿德勒最好回答这个问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|301289|关于LZ77和赫夫曼是如何一起工作的细节需要更仔细的研究。一旦原始数据被转换成字符串和特殊的长度、距离对，这些元素必须用Huffman代码表示。
虽然这不是，重复，而不是标准术语，我们称之为点开始读比特“拨号音”。毕竟，在我们的类比中，拨号音是您可以开始指定一系列数字的地方，这些数字将最终映射到特定的电话。所以一开始就叫“拨号音”。在这个拨号音中，有三种情况之一:字符、长度-距离对或块的末尾。由于我们必须能够分辨出它是什么，所有可能的字符(“文字”)、表示可能长度范围的元素(“长度”)和一个特殊的块结束指示符都被合并到一个字母中。这个字母表就成了赫夫曼树的基础。距离不需要包含在这个字母表中，因为它们只能在长度之后直接出现。一旦文字已被解码，或长度-距离对解码，我们在另一个“拨号音”点，我们又开始阅读。如果我们得到了块结束符号，当然，我们要么位于另一个块的开头，要么位于压缩数据的末尾。
长度码或距离码实际上可能是表示基值的代码，后面跟着形成要添加到基值的整数的额外位数。
..。|blockquote|301290|把整件事都读下来。|301291|长话短说。LZ77提供重复消除。Huffman编码提供了位压缩。它也在维基上。|301292|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/users/1180620/mark-adler|1|http://www.zlib.net/feldspar.html|2|https://en.wikipedia.org/wiki/DEFLATE^0|0|F|0|0|0|0|9|1|0|W|7|2|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@$A|X|B|Y|1|Z]]|C|$]]|$1|D|3|E|5|F|7|10|8|@]|9|@]|C|$]]|$1|G|3|H|5|6|7|11|8|@]|9|@$A|12|B|13|1|14]]|C|$]]|$1|I|3|J|5|6|7|15|8|@]|9|@$A|16|B|17|1|18]]|C|$]]|$1|K|3|-4|5|6|7|19|8|@]|9|@]|C|$]]]|L|$M|$5|N|O|P|C|$Q|R]]|S|$5|N|O|P|C|$Q|T]]|U|$5|N|O|P|C|$Q|V]]]]

<a href="https://stackoverflow.com/users/1180620/mark-adler">Mark Adler could best answer this question.</a>
<blockquote>
The details of how the LZ77 and Huffman work together need some closer examination. Once the raw data has been turned into a string of characters and special length, distance pairs, these elements must be represented with Huffman codes.
Though this is NOT, repeat, NOT standard terminology, call the point where we start reading in bits a &quot;dial tone.&quot; After all, in our analogy, the dial tone is where you can start specifying a series of numbers that will end up mapping to a specific phone. So call the very beginning a &quot;dial tone.&quot; At that dial tone, one of three things could follow: a character, a length-distance pair, or the end of the block. Since we must be able to tell which it is, all the possible characters (&quot;literals&quot;), elements that indicate ranges of possible lengths (&quot;lengths&quot;), and a special end-of-block indicator are all merged into a single alphabet. That alphabet then becomes the basis of a Huffman tree. Distances don't need to be included in this alphabet, since they can only appear directly after lengths. Once the literal has been decoded, or the length-distance pair decoded, we are at another &quot;dial-tone&quot; point and we start reading again. If we got the end-of-block symbol, of course, we're either at the beginning of another block or at the end of the compressed data.
Length codes or distance codes may actually be a code that represents a base value, followed by extra bits that form an integer to be added to the base value.
...
</blockquote>
<a href="http://www.zlib.net/feldspar.html" rel="nofollow noreferrer">Read the whole deal here.</a>
Long story short. LZ77 provides duplicate elimination. Huffman coding provides bit reduction. <a href="https://en.wikipedia.org/wiki/DEFLATE" rel="nofollow noreferrer">It's also on the wiki.</a>

blocks|key|301301|text|LZW试图利用重复的字符串，就像您称之为LZ77的第一个“阶段”。然后，它做了一个糟糕的熵编码的信息。LZW已经被更现代的方法完全取代了。(除了它在GIF格式中的遗留用途。)一旦LZ77生成了一个文字和匹配列表，LZW就没有什么可利用的了，然后它将为该信息制作一个几乎完全无效的熵编码器。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|301302|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

LZW tries to take advantage of repeated strings, just like the first "stage" as you call it of LZ77. It then does a poor job of entropy coding that information. LZW has been completely supplanted by more modern approaches. (Except for its legacy use in the GIF format.) Once LZ77 generates a list of literals and matches, there is nothing left for LZW to take advantage of, and it would then make an almost completely ineffective entropy coder for that information.

Why does LZ77 DEFLATE use Huffman encoding for it's second pass instead of LZW? Is there something about their combination that is optimal? If so, what is the nature of the output of LZ77 that makes it more suitable for Huffman compression than LZW or some other method entirely?

DEFLATE method reasoning

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

为什么LZ77在第二次传递时使用赫夫曼编码，而不是LZW？他们的组合有什么是最优的吗？如果是这样的话，LZ77输出的本质是什么，它比LZW或其他方法更适合于Huffman压缩？

问泄气法推理
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问泄气法推理EN