在瀏覽器內完全處理您的 UTF-8 文字、永不上傳位元組、並在本地驗證 RFC 1952 框架的情況下，在線上執行 gzcompress 是安全的。這一個事實將一個值得信賴的瀏覽器內部 gzip 工作流程，與風險更高的「將您的文字貼到表單中並祈禱伺服器是誠實的」模式區分開來。大多數關於在線 gzip 工具的隱私問題都來自伺服器步驟：文字會被 POST、解碼、壓縮，然後送回，這表示它存在於傳輸記錄、應用程式記憶體，甚至可能的備份中。瀏覽器原生替代方案跳過了來回過程。該字串會被轉換為 UTF-8 位元組，餵給瀏覽器內建的 Gzip Compress & Decompress 引擎，然後產生的串流會以標準 Base64 形式顯示，由您自行複製。沒有任何東西離開分頁。反向操作也以同樣的方式運作：您貼上 Base64 承載資料，瀏覽器便會解碼、驗證 gzip 魔術數字、執行 DecompressionStream，並檢查尾部。每個檢查都在本地進行，每個位元組都保留在您的裝置上，唯一會發生網路活動的就是頁面的初次載入。
對於在線 gzip 工具，真正的安全問題
「在線工具」這個詞過去意指「伺服器端的網頁應用程式」。對於 gzip 壓縮工具來說，該模型有真正的缺點：您的文字會被送到別人的機器上、在那裡壓縮後送回，而且經常會被快取。如果頁面壓縮超過 100 KB 的承載資料，或將其儲存用於分析，您的片段可能會在您關閉分頁很久之後，仍繼續停留在記錄中。
因此對於壓縮工具，問題不是「在線 gzip 整體而言是否安全」，而是「這個特定頁面是否將我的位元組保留在我的裝置上」。三個特性可以回答這個問題：
- 本地執行 — WHATWG Compression Streams API 在瀏覽器內部建立並讀取 gzip。在壓縮或解壓縮動作中不涉及 HTTP POST 或上傳處理常式。
- 本地驗證 — 在顯示任何文字之前，瀏覽器會先檢查 RFC 1952 框架、CRC32 尾部以及 ISIZE 欄位。
- 無持久化 — 該頁面不會將您的輸入或輸出寫入資料庫、分析端點或 cookie。重新整理分頁會清除一切。
缺少這三個特性中任何一個的工具，仍然可以稱為「在線」，但它不再是那種有資格冠上「安全」一詞的在線工具。
純瀏覽器 gzip 工具如何保護您的文字隱私
純瀏覽器模型建立在一小組平台 API 之上。Compression Streams 規範定義了將 DEFLATE 包裝在 RFC 1952 容器內的 JavaScript 介面。當您要求頁面壓縮文字時，引擎會將您的字串讀為 UTF-8 位元組，透過 CompressionStream('gzip') 執行，然後交回一個符合標準的 Uint8Array 串流。接著頁面將該二進位輸出編碼為標準 Base64 並顯示在畫面上。反向路徑則在嚴格的 RFC 4648 Base64 解碼之後使用 DecompressionStream('gzip')。
因為位元組從不經過網路請求，所以無法被代理伺服器攔截、被 CDN 鏡像，或被應用程式伺服器記錄。即使是具有 content-script 存取權限的惡意瀏覽器擴充功能，所擁有的攻擊窗口也會比伺服器端點來得小，而設計良好的頁面會透過在結果顯示後立即清除輸入來緩解這個問題。
同樣的架構也是為什麼像 在您瀏覽器中執行的免費免註冊 gzip 工具 這樣的相關工作流程，可以毫不誇張地宣稱零資料留存：根本不存在可以關聯到這些位元組的伺服器帳號或提交步驟。
以安全的方式將 UTF-8 文字壓縮為 gzip Base64
若要使用 Gzip Compress & Decompress 並享有完整的安全保證來壓縮文字，請依照以下確切順序操作：
- 在目前的 Chromium、Firefox 或 Safari 版本中開啟工具頁面。需要 Compression Streams API，若該 API 缺失，頁面應會向您發出警告。
- 選擇 UTF-8 text to gzip Base64 模式。替代模式用於反向操作，不接受原始文字。
- 在輸入區域中輸入或貼上 UTF-8 字串。請留意字元計數而非位元組計數：非 ASCII 字元（例如帶重音的字母或表情符號）會擴展為每個二到四個位元組。
- 點選 Compress。瀏覽器會將該字串轉換為 UTF-8 位元組，執行 CompressionStream('gzip')，並將結果以標準含填補 Base64 形式呈現 — 不含 data URL 前綴、不含檔名、不含換行。
- 複製完整的 Base64 字串。該頁面提供複製動作，讓您無需手動選取即可取得結果。
- 確認目的地所預期的容器完全符合此格式。許多 API 要求原始 gzip 位元組、Content-Encoding: gzip 標頭，或 .gz 檔案。以 Base64 包裝的 gzip 是不同的容器；送錯容器會在接收端失敗。
- 如果您的文字包含密碼或個人識別資訊等秘密，請停下來重新考量。Gzip 是壓縮，而非加密 — 任何持有該 Base64 的人都可以將其解壓縮。這類工作負載應使用真正的加密工具。
以安全的方式將 gzip Base64 解壓縮回 UTF-8 文字
若要以安全的方式反轉該工作流程：
- 將工具切換到 Gzip Base64 to UTF-8 模式。
- 僅貼上標準 Base64 承載資料。移除任何 data:application/octet-stream;base64，前綴，以及上游工具可能加入的任何空白字元。
- 點選 Decompress。該頁面會套用嚴格的 RFC 4648 Base64 解碼 — 缺少的填補、多餘的空白、字母表錯誤以及非零的填補位元，都會回傳錯誤而非產生靜默的亂碼。
- 接著解碼器會在將位元組傳遞給 DecompressionStream 之前，驗證最低的 gzip 框架（魔術數字 1f 8b 以及壓縮方法 8）。損毀或不完整的輸入會產生錯誤，永遠不會產生部分文字。
- 解壓縮後的位元組會以 UTF-8 進行嚴格解碼。如果 gzip 串流實際包含影像、封存檔或二進位大型物件，解碼器會將其報告為無效的 UTF-8，而非使用替換字元來取代位元組。
- 複製還原後的文字。透過重新壓縮並逐位元組比對原始輸入，來驗證其能往返相符。
- 確認產生該 Base64 的上游系統確實輸出了 RFC 1952 gzip，而非自訂容器。若非如此，頁面會刻意拒絕該輸入 — 這種拒絕正是安全保證正在運作的證明。
防止意外的限制與防護機制
實作中幾個特定的限制屬於安全設計的一部分，而非任意設定的上限。輸入字串與解壓縮後的輸出皆上限為 5,000,000 位元組。設定此上限有兩個原因：防止意外貼上大型內容而凍結分頁，並限制格式錯誤 gzip 串流可能造成的最壞情況膨脹。當模式或輸入變更時，過時的非同步結果會被取消，因此較慢的舊作業無法用舊的位元組覆蓋較新的值。輸出絕不會被靜默截斷；如果輸入過大，該操作會直接失敗，而不是傳回部分字串。
同樣重要的是尾部檢查。Gzip 在結尾處包含八個 little-endian 位元組：未壓縮資料的 CRC32 以及 ISIZE（輸入大小 mod 2^32）。瀏覽器會根據實際解壓縮後的位元組來驗證這些值。CRC32 能偵測意外的損毀，但並非抵禦攻擊者的密碼學完整性保證，然而它能捕捉所有「格式有效的 gzip 但內容錯誤」的陷阱。
| 串流中的位移 | 欄位 | 用途 | 工具的檢查方式 |
|---|---|---|---|
| 0–1 | 魔術數字 1f 8b | 識別 gzip 串流 | 若前兩個位元組不同則拒絕 |
| 2 | 壓縮方法 (CM) | DEFLATE 必須等於 8 | 若 CM ≠ 8 則拒絕 |
| 3–9 | 標頭旗標、MTIME、XFL、OS | 編碼器中繼資料 | 未驗證；允許因編碼器而異 |
| variable | 壓縮區塊 (DEFLATE) | 實際承載資料 | 由 DecompressionStream 處理 |
| last 8 bytes | CRC32 + ISIZE（little-endian） | 偵測損毀並確認長度 | 與解壓縮後的位元組進行比對 |
嚴格的純文字設計何時是一項特性
此工具刻意是一個純文字工作流程。Gzip 串流可以包裝任何二進位檔案：JPEG 影像、ZIP 封存檔、可執行檔、舊式 Windows-1252 文件。針對每一種情況，該頁面都會回傳嚴格的 UTF-8 錯誤。對於一個名為「文字用 gzcompress 在線工具」的工具來說，這是可能最安全的行為，因為它拒絕靜默替代替換字元、永不產生亂碼 (mojibake)、也絕不讓二進位資料冒充文字通過字串欄位。
如果您擁有 .gz 影像、.tar.gz 封存檔或非 UTF-8 文件，請改用二進位檔案 gzip 工具。權衡是誠實的：此頁面適用於承載資料保證為 UTF-8 文字、傳輸為文字欄位的狹窄工作流程。在該合約之外，保護您免於靜默損毀的同一種拒絕機制，會阻擋合法的解壓縮，而正確的做法是選擇專為二進位輸入所打造的工具。
代表 gzip 工具不安全 的警訊
評估任何在線 gzip 工具時，請將下列情況視為不合格條件：
- 該頁面要求您為一個無狀態的轉換進行登入或建立帳號。
- 該頁面透過連結「儲存」或「分享」您的壓縮結果 — 這暗示著伺服器端儲存。
- 傳回的輸出包裝在您未要求的 data: URL 或 .gz 檔名中。
- 壓縮器僅透過檔案上傳接受輸入，而文字工作流程其實足敷使用。檔案上傳適合用於二進位 gzip，但 UTF-8 文字壓縮器應接受貼上。
- 該頁面無法告訴您實作了哪一個 RFC。Gzip 對應 RFC 1952；如果工具無法說出其名稱，框架檢查很可能並不存在。
- 該工具將壓縮宣傳為加密。事實並非如此。
像 Gzip Compress & Decompress 這樣的瀏覽器原生工具，使用 WHATWG Compression Streams API 且從不將位元組傳送至伺服器，憑藉其設計本身就滿足上述每一項標準的安全那一側。