Gzip 在线压缩解压

关于 Gzip 在线压缩解压

Gzip 压缩与解压工具把文本或文件压成 gzip 流，也能把 gzip 数据还原成文本或字节，并可以选择把压缩结果表示为 Base64，好让它穿过只接受文本的字段。结果面板始终提供下载，这也是把真正的二进制结果完整带出浏览器的唯一方式。

gzip 是套在 DEFLATE 流外面的一层容器：10 字节头部（以魔数 1F 8B 08 开始）、压缩数据，然后是 CRC-32 和原始长度。正是这层封装，让 gzip、zlib 和裸 DEFLATE 明明装着同样的压缩载荷却互不通用，也解释了为什么一段数据在这个库里能解、换个库就报错。另外，小数据压缩并不划算：几百字节以下时，头尾开销比压缩省下的还多。

如何使用这个开发者工具

先选择「压缩」或「解压」，这个模式决定了输入面板如何被解释。
压缩时可以直接输入文本或选择文件；解压时请粘贴 Base64 形式的 gzip 数据，或选择 .gz 文件。
需要可复制的字符串时保持勾选「Base64 输出」；只打算下载字节时可以取消勾选。
执行操作后阅读结果面板：文本结果直接显示，二进制结果只会报出体积，因为它无法以文本呈现。
复制 Base64 字符串，或下载文件：压缩结果为 output.gz，解压出的二进制为 output.bin。

实例：一段日志到底能压到多小

四行结构化日志，连同结尾换行共 364 字节。重复的键名正是 DEFLATE 最擅长的东西。

输入文本

{"ts":"2026-02-02T02:40:00Z","level":"info","path":"/api/v1/orders","status":200,"ms":37}
{"ts":"2026-02-02T02:40:01Z","level":"info","path":"/api/v1/orders","status":200,"ms":41}
{"ts":"2026-02-02T02:40:02Z","level":"warn","path":"/api/v1/orders/9f2","status":404,"ms":12}
{"ts":"2026-02-02T02:40:03Z","level":"info","path":"/api/v1/orders","status":201,"ms":88}

Base64 gzip 输出

H4sIAAAAAAAAA6XOsQ6CMBAG4J3H+OeSXo9G8Z7Dya2JJZIgkF7BgfDuDiwsMOgLfPkWZIWAiS8lcUl8JxZPQvSAQRfn2EHQ9s0AgzHkFwQ2jK2dnR3SMyaFgeaQJ4UwkcFbIdV1LZYj2f0je3ci817+hNQfyfbW8E735Dfd8Yle/fR2m1zXa/EFnwXx42wBAAA=

gzip 流是 146 字节，为输入的 40%。而 Base64 形式有 196 个字符，也就是说能粘进 JSON 字段的那个版本，仍占原文本的 54%。载荷按字节传输时引用 146 这个数，按文本粘贴时就要引用 196。

常见压缩格式与它们的头部

开头几个字节就能确定格式。想解释「为什么这边生成的数据那边读不了」，这是最快的路径。

格式	起始字节	封装	本工具是否接受
gzip	1F 8B 08	10 字节头部，CRC-32 与长度尾部	接受，这是默认格式
zlib	78 01 / 78 9C / 78 DA	2 字节头部，Adler-32 尾部	接受，解压时会自动识别
裸 DEFLATE	无头部	只有压缩数据	不接受，会报 incorrect header check
ZIP 压缩包	50 4B 03 04	逐条目头部加中央目录	不接受，它是多文件容器
Brotli	无固定魔数	用于 Content-Encoding: br	不接受
Zstandard	28 B5 2F FD	帧头	不接受
xz	FD 37 7A 58 5A	LZMA2 之上的容器	不接受

常见问题排查

gunzip 能打开的 .gz 文件，在这里被拒绝。

成因解压模式下文本面板期待的是 Base64。而且把原始二进制粘进文本框本身就会破坏数据，非法 UTF-8 字节在工具看到之前就已被替换掉了。

解决办法 真正的 .gz 文件请走文件选择器。文本面板只用于本来就是 Base64 的数据——gzip 藏在 JSON 或 URL 参数里时通常就是这个形态。

压缩一小段字符串，结果比原文还大。

成因还没装数据，gzip 的头尾就要花掉 18 字节，Base64 再加三分之一。5 字节文本会变成 25 字节的流、36 个字符的 Base64 串。

解决办法 压聚合而不是压单条：一批记录用一个 gzip 流，而不是每条一个。经验值是 200 字节以下不值得为封装买单。

解压报 buffer error。

成因数据流被截断了。从日志查看器复制、存进有长度上限的数据库列，或者只下载了一半的文件，都会在 CRC-32 和长度尾部之前结束。

解决办法 回到源头重新取一次载荷。长度尾部存在时 gzip 能证明结果完整；而被截断的流，截断点之后的数据永远找不回来。

数据明明以 1F 8B 开头，却报 incorrect header check。

成因流结束之后还有多余数据。解压器会把尾随字节当成下一个 gzip 成员的开头，于是多出来的日志行、换行拼接或字段填充就会在那个位置报错。

解决办法 把流结束之后的内容全部截掉。真正拼接的多个 gzip 成员是被支持的，会解压成一个整体结果，这也正是多余字节被如此解读的原因。

结果面板只给出体积，不显示文本。

成因解压出的字节不是合法 UTF-8，这对 tar 包、图片或 protobuf 消息来说很正常。工具选择拒绝渲染，而不是给你一屏替换字符。

解决办法 下载 output.bin，用对应的工具打开。如果原文件是 .tar.gz，这一步拿到的是 .tar，还需要再解包一次。

适合用这个工具的场景

在争论之前，先量一量有代表性的载荷或日志样本到底能压缩多少。
解开藏在 JSON 字段、链路追踪头或 URL 状态参数里的 Base64 gzip 数据。
为读取压缩输入的测试造一个小巧的 .gz 夹具。
通过看开头几个字节，确认别人口中的「gzip 数据」是不是真的 gzip。

应该换用别的工具的场景

把多个文件打到一起。gzip 只压单个流，请用 tar 加 gzip，或直接用 ZIP。
保护数据。压缩不是加密，载荷可以被轻易还原。
预测 CDN 实际下发的体积。服务端会自选压缩级别，而且很多已改用 Brotli，实测值会和这里不同。

隐私与数据处理

压缩与解压完全在当前标签页内、由一份 JavaScript 版 zlib 实现完成，字节不出浏览器，标签页关闭后不留痕迹。真正的限制是内存而非策略：输入和输出会同时驻留，文件选择器拒绝 64 MB 以上的文件。日志片段里常常夹着用户标识，粘贴前请先精简样本。

常见问题

gzip 和 ZIP 是一回事吗？

不是。gzip 压缩单个流、几乎不带元数据；ZIP 是带条目目录的归档格式，每个条目单独压缩。两者常被混淆，是因为它们内部通常都用 DEFLATE。

为什么要把压缩结果再转成 Base64？

因为压缩后的字节无法安全地待在 JSON 字符串、HTTP 头或 URL 参数里。Base64 让它们可传输，代价是吃掉三分之一的压缩收益，但整体上仍然划算。

输出会和命令行 gzip 逐字节一致吗？

通常不会。本工具使用默认压缩级别，且不写入修改时间和原始文件名，而命令行 gzip 两者都会记录。任何 gzip 解压器都能读这两种形态，内容完全一致。

能打开 .tar.gz 吗？

解压后得到的是 tar 流，它本身是多文件容器。本工具不做解包，请下载结果再用 tar 展开。

压两次会更小吗？

不会。压缩后的数据几乎不剩冗余，再压一遍通常只会多出 18 字节的封装开销。

最大能处理多大的文件？

选择器上限是 64 MB，实际瓶颈则取决于标签页的内存，因为输入和输出都要完整驻留。更大的文件请用命令行 gzip，它是流式处理的。

Gzip

文本输入

结果