Deflate 轉 GZIP 轉換器
將原始 DEFLATE 轉換為 GZIP 串流會將壓縮酬載包裝在帶有中繼資料標頭的標準容器內，以便作業系統與網頁工具能夠正確讀取它。
格式比較與技術規格
| 規格 | DEFLATE | GZIP |
|---|---|---|
| MIME 類型 | application/ | application/ |
| 類型 | 原始 DEFLATE 串流 | DEFLATE 串流容器 |
| 壓縮 | LZ77 + 霍夫曼編碼 | 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 容器中可以解決這些相容性問題。開發人員會在網路協定中遇到原始的 DEFLATE 串流，例如 HTTP 壓縮、PNG 圖片區塊與 ZIP 壓縮檔。當這些串流需要儲存為獨立檔案供命令列工具或標準網路下載使用時，工程師會將它們轉換為 GZIP 格式。這能確保解壓縮公用程式快速識別檔案類型並解壓縮內容而不會發生錯誤。
技術規格與編解碼器解析
原始 DEFLATE 是 RFC 1951 位元串流，使用 LZ77 匹配與霍夫曼編碼（Huffman coding），沒有框架標頭或固定簽章。MIME 類型 application/zlib 描述的是根據 RFC 1950 包裝在 zlib 中的 DEFLATE 串流，而非原始 DEFLATE。GZIP (application/gzip) 會將 DEFLATE 酬載包裝在標頭中，標頭以 1F 8B 位元組開頭，並附上包含 CRC32 檢查碼與未壓縮大小（模數 2^32）的尾端。
作業系統與瀏覽器相容性
GZIP 串流在現代作業系統（包含 Linux、macOS 與 Windows）中具有廣泛的相容性。像是 gzip、gunzip 與 7-Zip 的命令列工具可以原生讀取 GZIP 檔案。網頁瀏覽器在接收來自伺服器的 HTTP 回應時會自動處理 GZIP 解壓縮，不過原始的 DEFLATE 通常需要在 JavaScript 環境或 WebAssembly 模組內採用自訂的解析器邏輯。
實用資訊
請務必確認您的解壓縮工具能正確讀取 GZIP 尾端，因為損毀的尾端 CRC32 檢查碼會導致解壓縮工具終止，即使底層的 DEFLATE 酬載是完整的。
常見問題
如何將原始 DEFLATE 轉換為 GZIP 串流且不失真？
這兩種格式都使用基於完全相同 DEFLATE 演算法的無損壓縮。在它們之間進行轉換只是在現有的壓縮位元組周圍加上容器標頭與檢查碼，這代表在包裝過程中不會發生任何資料遺失。
原始 DEFLATE 與 GZIP 串流有什麼差異？
原始 DEFLATE 僅包含壓縮酬載，沒有任何識別標頭或頁尾。GZIP 串流是一個標準化的檔案容器，它在原始 DEFLATE 資料中加入了 10 位元組的標頭與 8 位元組的尾端檢查碼，用於中繼資料追蹤與錯誤偵測。