GZIP 轉 Deflate 轉換器
將 GZIP 串流轉換為 Raw DEFLATE 會剝除外層檔案包裝與標頭中繼資料，只留下適用於專門網路協定與低階壓縮檔的壓縮酬載。
格式比較與技術規格
| 規格 | GZIP | DEFLATE |
|---|---|---|
| MIME 類型 | application/ | application/ |
| 類型 | DEFLATE 串流容器 | 原始 DEFLATE 串流 |
| 壓縮 | DEFLATE (RFC 1951) | LZ77 + 霍夫曼編碼 |
| 標準規格 | 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 串流轉換為 Raw DEFLATE，在網頁開發、網路程式設計和低階資料儲存工作流程中十分常見。開發人員在將單一檔案儲存到磁碟時經常使用 GZIP，因為該格式包含原始檔名和修改時間戳記等實用的中繼資料。然而，現代 HTTP 壓縮協定和特定的二進位格式只接受沒有包裝資料的壓縮酬載。執行此轉換可讓工程師將標準壓縮資料直接輸入網路串流或自訂解析器。例如，建構自訂 HTTP 回應處理常式或處理 ZIP 壓縮檔時，通常需要移除 GZIP 標頭與 CRC32 頁尾，以分離原始演算法的輸出。當受限的程式設計環境中每個位元組都至關重要時，移除這些額外的容器資料能減少負荷。
技術規格與編解碼器解析
MIME 類型為 application/gzip 的 GZIP 串流使用 RFC 1952 定義的容器結構。它以兩位元組的檔案簽章（magic bytes）（0x1F, 0x8B）開頭，接著是壓縮旗標、修改時間、作業系統 ID 以及選填的檔名。實際的壓縮資料位於中間，檔案結尾則是一個四位元組的 CRC32 檢查碼與一個四位元組的未壓縮大小指示值。相較之下，Raw DEFLATE 是 RFC 1951 位元串流，沒有固定簽章、框架標頭或頁尾。MIME 類型 application/zlib 描述的是包在 DEFLATE 周圍的 RFC 1950 zlib 包裝，而非 Raw DEFLATE 串流。將 GZIP 轉換為 Raw DEFLATE 會移除 GZIP 中繼資料與檢查碼，同時保留壓縮酬載。
作業系統與瀏覽器相容性
Raw DEFLATE 串流透過 Python、Node.js 和 C++ 等標準程式語言，在現代作業系統與網頁執行環境中原生執行。瀏覽器透過 HTTP content-encoding 標頭堆疊原生處理 DEFLATE。Windows、macOS 和 Linux 等作業系統則透過 zlib 等系統壓縮函式庫支援原始串流。包含 Android 和 iOS 在內的行動平台提供對 DEFLATE 常式的直接 API 存取，供自訂應用程式儲存層使用。
實用資訊
請務必確認目標解析器需要的是純 RFC 1951 串流，而不是 zlib 包裝的串流，因為 zlib 會加上兩位元組標頭，而 Raw DEFLATE 解析器會拒絕這種標頭。
常見問題
如何能在不損失品質的情況下將 GZIP 串流轉換為 Raw DEFLATE？
這兩種格式使用相同的無損壓縮演算法。轉換時只需讀取 GZIP 容器、移除十位元組的標頭與八位元組的頁尾，再儲存內部的壓縮區塊。由於底層演算法保持不變，因此不會遺失任何資料。
GZIP 串流與 Raw DEFLATE 有什麼區別？
GZIP 是完整的檔案容器，包含檔案簽章（magic bytes）標頭、原始檔名、修改時間戳記以及檢查碼頁尾。Raw DEFLATE 則只有壓縮資料本身，不包含任何標頭、頁尾或檔案中繼資料。