Gzcompress 線上工具對初學者來說,意思是將純 UTF-8 文字在瀏覽器中直接轉成精簡、可貼上的 Base64 包裝 gzip 位元組字串,不需要安裝 PHP、命令列工具或任何桌面軟體。如果你曾經搜尋過 gzcompress——這個 PHP 函式名稱——因為你想壓縮 JSON 酬載、長記錄檔或重複文字區塊,那麼線上 gzip 工具能完成同樣的工作:它會讀取你的文字,透過標準 DEFLATE 演算法執行,然後回傳以 ASCII 安全 Base64 包裝的 gzip 串流,讓你可以貼到設定檔、API 請求本文、資料庫欄位或聊天訊息中。輸出是符合標準的 RFC 1952 gzip 位元組串流,並非專屬格式的資料區塊,因此任何符合規範的解壓縮器——包括 PHP 的 gzdecode、Python 的 gzip 模組,以及 Linux 上的 gunzip 指令——都能將其還原成原始文字。
「gzcompress 線上」真正的含義
你在搜尋欄輸入的 gzcompress 這個詞,幾乎總是借自 PHP。在 PHP 中,gzcompress() 會回傳 zlib 格式的串流,而 gzencode() 會回傳 gzip 格式的串流;初學者經常把兩者搞混。適合初學者的線上 gzip 工具以 gzip 格式為目標——也就是網頁伺服器、.gz 副檔名,以及 Content-Encoding: gzip 標頭所使用的同一種格式——因為這已經是網路上其他所有工具都能理解的格式。當你在這類工具中按下「compress」,你的文字就會變成 gzip 位元組串流,接著以 Base64 編碼,讓二進位位元組能存放在一般文字欄位中,不會發生跳脫或損毀。
如果你明確需要 zlib 輸出(即 gzcompress() 所產生的包裝 DEFLATE 格式),請尋找能提供該容器的工具。本文介紹的工具是以更通用的 RFC 1952 gzip 標準為核心,而不是範圍較窄的 PHP gzcompress 呼叫,因為 gzip 是每個跨系統工作流程都預期的容器。
gzip 文字串流實際如何建構
每個 RFC 1952 gzip 串流都以兩個魔術位元組 1f 8b 開頭,接著是一個值為 8 的壓縮方法位元組 (DEFLATE)。在這三個位元組之後,是一些可選的標頭欄位——旗標、修改時間、額外資料以及可選的檔名——然後是 DEFLATE 壓縮區塊,最後是一個 8 位元組的小端序結尾,儲存原始未壓縮位元組的 CRC32,以及 ISIZE(輸入長度對 2^32 取模)。瀏覽器會在 WHATWG Compression Streams API 內為你完成所有這些工作。
壓縮在瀏覽器中分三個具體步驟進行:
- 你貼上的文字會被轉換成 UTF-8 位元組。非 ASCII 字元會佔用一個以上的位元組,因此對於表情符號、變音符號或 CJK 文字,位元組數可能遠大於可見字元數。
- 這些位元組會流經 CompressionStream("gzip"),產生完整的 RFC 1952 串流,包含魔術數字、標頭、DEFLATE 區塊、CRC32 與 ISIZE。
- 二進位結果會以標準填補式 Base64 包裝——沒有空白、沒有換行、沒有 data URL 前綴、沒有檔名——讓你可以貼到任何文字欄位中。
在反向還原時,規則也以相反順序套用:嚴格的 RFC 4648 Base64 解碼、魔術數字與方法檢查、DecompressionStream,然後對還原的位元組進行嚴格的 UTF-8 解碼。遺漏的填補、空白字元、無效的字母字元,以及非零的填補位元,都會在最開始就被拒絕,瀏覽器會在顯示任何輸出之前先驗證結尾。
逐步壓縮與解壓縮 UTF-8 文字
使用 Gzip Compress & Decompress 頁面,整個來回工作流程只需幾次點擊,而且完全在你的瀏覽器分頁中執行。
- 開啟工具,選擇 UTF-8 text to gzip Base64 模式。
- 貼上或輸入你想要壓縮的文字——從一個句子到數 MB 的 JSON 都沒問題。
- 點擊 Compress,等待編碼後的 Base64 字串出現在輸出框中。
- 點擊 Copy 取得完整的填補式 Base64 結果。不要修剪尾端的 = 填補字元,因為嚴格的 Base64 解碼器需要它。
- 若要反向處理,請切換到 Gzip Base64 to UTF-8 模式。
- 貼上標準 Base64 字串——不要有 data URL 標頭、空白或換行。
- 點擊 Decompress;原始的 UTF-8 文字會出現在下方。
- 以肉眼核對還原後的文字,並確認接收端系統確實預期這種容器(原始 gzip、Base64 gzip、Content-Encoding 標頭,或 .gz 檔案)。
如果還原出的位元組是影像、封存檔、可執行檔或舊式編碼文件而非文字,嚴格的解碼器會告訴你結果不是有效的 UTF-8。遇到這類情況請改用二進位檔案解壓縮器,不要重複使用這個純文字工作流程。
初學者常搞混的容器
「Gzip」是底層的壓縮演算法,但位元組可以透過幾種不同的容器來傳遞。Gzip Compress & Decompress 工具產生的是一種特定形式:以標準填補式 Base64 包裝的 RFC 1952 串流。把這種精確的形式送錯位置,是初學者工作流程失敗最常見的原因。
| 容器 | 外觀 | 典型目的端 |
|---|---|---|
| 原始 gzip 位元組 | 二進位,以 1f 8b 位元組開頭 | 帶有 Content-Encoding: gzip 的 HTTP 主體 |
| 標準 Base64 gzip | ASCII 字串,以 = 填補結尾 | JSON 欄位、設定檔、聊天訊息 |
| URL 安全 Base64 gzip | 使用 - 與 _ 取代 + 與 / | URL 查詢參數、JWT 酬載 |
| .gz 檔案 | 原始 gzip 位元組加上可選的檔名標頭 | 磁碟上的 file.gz、gunzip 指令 |
如果接收端服務要求「gzip Base64」字串,本工具的輸出正是你要的。如果它要求的是 .gz 檔案或 Content-Encoding 主體,那麼你需要的是原始位元組,而不是 Base64。
gzip 位元組串流的結構
了解串流的形狀有助於在出問題時除錯。每個符合標準的 gzip 串流都遵循相同配置,由 RFC 1952 定義,並由瀏覽器強制執行。
| 欄位 | 大小 | 意義 |
|---|---|---|
| Magic | 2 bytes | 固定值 1f 8b |
| CM | 1 byte | 壓縮方法,DEFLATE 必須為 8 |
| FLG | 1 byte | 可選標頭欄位的旗標 |
| MTIME | 4 bytes | 修改時間,小端序,常為零 |
| XFL / OS | 2 bytes | 額外旗標與作業系統標記 |
| Compressed data | n bytes | 一個或多個 DEFLATE 區塊 |
| CRC32 | 4 bytes | 原始未壓縮位元組的 CRC-32 |
| ISIZE | 4 bytes | 原始大小對 2^32 取模,小端序 |
瀏覽器會為你產生這個配置;你不需要手動編寫任何部分。結尾讓嚴格的解碼器能驗證串流確實來自原始輸入,而不是被竄改的副本。
每個初學者都該知道的限制與陷阱
輸入文字與解壓縮後的輸出都被限制在 5,000,000 bytes(約 4.77 MB)。這個保護機制是為了避免不小心貼上過大的內容,以及解壓縮膨脹效應導致瀏覽器分頁凍結。輸出絕不會被默默截斷,所以如果超過限制,你會看到清楚的錯誤訊息,而不是得到半截的字串。介面也會在模式或輸入變更時取消過時的非同步結果,因此較舊的壓縮作業無法覆蓋較新的值。
壓縮不是加密。任何收到 Base64 字串的人都能一鍵將其解壓縮回原始文字。請勿將 gzip 輸出視為密碼、API 金鑰或個人資料的保護機制。CRC32 結尾能偵測意外損毀——例如複製貼上過程中翻轉的位元——但它並非對抗攻擊者的密碼學完整性檢查。
兩個有效的編碼器可能對相同輸入產生不同的 Base64 字串,因為 RFC 1952 允許標頭欄位、DEFLATE 區塊選擇與壓縮等級有所不同,仍然代表相同內容。請勿逐字元比較不同工具的壓縮輸出;請將兩者都解壓縮,然後比較還原後的文字。
常見錯誤的疑難排解
當工具回報錯誤時,原因幾乎都是以下三種之一。
- 無效的 Base64 或填補錯誤。你可能修剪了尾端的 = 符號、加入了空白,或是貼上了像 data:application/octet-stream;base64, 這樣的 data URL 前綴。請只保留字母字元,然後重新貼上完整的填補式字串。
- 不是 gzip 串流或魔術位元組錯誤。位元組不是以 1f 8b 開頭。請確認你拿到的確實是 gzip 容器——而不是 zlib、ZIP、原始 DEFLATE 或 tar 封存檔。
- 結果不是有效的 UTF-8。gzip 串流確實解壓縮了,但還原的位元組不是文字。這通常代表你嘗試解碼的是二進位檔案。請改用二進位檔案 gzip 工具,或參考 Gzcompress 線上工具:在瀏覽器中壓縮與解碼文字 教學,了解同一系列工具在不同情境下的用法。
如果工具回報「expansion limit reached」,代表你的輸入大到解壓縮後的結果會超過 5,000,000 bytes。請將輸入拆成較小的區塊,或改用能從本機檔案讀取的串流工具。
什麼情況下這個工具是正確選擇
只要另一個系統明確預期 gzip 位元組,或你需要將精簡的文字酬載包裝後傳送到 JSON、YAML 或資料庫欄位,就可以使用 Gzip Compress & Decompress 頁面。它也是一個安全的學習沙盒,因為嚴格的解碼器會拒絕格式錯誤的輸入,而不是默默產生垃圾結果。如果你只需要不含 gzip 容器的純 Base64——例如將二進位文字編碼後放進電子郵件本文——那麼較簡單的 Base64 編碼器會更合適。如果你想研究底層位元組如何構成,可以參閱 WHATWG Compression Streams 規格,內容簡短易讀,並詳細說明瀏覽器用來建構與驗證每個串流的精確基本元件。
想進一步了解,請參閱 十六進位轉文字:將十六進位字串讀為 UTF-8 位元組。