原始 DEFLATE 转 GZIP 流转换器
将原始 DEFLATE 转换为 GZIP 流，将压缩负载包装在带有元数据标头的标准容器中，以便操作系统和网络工具能够正确读取它。
格式比较与技术规格
| 规格 | DEFLATE | GZIP |
|---|---|---|
| MIME 类型 | application/zlib | application/gzip |
| 类型 | raw DEFLATE stream | DEFLATE stream container |
| 压缩 | LZ77 + Huffman coding | DEFLATE (RFC 1951) |
| 标准规范 | IETF RFC 1950 / RFC 1951 | IETF RFC 1952 |
| 魔数文件头 (Magic Bytes) | 78 01 / 78 9C / 78 DA (zlib header bytes) | 1F 8B (gzip ID1/ID2) |
格式概述与应用
原始 DEFLATE 数据流包含没有文件标头或尾随校验和的压缩字节。网页浏览器和网络工具经常难以处理这些裸流，因为它们缺少诸如原始文件名、修改时间戳或操作系统标识符之类的元数据。将这些原始数据包装到 GZIP 容器中可以解决这些兼容性问题。 开发人员在 HTTP 压缩、PNG 图像块和 ZIP 档案等网络协议中遇到原始 DEFLATE 流。当这些流需要保存为用于命令行工具或标准网页下载的独立文件时，工程师会将其转换为 GZIP 格式。这确保了解压缩实用程序可以立即识别文件类型并提取内容而不会抛出错误。
技术规格与编解码器解析
原始 DEFLATE（application/zlib 或原始流）使用 LZ77 滑动字典匹配和哈夫曼编码的组合来压缩字节序列，而没有任何成帧头。GZIP 容器（application/gzip）采用此确切的 DEFLATE 负载，并将其包装在一个严格的 10 字节头中，该头包含两字节魔数签名（0x1F, 0x8B）、压缩方法标志、修改时间和操作系统 ID。GZIP 结构还附加了一个 8 字节的尾部，其中包含用于数据完整性验证的 CRC32 校验和以及对 32 次方取模的未压缩文件大小。
操作系统与浏览器兼容性
GZIP 流在现代操作系统（包括 Linux、macOS 和 Windows）中拥有普遍的兼容性。诸如 gzip、gunzip 和 7-Zip 之类的命令行工具原生读取 GZIP 文件。网页浏览器在从服务器接收 HTTP 响应时会自动处理 GZIP 解压缩，尽管原始 DEFLATE 通常需要在 JavaScript 环境或 WebAssembly 模块内使用自定义解析器逻辑。
💡 实用信息
始终验证您的解压工具是否正确读取了 GZIP 尾部，因为损坏的尾部 CRC32 校验和将导致提取工具中止，即使底层 DEFLATE 有效负载完好无损。
格式比较与技术规格
转换为 GZIP 文件的 10 MB 原始 DEFLATE 流为标头和尾部增加了微小的 18 字节开销。在 5G 连接上传输此文件大约需要 0.04 秒，在标准 4G 网络上大约需要 0.2 秒，在千兆光纤连接上则不到 0.01 秒。
常见问题
如何将原始 DEFLATE 转换为 GZIP 流而不损失质量？
这两种格式都使用基于完全相同的 DEFLATE 算法的无损压缩。在它们之间进行转换只需在现有的压缩字节周围添加容器标头和校验和，这意味着在包装过程中不会发生数据丢失。
原始 DEFLATE 和 GZIP 流有什么区别？
原始 DEFLATE 仅包含压缩负载，没有任何识别标头或页脚。GZIP 流是一个标准化的文件容器，它向原始 DEFLATE 数据添加了 10 字节的标头和 8 字节的尾随校验和，用于元数据跟踪和错误检测。