GZIP转Deflate转换器
将 GZIP 流转换为原始 DEFLATE 会去除外层文件封装和标头元数据，仅留下供专用网络协议和底层归档使用的压缩数据。
格式比较与技术规格
| 规格 | GZIP | DEFLATE |
|---|---|---|
| MIME 类型 | application/ | application/ |
| 类型 | DEFLATE 流容器 | 原始 DEFLATE 流 |
| 压缩 | DEFLATE (RFC 1951) | LZ77 + Huffman 编码 |
| 标准规范 | IETF RFC 1952 | IETF RFC 1950 / RFC 1951 |
| 魔数文件头 (Magic Bytes) | 1F 8B (gzip ID1/ID2) | 78 01 / 78 9C / 78 DA (zlib header bytes) |
格式概述与应用
将 GZIP 流转换为原始 DEFLATE 经常发生在 Web 开发、网络编程和底层数据存储工作流中。当开发人员将单个文件保存到磁盘时，通常会处理 GZIP，因为该格式包含有用的元数据，例如原始文件名和修改时间戳。但是，现代 HTTP 压缩协议和特定的二进制格式仅需要压缩的有效载荷，而不需要任何包装字节。 执行此转换允许工程师将标准压缩数据直接传入网络流或自定义解析器。例如，构建自定义 HTTP 响应处理程序或处理 ZIP 档案通常需要剥离 GZIP 标头和 CRC32 页脚以隔离原始算法输出。在受限编程环境中每个字节都至关重要时，删除这些额外的容器数据可以减少开销。
技术规格与编解码器解析
由 MIME 类型 application/gzip 标识的 GZIP 流使用 RFC 1952 中定义的容器结构。它以两字节的魔数标头（0x1F、0x8B）开头，后跟压缩标志、修改时间、操作系统 ID 和可选文件名。实际压缩数据位于中间，文件以四字节 CRC32 校验和以及四字节未压缩大小指示值结尾。相比之下，原始 DEFLATE 是 RFC 1951 位流，没有固定签名、分帧标头或页脚。MIME 类型 application/zlib 描述的是 DEFLATE 外层的 RFC 1950 zlib 封装，而非原始 DEFLATE 流。将 GZIP 转换为原始 DEFLATE 会移除 GZIP 元数据和校验和，同时保留压缩数据。
操作系统与浏览器兼容性
原始 DEFLATE 流通过 Python、Node.js 和 C++ 等标准编程语言在现代操作系统和 Web 运行时中原生运行。浏览器通过 HTTP 内容编码标头堆栈原生处理 DEFLATE。诸如 Windows、macOS 和 Linux 的操作系统通过系统压缩库（例如 zlib）支持原始流。包括 Android 和 iOS 在内的移动平台为自定义应用存储层提供了对 DEFLATE 例程的直接 API 访问。
实用信息
请务必核实您的目标解析器期望的是纯 RFC 1951 流，而不是 zlib 包装的流，因为 zlib 会添加一个双字节标头，原始 DEFLATE 解析器会拒绝该标头。
常见问题
如何将 GZIP 流转换为原始 DEFLATE 且不丢失质量？
这两种格式使用相同的无损压缩算法。转换它们只需读取 GZIP 容器，剥离十字节的标头和八字节的页脚，并保存内部压缩块。由于底层算法保持不变，因此不会丢失任何数据。
GZIP 流与原始 DEFLATE 有什么区别？
GZIP 是一个完整的文件容器，其中包含魔数标头、原始文件名、修改时间戳和校验和页脚。原始 DEFLATE 仅仅是压缩数据本身，不包含标头、页脚或文件元数据。