取代伺服器端 gzcompress API 呼叫的最快方法,就是在瀏覽器中直接執行 RFC 1952 gzip 壓縮,使用 WHATWG Compression Streams API,然後將二進位輸出包裝成標準 Base64,這樣就能貼到文字欄位、JSON 酬載,或 HTTP 請求主體中。Gzip Compress & Decompress 工具正是這樣做的:它接收 UTF-8 文字,產生符合標準的 gzip 位元組(以魔術數字組 1F 8B 與方法位元組 8 開頭),驗證 CRC32 與 ISIZE 結尾,然後輸出一段已加填充的 Base64 字串,隨時可以複製。不需要網路往返、沒有速率限制、不需要 API 金鑰,也不會有伺服器記錄你酬載的疑慮。由於整個流程都在你的分頁中本機執行,因此反向操作時也保有同樣的隱私特性:你貼上 Base64 包裝的 gzip 串流,工具會嚴格解碼、拒絕錯誤的框架,並將其解壓回有效的 UTF-8 文字,或在出錯時回報錯誤。這種「瀏覽器端壓縮、Base64 傳輸、無伺服器」的模式,對於任何在尋找 gzcompress 線上 API 替代方案的人來說,是最乾淨的解答。
本機壓縮 vs. 伺服器端點
伺服器端 gzip 端點確實解決了實際問題,但會引入四項本機流程得以避免的成本。第一,每次 API 呼叫都會把明文酬載上傳給第三方,這對於日誌、使用者資料或機密內容來說幾乎難以接受。第二,免費端點可能會限流、棄用或無預警消失,在正式流量上依賴這類服務相當脆弱。第三,要除錯遠端編碼器時,當輸出看起來有誤,你無法檢查框架位元組,只能看到表面的結果。第四,外部服務通常回傳原始 gzip 位元組或十六進位字串,而不是能乾淨放入 JSON 欄位、環境變數或設定檔的 Base64 包裝文字。
本機瀏覽器工具則反轉了上述每一點。WHATWG Compression Streams 規範定義了一套內建的 gzip 編解碼器,所有現代瀏覽器都內建支援,因此不需要 polyfill 或額外相依套件。工具會將你的 UTF-8 字串轉成位元組,透過 CompressionStream('gzip') 傳送,再將二進位串流編碼為已加填充的標準 Base64,不含空白、不含 data URL 前綴,也不含檔名。在反向操作時,它嚴格套用 RFC 4648 Base64 解碼、在將位元組交給 DecompressionStream 之前檢查最低 gzip 框架,並將結果以 UTF-8 強制解碼,如此一來,非文字酬載便無法以替換字元的形式悄悄通過。
同樣的概念也可推廣到其他文字編解碼器,這也是為什麼像 無需 API 金鑰的 Base64 解碼 這類情境,也能採用相同的平行模式:把位元組留在你的分頁中、以文字形式傳輸,並且只有在往返乾淨無誤後才交給目的系統。
RFC 1952 Gzip 包裝究竟包含什麼
Gzip 是由 RFC 1952 定義的無損容器。它和 PHP 的 gzcompress() 函式所使用的較舊 zlib 容器並不相同,zlib 由 RFC 1950 定義,以位元組 78 01 開頭(或依壓縮等級而為 78 9C / 78 DA)。如果你的下游系統呼叫 gzcompress() 並預期使用該 zlib 框架,那這個瀏覽器工具就不是合適的選擇;如果它呼叫的是 gzencode()、接受 HTTP Content-Encoding: gzip 標頭,或讀取 .gz 檔案,那就相符。
該容器分為三個部分。固定標頭以魔術位元組 1F 8B 開頭,接著是值為 8 的壓縮方法位元組(代表 DEFLATE)、可選的旗標欄位、四位元組的修改時間、一個額外旗標位元組、一個作業系統位元組,以及任何可選的標頭欄位(例如原始檔名)。主體包含一個或多個 DEFLATE 壓縮區塊。串流以八位元組的小端序結尾收尾,內容為未壓縮位元組的 CRC32,後接 ISIZE(即輸入大小對 232 取模)。
| 容器 | 規範 | 起始位元組 | 結尾 | 常見用途 |
|---|---|---|---|---|
| zlib | RFC 1950 | 78 01 / 78 9C / 78 DA | Adler-32 (4 位元組) | 記憶體內框架,PHP gzcompress() |
| gzip | RFC 1952 | 1F 8B ... method 08 | CRC32 + ISIZE (8 位元組) | .gz 檔案,HTTP Content-Encoding,PHP gzencode() |
| raw DEFLATE | RFC 1951 | 無 | 無 | 部分較舊的協定與內部傳輸 |
瀏覽器的 CompressionStream 與 DecompressionStream 實作會為你處理所有這些框架。工具只在讓瀏覽器執行解壓縮之前檢查魔術數字與方法,並直接信任瀏覽器本身的 CRC32 與 ISIZE 驗證,而不會自行重算。這已足以在不依賴伺服器的情況下,捕捉意外的損壞與不完整的貼上內容。
將 UTF-8 文字壓縮為 Base64 Gzip 酬載
- 開啟 Gzip Compress & Decompress 頁面,確認模式選擇器設定為 UTF-8 text to gzip Base64。
- 輸入或貼上你要壓縮的 UTF-8 文字。含腔調字元、emoji 與 CJK 字碼點皆可;它們會先被轉成 UTF-8 位元組,工具會透明地接受所產生的多位元組序列。非 ASCII 字元每個可能佔用好幾個位元組,因此輸入的位元組數並不等於可見字元數。
- 觸發壓縮動作。瀏覽器會將字串編碼為 UTF-8,把這些位元組推送通過 CompressionStream('gzip'),再將產生的串流以標準 Base64 編碼,具備正確填充、不含空白、不含 data URL 前綴,也不含檔名。
- 複製完整的 Base64 字串。不要修剪尾端的 = 符號;下游的 Base64 解碼器通常要求正確的填充,並會把未填充的字串視為格式錯誤而拒絕。
- 把 Base64 貼到它該出現的地方——例如 JSON 主體、環境變數、curl 請求、測試 fixture——並確認目的端實際上預期的是 Base64 包裝的 gzip,而不是原始 zlib、原始 DEFLATE,或 .gz 檔案上傳。即使底層使用的壓縮演算法相同,這些仍屬於不同的容器。
將 Base64 Gzip 串流解壓回 UTF-8 文字
- 將模式選擇器切換為 Gzip Base64 to UTF-8。
- 貼上一段具正確填充的標準 Base64 字串,其解碼結果為 RFC 1952 gzip 串流。缺少填充、夾帶空白、或含有 Base64 字元集以外字元的字串,會在解壓縮之前就被拒絕,因此你可以快速反覆嘗試,而不會產生半解碼的結果。
- 執行解壓縮動作。工具會解碼 Base64、驗證最低 gzip 框架(魔術數字 1F 8B 與方法 08),然後讓 DecompressionStream 展開位元組。瀏覽器會自行驗證結尾,並在輸入不完整或損壞時回報明確錯誤。
- 閱讀還原後的 UTF-8 文字,確認無誤後再行複製。解碼後的位元組會以 UTF-8 強制驗證;若 gzip 串流展開後是影像、封存檔、可執行檔,或舊式非 UTF-8 文件,則會被回報為 UTF-8 錯誤,而不是悄悄被轉成替換字元。
- 在擁有該資料的應用程式中對還原後的內容進行健全性檢查。如果目的端預期的是 PHP gzcompress() 所產生的較舊 zlib 容器,請改用支援 zlib 的工具來解碼,而不是再透過本頁貼回去處理。
何時二進位檔案工具才是更好的選擇
這個工具刻意定位為文字工作流程。Gzip 本身可以包裝任何位元組串流——JPEG、ZIP、PDF、二進位協定緩衝區——但本頁會將解壓縮後的位元組強制以 UTF-8 解碼,因此非文字酬載將會以明確錯誤失敗,而不是假冒成文字。面對這類酬載時,請改用具備檔案處理能力的 gzip 解壓縮器,將位元組寫入磁碟,而不是將其當成字串解碼。壓縮端也適用相同的界線:當輸入已經是二進位資料,並且你希望將其包裝成 .gz 附件,而不是以 Base64 一行輸出到 JSON 酬載時,檔案工具才是正解。嘗試將二進位檔案透過這個純文字頁面往返處理時,會刻意產生令人困惑的錯誤;這種失敗是保護機制,而不是 bug。
限制、結尾檢查,以及為何輸出會有所不同
有兩項硬性限制保護瀏覽器分頁。UTF-8 輸入與解壓縮後的 UTF-8 輸出皆上限為 5,000,000 位元組;超出大小的貼上內容會回傳錯誤,而不是悄悄截斷,這點很重要,因為即便是小型輸入,經 DEFLATE 展開後仍可能產生遠大許多的輸出,而失控的解壓縮酬載可能會讓分頁凍結。介面也會在模式或輸入變更時取消過時的非同步結果,因此舊的壓縮作業無法在使用者中途編輯時覆蓋較新的結果。
完整性由瀏覽器本身的 gzip 實作透過 CRC32 與 ISIZE 結尾值進行檢查。內部共有八組 fixture 涵蓋空字串、短字串、常見 CRC 套件、123456789 參考輸入,以及 quick-brown-fox 句子;每組 fixture 都會驗證魔術數字、方法位元組、往返行為與結尾一致性,而非驗證單一精確的 Base64 拼法。最後一點很重要:兩套 gzip 工具並不需要產生完全相同的壓縮位元組,因為修改時間、作業系統位元組,以及 DEFLATE 區塊選擇等標頭欄位都可能不同,卻仍展開成相同內容。在驗證整合時,請比較解壓縮後的文字與框架不變性,而不是字面上的 Base64 字串。
還有一點值得再次強調:壓縮並非加密。輸出可能不易快速瀏覽,但任何收到 Base64 的人都能將其解壓。Gzip CRC32 用於偵測意外損壞,並非抵禦攻擊者的密碼學完整性保證。請把 gzip 視為傳輸最佳化,以及把酬載放進文字友善容器的手段,而不是保護憑證、權杖或個人資料的工具。