在 Windows 上執行 gzcompress online 是一個單一分頁的工作流程：在 Windows 10 或 11 上開啟 Microsoft Edge 或 Google Chrome，載入 Gzip Compress & Decompress 頁面，將 UTF-8 文字貼入壓縮框，瀏覽器就會回傳一段 Base64 字串，其中包裹著完整加上框線的 RFC 1952 gzip 位元組串流。不需要 PowerShell cmdlet、不需要安裝 WSL、不需要設定 7-Zip，也不需要上傳任何檔案，因為這個頁面會直接呼叫瀏覽器原生的 CompressionStream('gzip') 與 DecompressionStream('gzip') 建構函式。壓縮輸出刻意採用 Base64 編碼，這樣才能將其貼到 JSON 設定欄位、HTTP 請求內文、記錄檔或聊天訊息中，而不會受到不可列印位元組的損壞。若要反向操作，同一個頁面接受一段符合標準且帶有填補的 Base64 字串（其中包含 gzip 串流），會驗證 1f 8b 的魔術數字標頭以及值為 8 的壓縮方法位元組，讓瀏覽器解壓縮 DEFLATE 酬載，檢查 CRC32 與 ISIZE 尾標，然後回傳嚴格的 UTF-8 文字。雙向操作都在使用者的渲染程序中執行，底層位元組從不外送到裝置以外。

gzcompress online on windows
在 Windows 上使用 Gzcompress Online：在 Edge 或 Chrome 中執行

為什麼「gzcompress online on Windows」是常見的搜尋

Windows 自從 Windows 10 1803 版以來就一直內建支援 gzip 的工具，但它們藏在命令提示字元或 PowerShell 之後。Windows 上的 tar.exe 公用程式可以使用 tar -czf 和 tar -xzf 來建立和解壓縮 .gz 檔案，PowerShell 也能以 shell 方式呼叫它，但 PowerShell 本身的 Compress-Archive cmdlet 會產生 .zip 封存檔而非 gzip，因此當開發者讀到「gzcompress」這個詞時，它並不符合預期。對於只想貼上一段 UTF-8 文字、產生 gzip 串流、並將結果以安全字串形式複製到設定檔或 API 酬載中的使用者來說，開啟 Edge 或 Chrome 執行瀏覽器原生的 gzip 工具，會比開啟終端機更快速。這正是 Gzip Compress & Decompress 頁面所支援的工作流程：瀏覽器負責處理，結果採用 Base64 因此能貼到任何地方，而且完全不上傳。

為什麼 Edge 或 Chrome 是 Windows 10 與 11 上合適的執行環境

這兩款瀏覽器皆內建 WHATWG Compression Streams 規範，向 JavaScript 公開 CompressionStream('gzip') 和 DecompressionStream('gzip')。Edge 自 2022 年中的 103 版起便支援此 API，Chrome 則自 2020 年初的 80 版起支援，因此幾乎每個受支援的 Windows 10 或 11 安裝環境都已經具備 gzip 與 gunzip 文字所需的執行環境。由於頁面直接呼叫這些建構函式，因此不需要下載任何函式庫、不需要註冊 DLL，也不需要系統管理員權限。壓縮會在使用者分頁所使用的同一個渲染程序中執行，位元組從不離開裝置。在 Windows 上這點比在 macOS 或 Linux 上更為關鍵，因為使用者無法假設系統中一定存在 gzip 二進位檔，即使有 tar.exe，它產生的也是磁碟上的 .gz 檔案，而非可直接貼上的 Base64 字串。以瀏覽器為基礎的工作流程則完全跳過檔案系統。

在 Windows 上將 UTF-8 文字壓縮成 gzip Base64

  1. 在 Windows 10 或 11 上開啟 Microsoft Edge 或 Google Chrome，並前往 Gzip Compress & Decompress 頁面。
  2. 若尚未選取，請選擇「UTF-8 text to gzip Base64」模式。
  3. 將想要壓縮的 UTF-8 文字貼上或輸入到輸入框中。頁面會先將 JavaScript 字串編碼為 UTF-8 位元組，再將其傳遞給 CompressionStream('gzip')；請記住非 ASCII 字元可能會各佔 2、3 或 4 個位元組，因此 gzip 串流的 ISIZE 欄位反映的是位元組長度，而非可見字元數。
  4. 點擊 Compress。頁面會在 UTF-8 位元組上執行串流，並將產生的二進位輸出編碼為符合標準且帶有填補的 Base64，不含空格、換行、data: URL 前綴或檔名。
  5. 使用 Copy 按鈕複製完整的 Base64 輸出。請擷取整段字串，包含任何尾端的 = 填補字元，因為截斷的 Base64 字串將無法在接收端解碼。
  6. 將結果貼到預期接收 gzip 串流的目的地，無論是 JSON 設定值、資料庫欄位、HTTP 請求內文，或是要貼到 Notepad 的 Windows 剪貼簿。

在 Windows 上將 gzip Base64 解壓縮回 UTF-8 文字

  1. 將頁面切換到「Gzip Base64 to UTF-8」模式。
  2. 貼上包裹著 gzip 串流的、符合標準且帶有填補的 Base64 字串。解碼器在執行任何解壓縮動作前，會先拒絕空白字元、無效的字母字元、缺少的填補，以及非零的填補位元，因此請僅貼上 Base64 酬載。
  3. 點擊 Decompress。頁面會驗證最低 gzip 框線：開頭的 1f 8b 魔術位元組，以及設為 8 以代表 DEFLATE 的壓縮方法位元組。未通過此檢查的串流會在不接觸 DecompressionStream 的情況下遭到拒絕。
  4. 瀏覽器會解壓縮串流，並檢查八個位元組的小端序尾標，其中包含未壓縮位元組的 CRC32 以及 ISIZE 欄位（也就是原始大小模 2^32）。輸入損壞或不完整時會回傳錯誤，而非回傳部分文字。
  5. 解壓縮後的位元組會以嚴格模式解碼為 UTF-8。若無法構成有效的 UTF-8 序列，工具會回報失敗，而不會取代位元組或產生亂碼。
  6. 請在輸出面板中驗證還原後的文字，並確認接收端應用程式實際上預期的是這個確切的容器——一段包裹著 UTF-8 文字的 Base64 gzip 串流——之後再將整個往返流程視為成功。

RFC 1952 框線對工作流程的意義

壓縮酬載並非「原始 DEFLATE」，而是具有固定標頭、每筆紀錄可選的中繼資料、壓縮後的 DEFLATE 區塊，以及固定尾標的完整加上框線的 gzip 串流。此工具會根據 RFC 1952 規範，在輸入時驗證此框線，並在輸出時產生此框線；但了解欄位配置有助於您除錯，找出為什麼某個目的地接受一個 gzip 串流，卻拒絕另一個。

位移大小（位元組）欄位意義
02ID1, ID2識別 gzip 容器的魔術位元組 1f 8b
21CM壓縮方法；DEFLATE 必須為 8
31FLG旗標位元組；位元 0 FTEXT，位元 1 FHCRC，位元 2 FEXTRA，位元 3 FNAME，位元 4 FCOMMENT，位元 5–7 保留
44MTIME原始檔案在 Unix 紀元秒數下的修改時間
81XFL壓縮器使用的額外旗標；例如 4 = 最快速度，2 = 最大壓縮
91OS原始作業系統；0 = FAT，3 = Unix，255 = 未知
10..n不定壓縮資料一個或多個 DEFLATE 區塊
trailer−8..trailer−18CRC32, ISIZE原始未壓縮位元組的小端序 CRC32，接著是原始大小模 2^32

兩個 gzip 編碼器可能在 FLG、MTIME、XFL 與 OS 上意見分歧，但解壓縮後仍會得到相同的位元組。這正是為什麼此工具並不保證產生唯一標準的 Base64 字串；而是在每次執行時驗證框線不變量（魔術數字、CM=8、CRC32、ISIZE）。作為具體範例，字串 café 有 4 個可見字元，但編碼為 5 個 UTF-8 位元組：c (U+0063, 1 位元組) + a (U+0061, 1 位元組) + f (U+0066, 1 位元組) + é (U+00E9, 2 位元組) = 5 位元組。尾標中的 CRC32 是以這 5 個位元組計算得出，ISIZE 將記錄為 5，雖然螢幕上的字串看起來是 4 個字元。

Windows 特有的陷阱：CRLF、字碼頁與剪貼簿編碼

Windows 對乾淨的文字輸入特別不友善，若您不小心貼入或從此工具複製出去，下列三個怪癖將會咬您一口。

  • CRLF 行尾。Windows 上的 Notepad 寫入 UTF-8 檔案時會附上 UTF-8 BOM，並將 \n 轉換為 \r\n。若您從 Notepad 複製多行字串到壓縮框中，CRLF 行尾就會成為壓縮酬載的一部分。這是正確的行為，但在 Linux 目標上解壓縮後的字串將會包含多餘的 \r 字元。若目的地預期的是 Unix 行尾，請先將檔案另存為「UTF-8（無 BOM）」加上 Unix 行尾，或使用 Notepad++ 或 VS Code 來控制編碼。
  • 主控台字碼頁。在 cmd.exe 中輸入 type file.txt 會以作用中的 OEM 字碼頁（通常是 Windows-1252）讀取檔案，將其貼到瀏覽器時，Windows-1252 的多位元組會變成亂碼。請在 PowerShell 中使用 Get-Content -Encoding UTF8，或直接在 Notepad 中開啟檔案並從中複製。
  • 終端機貼上會附加尾端 CR。在 Windows 終端機中貼上 Base64 字串後再從終端機重新複製，有時會引入尾端的歸位字元。嚴格的 RFC 4648 解碼器會將其視為無效字母字元而拒絕。貼入解壓縮框之前，請先清除來源中的空白字元，或使用程式碼編輯器確認 Base64 是乾淨的。

在 Windows 上使用 gzcompress online 不適合的情境

此頁面刻意設計為文字工作流程。若 gzip 串流包裹的是二進位檔案，例如 JPEG 影像、.tar 封存檔、PDF，或舊式 Windows-1252 編碼的文件，嚴格的 UTF-8 解碼器會拒絕產生字串。在此情況下，請使用像 7-Zip 這樣的桌面 gzip 解壓縮工具，或從 PowerShell 執行 tar -xzf file.gz 以在磁碟上還原原始位元組。

若您需要位元組完全相同的輸出以用於數位簽章、可重現建置或雜湊承諾，此工具同樣不適合。即使兩個 gzip 工具解壓縮後得到相同內容，它們幾乎從不產生相同的位元組，因為上述標頭欄位（MTIME、OS、XFL）以及 DEFLATE 區塊選擇會因編碼器而異。請將 gzip 視為內容的容器，而非穩定的序列化方式，並應以解壓縮後的文字進行驗證，而非依據固定的 Base64 拼字。

最後，gzip 並非加密。它是由 RFC 1952 定義的無損壓縮格式，任何持有該 Base64 字串的人都能將其解壓縮。請勿將 API 金鑰、密碼、工作階段權杖或個人資料貼到此工具中以期望獲得保密性，也勿將 CRC32 視為對竄改的保護——它只能偵測意外的損壞，無法防範能同時重寫串流與尾標的攻擊者。

若您正在權衡選項，在 Windows 上不安裝軟體即可進行二進位轉文字對此有詳細說明。

若您正在權衡選項，gzcompress online 用於 UTF-8 文字是否安全？對此有詳細說明。