Gzip 压缩与解压
编码所有处理都在浏览器本地完成,数据不上传服务器
把文本压成 gzip,或把 gzip 解回文本。⚠️ 先说清楚一件事:gzip 不是加密。它没有密钥,任何人都能解开,压缩后的数据只是变得不直接可读而已 —— 不少工具站把它归进「加密解密」,那是个历史误称。它真正的用途是让数据变小:一段 JSON 压完通常只剩三成,日志、接口响应、备份文件都靠它。这里走的是浏览器原生的压缩实现,因此结果与 `gzip` 命令、与 zlib、与各语言的标准库逐字节一致,可以直接互换。输出的行列出了原始大小、压缩后大小与体积比 —— 顺带一提,如果压完反而变大了,那是正常的(短文本加上一整套 gzip 头就会这样),页面会明确告诉你。
功能
- 双向:文本 ⇄ gzip
- 输出 Base64 或十六进制,输入时两种都认(十六进制容忍空格、冒号与换行)
- 结果与 gzip 命令、zlib、各语言标准库逐字节一致,可以直接互换
- 同时给出原始大小、压缩后大小与体积比
- 压完反而变大时明确说明原因,不会让人以为工具坏了
- 数据不是有效 gzip 时,指出可能是截断、换行或格式其实是 zlib / deflate
使用方法
- 选择方向:压缩或解压
- 选择数据写法:Base64 或十六进制
- 粘贴内容,按 Ctrl/⌘ + Enter 或点「运行」
- 复制结果 —— 每一行都有单独的复制按钮
常见问题
- gzip 能用来加密吗?
- 不能。gzip 是压缩,不是加密:没有密钥,任何人都能解开,只是数据变得不直接可读。把敏感内容压一遍再发出去,和直接发出去没有区别 —— 压缩后的字节流里仍然带着全部信息。需要保密请用 AES,或者任何真正的加密算法。
- 为什么压完反而变大了?
- 因为 gzip 有固定的头部与尾部开销(约 18 字节),而且当内容本来就短、或者已经经过压缩时(zip、图片、视频、PDF 里的流),DEFLATE 找不到可压缩的重复模式,反而要额外记录「这里没压」的信息。这是所有压缩算法的常态,不是工具的问题。判断标准很简单:压缩只对「有冗余的、还没压过的」数据有效。
- 我的数据解不开,提示不是有效的 gzip?
- 先看是不是复制时被截断了 —— 压缩产物里有二进制字节,粘进聊天窗口或表单时常被截断或插入换行。其次确认格式:`zlib`(带 0x78 开头)、`raw deflate`(无头无尾)和 `gzip`(0x1f 0x8b 开头)是三种互不兼容的格式,经常被统称为「压缩」,但拿 gzip 去解 zlib 的数据必然失败。本工具只处理 gzip。
- 结果的格式与 gzip 命令一样吗?
- 完全一样。同一条数据用 `echo -n "内容" | gzip -c | base64` 得到的结果,与本工具的 Base64 输出逐字节相同 —— 因为两边用的都是标准的 DEFLATE 与 gzip 封装,而且 gzip 头里的时间戳字段都写 0(所以同样的输入必然得到同样的输出,可以放心对比与缓存)。
相关工具
AES / DES 加解密
编码用 AES、DES 或 3DES 加解密文本,支持 CBC、GCM、CTR、ECB 四种模式,密钥可写文本、十六进制或 Base64,全部在本地完成。
Base64 编解码
编码把文本转成 Base64,或把 Base64 还原成文本,中文与 emoji 都按 UTF-8 正确处理。全部在浏览器本地完成,内容不上传。
哈希计算
编码算出文本的 MD5、SHA-1、SHA-256 或 SHA-512 摘要,也可算老系统用的 MD4 与 MD2,中文按 UTF-8 字节计算。全部在本地完成。
URL 编解码
编码把中文、空格与符号转义成 %XX,或把 %XX 还原成文本;整条 URL 与单独的参数值要选对方式,选错不会报错,但链接会打不开。全部在浏览器本地完成。
HTML 实体编解码
编码把 < > & 与引号转成 HTML 实体,也能把实体还原成字符,而且只解一遍:&lt; 得到的是 < 而不是尖括号。全部在浏览器本地完成。
JWT 解析与验签
编码把 JWT 拆成 header、payload、signature,支持用密钥验证 HS256/384/512 签名,并把 exp、nbf 换算成可读时间。全部在浏览器本地完成。