为什么我不能像gzip那样使用zlib解压字符串

发布于 2024-11-05 06:39:35 字数 300 浏览 4 评论 0原文

我知道这里有很多关于使用 python 中的 zlib 或 gzip 模块解压缩数据的问题和答案。但我很好奇 gzip 如何实现它,因为 gzip 是基于 zlib 的。
我阅读了 gzip 的源代码,发现它使用 zlib 逐块解压缩数据,并将 wbits 设置为 -15。
然而,当我直接使用 zlib 和 wbits -15 解压缩时,它告诉我“无效的块类型”,只有 wbits 15+16 才可以工作。

我知道为什么我应该使用 15+16,但是我不知道为什么 gzip 可以使用 -15 但我不能。 谁知道我的模块和 gzip 模块之间的实现差异?

I know here has many questions and answers about decompress data with zlib or gzip module in python. But I'm curious about how gzip implement it since gzip is based on zlib.
I read gzip's source and found it's using zlib to decompress data chunk by chunk with wbits set to -15.
However when I directly use zlib with wbits -15 to decompress, it tells me "invalid block type", only with wbits 15+16 it can works.

I know why I should use 15+16, however I don't know why gzip can use -15 but I can't.
Who knows the differences of implementations between mine and gzip modules?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

小霸王臭丫头 2024-11-12 06:39:35

zlib 模块直接将 wbits 参数传递给实际的 zlib 库。它被称为 windowBits 并记录在 zlib 手册中。让我引用相关部分:

对于原始 deflate,windowBits 也可以是 –8..–15。在这种情况下,-windowBits 确定窗口大小。 deflate() 将生成没有 zlib 标头或尾部的原始 deflate 数据,并且不会计算 adler32 检查值。

由于 gzip 模块自己进行标头解析和生成,因此它需要告诉 zlib 避免它。否则将会有两个 zlib 标头和一个损坏的压缩文件。

The zlib module passes the wbits parameter directly the actual zlib library. There it is called windowBits and is documented in the zlib manual. Let me quote the relevant section:

windowBits can also be –8..–15 for raw deflate. In this case, -windowBits determines the window size. deflate() will then generate raw deflate data with no zlib header or trailer, and will not compute an adler32 check value.

Since the gzip module does the header parsing and generation itself, it needs to tell zlib to avoid it. Otherwise there would be two zlib headers and a broken compressed file.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文