我正在开发一个文件压缩程序。我们目前正在实现.ZIP archiver standart，这样当生成压缩的.ZIP归档器时，任何其他信誉良好的压缩器（如7zip）都可以完全理解/解压缩它。
我们现在正在开发基于RFC 1951的DEFLATE算法 我们有LZ77的变体和具有固定代码的霍夫曼编码，它与RFC完全兼容，因此可以使用Literal-Length + Distance值。
关于动态霍夫曼编码我目前能够从一些压缩数据中提取霍夫曼树（通过另一个可靠的压缩器压缩），但是当它开始解压缩真实数据时，我得到的值不正确。
可能我正在以错误的方式读树。
我没有具体找到任何人在这里解释这些树的值存储在压缩数据上的方式。
我假设编码数据遵循相同的文字长度值（0~285）+距离（0~30）及其相应的每文字/距离的额外位数，如RFC中所解释的那样，固定霍夫曼编码的方式相同。 / p>
存储在固定霍夫曼编码中的方式是霍夫曼代码与最少上代码的最重要位一起存储内存中的重要位。通过这种方式，您可以逐位向下浏览编码树 霍夫曼代码的额外位以其他方式存储。
动态霍夫曼编码是否以相同的方式存储它们？
我缺少什么或者我应该注意什么？
答案 0 :(得分：8)
首先，你不需要做你正在做的事情，因为它已经在zlib中完成，这是一个允许商业用途的免费压缩库。根据RFC 1951，zlib提供了deflate压缩和膨胀解压缩的实现。此外，您可以使用minizip，它作为zlib源代码包中的第三方贡献，或libzip，使用zlib处理zip文件。< / p>
如果你打算自己动手，那么你可以看看puff.c，也可以在zlib发行版中看到，这是为了补充RFC 1951，目的是通过一个明确的deflate格式定义大量评论工作deflate解码器。
事实上，RFC 1951确实用精确的方式解释了格式。你只需要仔细阅读。 puff.c可能有助于加快学习过程。非固定霍夫曼编码的正确术语是“动态的”。不是“适应性的”。原因是术语“自适应霍夫曼”指的是其他东西 - 一种在deflate格式中不使用的特殊技术 - 当你在数据中移动时，霍夫曼树实际上会变形。动态霍夫曼编码，deflate使用的，而是将数据分成块，并为整个块中的每个块发送完整的霍夫曼代码。
是的，动态霍夫曼码和额外比特以与固定霍夫曼码相同的顺序存储。棘手的部分是了解如何在每个块的deflate流标头中传输霍夫曼码。
答案 1 :(得分：1)
我认为你可能会错误地记录霍夫曼代码的额外位数。 RFC1951说明了额外位的表示：
额外位应解释为首先存储最高有效位的机器整数，例如，位1110代表值14.
额外的位是霍夫曼代码的一部分，因此以相同的顺序读取;除此之外，这意味着将要编码具有连续霍夫曼代码的许多长度和距离值范围（即，如果长度/文字字母的代码269与位串“1010”结束，则长度为19-22）将分别有代码101000,101001,101010和101011。）