Zlib 最小放气大小答案

【问题标题】：Zlib minimum deflate sizeZlib 最小放气大小
【发布时间】：2015-09-04 14:01:38
【问题描述】：

我试图弄清楚是否有一种方法可以根据输入缓冲区的大小来计算输出缓冲区所需的最小大小。

这个问题和zlib, deflate: How much memory to allocate?类似，但又不一样。我是在单独询问每个块，而不是整个流。

所以假设我们有两个缓冲区：INPUT 和OUTPUT，我们有一个BUFFER_SIZE，也就是说，4096 字节。（只是一个方便的数字，我选择这个尺寸没有特别的原因。）

如果我使用以下方法放气：

deflate(stream, Z_PARTIAL_FLUSH)

这样每个块都被压缩，并立即刷新到输出缓冲区，有没有办法可以保证输出缓冲区中有足够的存储空间而无需重新分配？

从表面上看，我们假设 DEFLATED 数据将始终大于未压缩的输入数据（假设我们使用大于 0 的压缩级别。）

当然，情况并非总是如此 - 特别是对于较小的值。例如，如果我们对单个字节进行压缩，由于 LZW 流中的标头和字典之类的开销，压缩后的数据显然会比未压缩的数据大。

考虑 LZW 的工作原理，如果我们的输入数据至少为 256 字节（这意味着最坏的情况，每个字节都是不同的，我们无法真正压缩任何东西），我们应该意识到输入大小 LESS超过 256 字节 + zlib 标头可能需要更大的输出缓冲区。

但是，一般来说，现实世界的应用程序不会像那样压缩小尺寸。因此，假设输入/输出缓冲区更像 4K，是否有某种方法可以保证输出压缩数据比输入数据小？

（另外，我知道deflateBound，但由于开销，我宁愿避免它。）

或者，换句话说，是否有一些最小缓冲区大小可以用于输入/输出缓冲区，以保证输出数据（压缩流）小于输入数据？还是总有一些病态的情况会导致输出流大于输入流，而不管大小？

【问题讨论】：

我很困惑。你是压缩还是解压？首先你说deflate()，也就是压缩。然后你说每个块都是“解压缩的”。于是解压。然后你说如果你不使用压缩级别0，放气的数据会更大。所以你的意思是解压缩？然后你说对于小数据大小，deflate 数据会比未压缩的流大，所以压缩。然后你问保证输出小于输入（你不能），所以压缩。
抱歉，我正在压缩。当我说“解压缩”时，这是一个错误（我编辑了帖子以修复。）
那么“表面上，我们假设 DEFLATED 数据将始终大于未压缩的输入数据”是什么意思？

标签： c zlib

【解决方案1】：

信息论表明，必须始终存在“压缩”到更大的病态案例。

This page 从 zlib 的最坏情况编码大小开始 - 看起来最坏情况增长是 6 个字节，加上每个开始的 16KB 块 5 个字节。因此，如果您总是在小于 16KB 之后刷新，那么拥有 11 个字节加上刷新间隔的缓冲区应该是安全的。

除非您严格控制要压缩的数据类型，否则查找病态病例并不难。任何随机数生成器都会很快找到你。

【讨论】：

【解决方案2】：

虽然我不能完全断定你的问题，但我可以单独评论部分问题。

有什么方法可以保证输出的压缩数据是比输入数据小？

绝对不是。压缩输出总是有可能大于某些输入。否则你将无法压缩其他输入。

（另外，我知道 deflateBound，但宁愿避免它，因为开销。）

几乎没有开销。我们所说的比合理大小的输入缓冲区大百分之几。

顺便说一句，deflateBound() 提供了整个输出流大小的界限，作为整个输入流大小的函数。当您处于一堆输入不完整且输出空间不足的 deflate() 调用中时，它无法帮助您。例如，您可能仍有待处理的放气输出，并在下一次deflate() 调用时交付，而根本没有提供任何新输入。那么对于那个孤立的调用，扩展比是无限的。

由于 LZW 中的标题和字典之类的开销流。

deflate 不是 LZW。它使用的方法称为 LZ77。它与现在已经过时的 LZW 非常不同。压缩的放气数据中没有存储“字典”。 “字典”只是当前正在压缩或解压缩的数据之前的未压缩数据。

或者，换句话说，我是否有一些最小缓冲区大小？可用于输入/输出缓冲区...

zlib 接口背后的整个想法是让您不必担心缓冲区中的内容。您只需使用更多输入数据和更多输出空间继续调用deflate() 或inflate()，直到完成，一切都会好起来的。如果您需要进行多次调用来消耗一个输入缓冲区，或者需要多次调用来填充一个输出缓冲区，这并不重要。您只需使用循环来进行更多调用，在需要时提供更多输入，并在需要时处理输出并提供新的输出空间。

【讨论】：