線上批次 gzcompress 的意思是對多個 UTF-8 文字項目執行相同的 gzip 壓縮,並將每個結果收集成可複製貼上的 Base64 字串,而 Gzip Compress & Decompress 工具正好在瀏覽器中做到這件事:它將每一行透過原生的 Compression Streams API 進行處理,並將輸出包裝成標準的含填補 Base64,且不附加資料 URL 前綴、檔名或換行。壓縮器接收 UTF-8 字元,將其編碼為位元組序列,再把這些位元組交給 CompressionStream('gzip'),然後將產生的二進位串流編碼為 RFC 4648 Base64,讓這些位元組能夠存在於 JSON、記錄檔行、資料庫欄位或表單欄位中。由於頁面一次只處理一個載荷,所謂的「批次」工作流程其實是一種重複動作:貼上第一個字串、複製其 Base64 結果、貼上下一個字串,依此類推。在瀏覽器中執行這項操作可讓原始文字與壓縮輸出保持在同一台機器上,當字串包含憑證、設定或其他私密資料時,這一點很重要。
「線上批次 Gzcompress」真正的含義
當開發人員想要在不出瀏覽器的情況下壓縮多個短字串(例如記錄項目、JSON 載荷、標頭、識別項、查詢字串)時,搜尋引擎就會顯示「gzcompress online bulk」這個片語。PHP 函式 gzcompress() 已成為「從字串產生 gzip 相容位元組」的代名詞,而無法在本機安裝 PHP 的人仍想要相同的輸出。此處的「批次」並非指平行的批次處理器;它指的是一種快速重複相同單項轉換的方式,具有一致的框架與統一的文字輸出編碼。
Gzip Compress & Decompress 頁面符合該工作流程,因為它始終產生相同類型的結果:包裹著符合標準的 RFC 1952 gzip 串流的標準含填補 Base64 字串。當你需要將輸出貼到聊天訊息、Jira 票證或 JSON 屬性中(這些地方原始的二進位位元組並不安全)時,這種包裝方式就很重要。你可以對每個項目執行一次頁面,卻仍然將結果稱為「批次」,因為每次執行都遵循相同的規則,並產生可直接串接成單一文件而無需進一步轉換的文字。
分批壓縮多個 UTF-8 字串
- 選擇模式「UTF-8 text to gzip Base64」,讓頁面將你的輸入讀取為字元,並在壓縮前透過 UTF-8 編碼器進行轉換。
- 將第一個字串貼上或輸入到輸入框中;瀏覽器會將字元轉換為位元組序列,其中非 ASCII 字元可使用多個位元組。
- 點擊壓縮動作;頁面會將位元組透過 CompressionStream('gzip') 串流處理,驗證框架,並將結果呈現為不含空格或換行的標準含填補 Base64。
- 使用頁面上的複製按鈕複製 Base64 結果,並貼到你的累積器中——可以是試算表、文字檔、腳本或資料庫欄位。
- 清除輸入,貼上下一個字串,然後從步驟 3 開始重複。當模式或輸入變更時,介面會取消過時的非同步任務,因此較舊的執行絕不會覆寫較新的值。
- 完成清單後,透過將兩三個項目以同樣方式回傳到同一頁面進行抽查解壓縮,並將還原後的文字與來源進行比對,以驗證累積器。
如果你的項目具有共同的格式(例如 JSON 行或記錄檔行),請逐筆貼上而非串接在一起;gzip 可能會更積極地壓縮串接後的內容,這會產生一個與下游各筆參考值不再相符的結果。
批次輸出的 Gzip 框架與 Base64 包裝
此工具的每個結果都是真正的 gzip 串流,而非原始的 DEFLATE 位元組區塊。根據 RFC 1952,該串流以魔術位元組 1f 8b 開頭,接著是 DEFLATE 的壓縮方法位元組 8,然後帶有標頭欄位、壓縮區塊,以及一個八位元組的小端序尾部,其中包含未壓縮位元組的 CRC32 與 ISIZE(輸入大小對 2^32 取模)。瀏覽器會自動建立並驗證此框架,而此工具的測試會獨立斷言這些不變式,而不僅僅檢查來回轉換的行為。在其上加上一層 Base64,讓位元組可以安全地貼入文字欄位中;採用的是標準的 RFC 4648 編碼,這代表輸出含有填補、使用標準字母表,且不附加資料 URL 前綴。
由於 gzip 輸出在位元組層級並非確定性的,兩個不同的編碼器(包括同一工具的兩次執行)可能會產生不同的 Base64 字串,卻能解壓縮為相同的文字。標頭欄位、DEFLATE 選擇與壓縮等級都可能有所不同,即使它們代表相同的內容。對於批次工作而言,這通常不是問題:大多數消費者只會驗證魔術位元組與尾部,或者直接進行解壓縮並比較內容。如果你需要位元組穩定的輸出作為測試固定資料,請固定編碼器版本與壓縮等級,並將產生的 Base64 視為快照,而非保證。
| 批次輸出特性 | 此工具中的行為 |
|---|---|
| 格式 | 包裹著 RFC 1952 gzip 串流的標準含填補 RFC 4648 Base64 |
| 前綴 | 無——無資料 URI、無檔名、無 MIME 標記 |
| 換行 | 無——單一連續字串,可立即貼到任何位置 |
| 標頭欄位 | 由瀏覽器依 Compression Streams 規範建構的標準 gzip 標頭;不可編輯 |
| 尾部 | 自動附加 CRC32 與 ISIZE(輸入大小對 2^32 取模) |
| 確定性 | 不保證跨編碼器的位元組完全一致;內容與框架是穩定的 |
反轉批次輸出:將 Gzip Base64 貼回 UTF-8
解壓縮遵循同樣的逐一節奏。將頁面切換到「Gzip Base64 to UTF-8」模式,貼上包裹著 RFC 1952 gzip 串流的標準 Base64 字串,然後執行解壓縮動作。頁面首先套用嚴格的 RFC 4648 Base64 解碼:缺少的填補、空白字元、無效的字母字元以及非零的填補位元會導致立即拒絕,而不是產生部分結果。接著解碼器會在將資料傳遞給 DecompressionStream 之前檢查最低 gzip 框架與魔術位元組,然後瀏覽器會驗證壓縮串流與尾部。損壞或不完整的輸入會產生錯誤,絕不會產生部分文字。
解壓縮之後,頁面會將產生的位元組以嚴格模式解碼為 UTF-8。如果 gzip 串流包含影像、封存檔、可執行檔或舊式編碼的文件,嚴格的解碼器會回報這些位元組不是 UTF-8,而不是替換字元或損壞輸出。對於非文字類型的載荷,請切換到二進位檔案 gzip 工具——此頁面刻意保持為文字工作流程,以避免批次使用者在本應是影像的位置出現損壞的字串。
批次限制、錯誤與後續處理
單次執行的壓縮輸入與解壓縮輸出上限皆為 5,000,000 位元組。設定此上限是為了防止誤貼內容意外落到頁面上時瀏覽器分頁失去回應;一段意外過大的 Base64 字串解壓縮後可能會膨脹為其長度的許多倍,進而凍結介面。頁面絕不會悄悄截斷輸出:如果 gzip 串流解壓縮後將超出上限,該次執行會回傳錯誤。對於真正的批次管線,請將輸入切割成多個區塊,確保每個區塊遠低於五百萬位元組,然後對每個區塊分別執行頁面一次。
有幾條實用的規則可讓批次工作保持乾淨。首先,請將 gzip 視為容器而非加密——任何持有該 Base64 字串的人都可以對其進行解壓縮,因此請勿使用此輸出來保護憑證或個人資料。其次,gzip 的 CRC32 能偵測意外的損壞,但並非密碼學層級的完整性保證,因此能編輯位元組的攻擊者通常也能編輯尾部。第三,目的端系統很重要:某些 API 預期原始 gzip 位元組,某些預期 Base64,某些預期 Content-Encoding: gzip 標頭,還有一些預期實體的 .gz 檔案。此工具產生的是 Base64 包裝形式,因此在批次送出數千個項目之前,請確認目的端與該容器相符。
| 批次執行期間的症狀 | 最可能的原因 | 處理方式 |
|---|---|---|
| 解壓縮回傳「not valid UTF-8」 | gzip 載荷為二進位檔案而非文字 | 使用二進位檔案 gzip 工具 |
| 解壓縮回傳 Base64 錯誤 | 缺少填補、含有空白字元或字母表錯誤 | 將字串重新匯出為標準的 RFC 4648 Base64 |
| 結果看起來合理但下游拒絕 | 容器不符(原始位元組 vs Base64 vs .gz) | 檢查目的端預期的編碼包裝方式 |
| 頁面在大量貼上時凍結 | 解壓縮膨超出 5,000,000 位元組上限 | 將輸入切割成多個區塊,並對每個區塊執行頁面一次 |
| 相同文字的兩次執行產生不同的 Base64 | 不同執行間的 gzip 標頭與 DEFLATE 選擇有所不同 | 驗證解壓縮後的內容,而非精確的位元組 |
批次模式:迴圈、管線與貼上紀律
最快的批次模式是簡短的迴圈:一次將一個字串送入頁面的輸入框,複製 Base64 結果,並將其附加到清單中。由於當模式或輸入變更時,介面會取消過時的非同步結果,你可以持續輸入而無需等待上一次執行完成——只有最新執行的結果會被採用,任何較舊的執行中任務都會被捨棄。在貼上紀律方面,請將每個壓縮字串視為獨立的區塊:不要有前導的 data: URI、不要有 base64, 標記、不要有尾隨註解。頁面不會移除這些內容,因此解碼器接受該字串之前,必須先移除任何額外的包裝。
若要在頁面周圍進行自動化,可將其與一個動無頭瀏覽器並擷取每個 Base64 結果的小腳本搭配使用,或事先組合許多壓縮項目並將其作為佇列貼上。只要每個項目都低於大小上限,處理單一字串的同一個 Gzip Compress & Decompress 工作流程也能處理包含數千筆的佇列。當目的端是文字時——例如 JSON 欄位、記錄檔行、設定值——Base64 包裝的 gzip 串流可直接放入而無需進一步轉換,而從 UTF-8 到 gzip Base64 再回來的來回轉換,會由頁面在每次執行時檢查的框架不變式完整保留。
釐清容器細節的格式參考資料:RFC 1952(gzip 容器)以及 Compression Streams 規範(此工具所使用的瀏覽器 API)。
相關閱讀:如何將十六進位轉換為可讀文字:Plain 與 0xNN。
相關閱讀:如何從文字或檔案計算 SHA-1 雜湊。