GZIP 流转原始 DEFLATE 转换器

将 GZIP 流转换为原始 DEFLATE 会剥离外部文件包装器和标头元数据，仅留下用于专用网络协议和底层归档的压缩有效载荷。

格式比较与技术规格

规格	GZIP	DEFLATE
MIME 类型	`application/gzip`	`application/zlib`
类型	DEFLATE stream container	raw DEFLATE stream
压缩	DEFLATE (RFC 1951)	LZ77 + Huffman coding
标准规范	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 校验和以及四字节的未压缩大小指示器结尾。相比之下，由 application/zlib 或原始流标识的原始 DEFLATE 依赖于 RFC 1951。它不包含魔数、标头和页脚。它结合使用 LZ77 算法和霍夫曼编码来直接存储压缩块。由于这两种格式使用完全相同的 DEFLATE 压缩引擎，因此它们之间的转换完全是无损的。转换过程只需展开 GZIP 包装器，丢弃元数据，并提取内部 DEFLATE 字节流。

操作系统与浏览器兼容性

原始 DEFLATE 流通过 Python、Node.js 和 C++ 等标准编程语言在现代操作系统和 Web 运行时中原生运行。浏览器通过 HTTP 内容编码标头堆栈原生处理 DEFLATE。诸如 Windows、macOS 和 Linux 的操作系统通过系统压缩库（例如 zlib）支持原始流。包括 Android 和 iOS 在内的移动平台为自定义应用存储层提供了对 DEFLATE 例程的直接 API 访问。

💡 实用信息

请务必核实您的目标解析器期望的是纯 RFC 1951 流，而不是 zlib 包装的流，因为 zlib 会添加一个双字节标头，原始 DEFLATE 解析器会拒绝该标头。

格式比较与技术规格

压缩为 GZIP 流的 10 MB 文本文件会缩小到大约 2 MB。剥离标头和页脚以创建原始 DEFLATE 文件会产生相同的 2 MB 有效载荷大小。在 500 Mbps 光纤连接上传输此 2 MB 文件大约需要 0.04 秒，在标准的 5G 网络上大约需要 0.4 秒，在拥堵的 4G 蜂窝链路上大约需要 4 秒。

常见问题

如何将 GZIP 流转换为原始 DEFLATE 且不丢失质量？

这两种格式使用相同的无损压缩算法。转换它们只需读取 GZIP 容器，剥离十字节的标头和八字节的页脚，并保存内部压缩块。由于底层算法保持不变，因此不会丢失任何数据。

GZIP 流与原始 DEFLATE 有什么区别？

GZIP 是一个完整的文件容器，其中包含魔数标头、原始文件名、修改时间戳和校验和页脚。原始 DEFLATE 仅仅是压缩数据本身，不包含标头、页脚或文件元数据。