你能给我一个短数据字符串的例子，当使用 Zlib 的 DEFLATE 方法解压缩时，它会扩展到更长的东西？
更准确地说：可以为 Zlib 的 DEFLATE 制造的最糟糕的减压炸弹是什么？这里的品质因数是压缩比。如果压缩文件是n字节长，并且在解压缩后会产生m字节长，那么压缩比是m/n。我正在寻找可以最大化压缩比的东西，希望压缩数据非常短。谁能给我一个这样的减压炸弹的例子吗？
相关：这篇文章声称 DEFLATE 可以渐近接近 1032 的压缩比；这是最好的，还是如果我们选择一个精心挑选的压缩字节序列，可以实现更高的压缩率？Libpng通过施加资源限制来防御减压炸弹，但它们没有给出具体减压炸弹的具体示例。另请参阅zip 炸弹，对应的攻击，但针对 ZIP 文件格式。
“1032:1”数字的来源在zlib 站点上给出，它被告知：
限制来自这样一个事实，一个长度/距离对最多可以表示 258 个输出字节。长度至少需要一位，而距离至少需要一位，因此两位输入可以输出 258 个字节，或者八位输入可以输出 1032 个字节。动态块没有长度限制，因此您可以任意接近 1032:1 的限制。
这是 zlib 的两位设计师之一 Mark Adler 的一句话。我自己为 Deflate 实现了一个库，我可以确认，考虑到算法的工作原理，这个渐近限制确实是正确的（你不能超越，但你可以尽可能接近）。Deflate 通过编码“副本”来工作：每个元素要么是一个新字节，要么是过去序列的副本；副本可以重叠（即您可以在距离 4 处复制长度为 30 的序列，产生过去 4 字节序列的 15 倍）；霍夫曼代码应用于元素序列。要获得最小长度的“副本”，您需要它重叠很多，并且每个副本最多值得 258 个字节。所以要压缩的数据必须是一长串相同的字节。
正如@Steffen 所说，使用gzip一长串零进行压缩将产生超过 1000:1 的压缩比。它不必是零；任何重复由相同字节值组成的序列都可以解决问题；但是 Linux 机器有一个/dev/zero，而不是一个/dev/fortytwo.
“压缩炸弹”在很久以前就已经活跃了；早在 1996 年，我就看到它被用来杀死 Netscape（当时，Netscape 处理背景图片，但 Mosaic 没有；一个非常小的 GIF 文件可以编码一个巨大的背景，Netscape 在 X11 服务器中将其分配为单个大像素图）。
gzip 使用 zlib deflate。要从 10M 输入中创建 ab 10k 炸弹，您可以使用
dd if=/dev/zero bs=1024 count=$((10*1024)) | gzip -9 > bomb.gz
而且我认为该帖子声称您的最大比率约为 1000 是正确的。更多信息位于http://www.aerasec.de/security/advisories/decompression-bomb-vulnerability.html（旧）但http： //blog.cyberis.co.uk/2013_08_01_archive.html表明大多数现代浏览器仍然没有针对它的保护。