DEFLATE 算法的内存使用情况答案

【问题标题】：Memory usage by DEFLATE algorithmDEFLATE 算法的内存使用情况
【发布时间】：2021-06-19 05:05:01
【问题描述】：

DEFLATE 算法的许多实现都允许基于流的输入。一个例子是 Java 的java.util.zip.ZipOutputStream。据我所知，DEFLATE 在压缩之前构建了一个 Huffman 树，并将该树写入 .zip 文件的开头。

但是，为了构建 Huffman 树，程序需要对最频繁出现的字符进行计数，而这些字符只有在读取文件后才具有。如果流太大以至于无法立即放入内存，那么霍夫曼树是如何构建的？

【问题讨论】：

【解决方案1】：

DEFLATE 以块为单位压缩数据。每个块都包含自己的树/计数，未压缩时通常约为 16KB。

格式在RFC 1951中指定

【讨论】：

谢谢！有没有办法检查这些块的存在/大小？因为当我做unzip -l file.zip 时，我只看到我压缩的一个文件。理论上是否可以独立解码/膨胀这些块？
您在压缩文件上使用的普通工具不会暴露块结构。我添加了一个定义它的 RFC 链接。从理论上讲，如果您可以确定块的开始位置，则可以独立解码块。没有标记可以识别不能出现在块中的块末端，因此识别它们需要一些聪明才智，并且不会 100% 可靠。
非常感谢您提供的信息！还有一个问题：块之间是否允许 LZSS 反向引用？还是他们真的独立？
在一个稍微不相关的说明中，ZIP 格式的文件最多应该是 2^32 字节 ~ 4Gb。但是，java.util.zip.ZipOutputStream 方法可以输出大于 5Gb 的档案（自己检查了一下）。你知道原因吗？
反向引用可以指向前面的块，但最大距离为 32KB。我不知道为什么 .zip 会被限制为 4GB——当然，这可能是由于标题中有 4 个字节的条目——但 deflate 格式本身没有这样的限制。