線上 gzcompress PHP 工作流程應先辨識所需的容器：此瀏覽器工具會建立以 Base64 包裝的 RFC 1952 gzip，而不是 PHP gzcompress() zlib 串流。Gzip 壓縮與解壓縮工具可處理該工作的 gzip 部分。它會將輸入的 UTF-8 文字轉換為 gzip 位元組，將這些二進位位元組顯示為完整且填補的 Base64，並將程序反轉為嚴格有效的 UTF-8 文字。處理程序透過瀏覽器原生 Compression Streams 在本機執行，因此不必將內容傳送到伺服器進行壓縮。反向模式會先檢查 Base64 包裝、最小 gzip 結構、壓縮串流、尾端與最終 UTF-8 編碼，再顯示還原的文字。當 PHP 應用程式、API 欄位、設定值或純文字傳輸明確要求以 Base64 包裝的 gzip 時，此格式很有用。若接收端預期的是 zlib，它並不是 PHP gzcompress() 的直接替代方案。請先確認目的端所需的格式；線上結果是 gzip 加 Base64，而 .gz 檔案或 HTTP Content-Encoding 值則採用不同的傳遞慣例。
Gzip、zlib 與 PHP gzcompress()
「線上 gzcompress PHP」這個詞可能指重現 PHP 的壓縮行為、為 PHP 壓縮資料，或只是在瀏覽器中建立 gzip 內容載荷。這些是相關的工作，但格式並不相同。PHP 的 gzcompress() 函式會產生 zlib 串流，而 gzencode() 等以 gzip 為主的函式則會產生 RFC 1952 gzip 串流。本文的線上工作流程刻意建立 gzip，因為 gzip 廣泛用於壓縮檔案與 HTTP 內容編碼。
Base64 增加第三層。它不會壓縮任何內容；它會將二進位 gzip 位元組表示成可複製到表單、JSON 欄位、原始檔或其他純文字位置的文字。接收系統必須先移除 Base64 包裝，才能處理 gzip 串流。
| 目的端需求 | 預期表示法 | 與此工具的相符程度 |
|---|---|---|
| PHP gzcompress() 或 zlib 解碼器 | Zlib 串流 | 與 gzip 輸出不相容 |
| Gzip API 或二進位 gzip 讀取器 | RFC 1952 gzip 位元組 | 先解碼 Base64 包裝 |
| 以 Base64 包裝的 gzip 欄位 | 標準且填補的 Base64 | 直接符合工具輸出 |
| HTTP Content-Encoding: gzip | 依適當協定處理的原始 gzip 表示法 | Base64 無法取代內容編碼層 |
| .gz 檔案 | 包含 gzip 資料的二進位檔案 | 寫入檔案前先解碼 Base64 |
壓縮並還原 UTF-8 文字
- 開啟工具並選擇將 UTF-8 文字轉為 gzip Base64。
- 將來源文字貼到輸入欄位。大小限制以 UTF-8 位元組計算，而非可見字元，因為一個非 ASCII 字元可能需要數個位元組。
- 執行壓縮操作並等待完整的 Base64 結果。
- 複製整個已填補的 Base64 字串。工具不會在結果中插入空格、換行、data URL 前置詞或檔案名稱。
- 若要執行反向操作，請選擇將 Gzip Base64 轉為 UTF-8。
- 只貼上包含 RFC 1952 gzip 串流的標準 Base64 字串。缺少填補、插入空白字元、無效字母表字元及非零填補位元都會遭到拒絕。
- 執行解壓縮操作。若 gzip 資料損毀或不完整，系統會傳回錯誤，而不會顯示部分文字。
- 複製還原的 UTF-8 文字並與原始內容比較，包括標點符號、換行、重音符號、表情符號及其他 Unicode 字元。
- 確認目的端預期的是這種以 Base64 包裝的 gzip 表示法。若內容載荷是影像、封存檔、可執行檔或其他非文字檔案，請使用二進位 gzip 工具。
每個成功結果背後的檢查
壓縮程序會先將輸入的字串轉換為 UTF-8 位元組。這些位元組會經由瀏覽器的 Compression Streams 實作處理，進而建立 gzip 串流。反向模式會套用嚴格的 RFC 4648 Base64 解碼、檢查最小 gzip 框架與魔術位元組，然後使用解壓縮支援。瀏覽器會先驗證壓縮串流及其尾端，之後才視解碼後的位元組為完整。
| 層 | 值或需求 |
|---|---|
| 文字編碼 | 來源字串會在壓縮前轉換為 UTF-8。 |
| Base64 包裝 | 標準且已填補的 Base64，不含空白字元、前置詞或檔案名稱。 |
| Gzip 簽章 | 魔術位元組 1f 8b 會開始串流。 |
| 壓縮方法 | CM=8 表示 DEFLATE。 |
| Gzip 尾端 | 八位元組的小端序尾端包含未壓縮位元組的 CRC32，以及輸入大小對 2^32 取模所得的 ISIZE。 |
| 還原內容 | 解壓縮後的位元組必須通過嚴格的 UTF-8 解碼。 |
這些欄位由 RFC 1952 定義。Gzip 本身可容納任意二進位資料，但本頁刻意只接受文字輸入，也只產生嚴格有效的 UTF-8 輸出。因此，包含非文字檔案的有效 gzip 串流會在最終解碼階段失敗，而不會在未告知的情況下被轉換或損毀。
為何有效的 Gzip Base64 可能看起來不同
在所有編碼器之間，gzip 輸出在位元組層級並不具決定性。標頭欄位、DEFLATE 選擇與壓縮層級可能不同，但所有輸出解壓縮後都會得到相同內容。因此，兩個有效的 Base64 字串不一定需要逐字相符。請比較其解碼後的 gzip 串流與還原內容，而不是依據某個預先指定的「正確」拼寫。
工具的檢查會使用真正的解壓縮，以及對 gzip 魔術位元組、CM 值、CRC32 與 ISIZE 的獨立檢視。這種做法能辨識有效的框架與內容，同時不斷言每個壓縮器都必須產生相同的壓縮位元組。
在 PHP 傳遞流程中使用以 Base64 包裝的 Gzip
- 檢查 PHP 接收端，判斷它預期的是 zlib 還是 gzip，以及需要原始位元組、Base64、.gz 檔案或 HTTP 內容編碼回應。
- 若它明確預期以 Base64 包裝的 RFC 1952 gzip，請選擇將 UTF-8 文字轉為 gzip Base64並壓縮確切的內容載荷。
- 將完整且已填補的結果複製到約定的文字欄位。請將 URL 編碼或 JSON 逸出視為獨立的傳輸步驟；兩者都不會改變底層的 gzip 表示法。
- 在 PHP 端，先執行嚴格的 Base64 解碼，再將結果位元組傳給 gzip 解碼器。
- 不要將此輸出直接傳送給預期從 gzcompress() 取得 zlib 串流的程式碼。若接收端需要 zlib，請改用適當的 PHP 端壓縮函式產生該容器。
- 若 HTTP 回應使用 Content-Encoding: gzip，請遵循協定對原始內容本文與標頭的要求，而不是將 Base64 嵌套至已編碼的本文中。
- 使用具代表性的 UTF-8 內容執行小型往返測試，比較還原後的位元組或文字，然後驗證應用程式本身的結構描述與商業意涵。
這種分離方式可避免常見的整合錯誤：將 Base64 視為壓縮、將 gzip 視為 zlib，或將文字欄位視為二進位檔案。每一層都有不同的用途，且必須依正確順序解碼。
錯誤、限制與安全邊界
嚴格驗證有助於防止損毀的資料看似有效。反向模式會拒絕缺少 Base64 填補、含有空白字元、無效字元、填補位元不正確、gzip 框架錯誤、壓縮區塊損毀及串流不完整等情況。若 gzip 解壓縮成功，但結果位元組不是 UTF-8，工具會回報文字解碼錯誤。它不會替換無效位元組、插入猜測的字元，也不會傳回部分輸出。
輸入與解壓縮後的輸出上限為 5,000,000 位元組。這可防止過大的貼上內容及擴充資料使瀏覽器分頁失去回應。輸出絕不會在未告知的情況下遭到截斷。當模式或輸入內容變更時，介面也會取消過時的非同步工作，避免較舊的工作覆蓋較新的結果。非 ASCII 文字達到位元組上限的速度，可能比可見字元數所呈現的更快。
壓縮不等於加密、保密、驗證或清理消毒。任何取得 gzip 內容載荷的人都能將其解壓縮。CRC32 有助於偵測意外損毀，但無法提供防範蓄意修改的密碼學保證。請勿使用 gzip Base64 隱藏憑證、個人資料或其他敏感資料。
執行最終往返檢查
- 確認接收該內容的 PHP 程式碼預期的是 gzip，而非 zlib。
- 檢查 Base64 值是否具有必要的填補，且未遭換行或空格修改。
- 確保內容載荷前後沒有不應存在的 data URL 前置詞或檔案名稱。
- 在工具中解壓縮副本，並將還原的 UTF-8 文字與預期來源比較。
- 根據定義內容意義與格式的應用程式，驗證解碼後的內容。
複製作業成功只能證明文字表示法能完整傳輸，並不能證明接收應用程式選擇了正確的容器。確認兩端的格式，可避免有效的 gzip 內容載荷因類型錯誤而遭到拒絕。