Content-Encoding 頭

Baseline 廣泛可用 *

此特性已相當成熟，可在許多裝置和瀏覽器版本上使用。自 ⁨2015 年 7 月⁩以來，各瀏覽器均已提供此特性。

* 此特性的某些部分可能存在不同級別的支援。

HTTP Content-Encoding 表示性頭列出了已應用於資源的編碼及其應用順序。這使接收者知道如何解碼資料以獲取 Content-Type 頭中描述的原始內容格式。內容編碼主要用於在不丟失原始媒體型別資訊的情況下壓縮內容。

伺服器應儘可能多地壓縮資料，並在適當情況下使用內容編碼。壓縮已壓縮的媒體型別（例如 .zip 或 .jpeg）通常不合適，因為它可能會增加檔案大小。如果原始媒體已被編碼（例如，作為 .zip 檔案），則此資訊不包含在 Content-Encoding 頭中。

當 Content-Encoding 頭存在時，除非明確說明，否則其他元資料（例如 Content-Length）指的是資料的編碼形式，而不是原始資源。內容編碼與 Transfer-Encoding 不同，Transfer-Encoding 處理 HTTP 訊息本身如何逐跳在網路上傳輸。

頭型別	表示形式頭
禁止請求頭	否

語法

http

Content-Encoding: gzip
Content-Encoding: compress
Content-Encoding: deflate
Content-Encoding: br
Content-Encoding: zstd
Content-Encoding: dcb
Content-Encoding: dcz

// Multiple, in the order in which they were applied
Content-Encoding: deflate, gzip

指令

gzip: 使用 Lempel-Ziv 編碼 (LZ77) 的格式，帶有一個 32 位 CRC。這是 UNIX gzip 程式的原始格式。HTTP/1.1 標準還建議，支援此內容編碼的伺服器應識別 x-gzip 作為別名，以實現相容性。
壓縮（compress）: 使用 Lempel-Ziv-Welch (LZW) 演算法的格式。該值名稱取自實現此演算法的 UNIX compress 程式。與已從大多數 UNIX 發行版中消失的 compress 程式一樣，此內容編碼在今天不被許多瀏覽器使用，部分原因是專利問題（已於 2003 年過期）。
解壓縮（deflate）: 使用 zlib 結構（定義於 RFC 1950），以及 deflate 壓縮演算法（定義於 RFC 1951）。
br: 使用 Brotli 演算法結構（定義於 RFC 7932）的格式。
zstd: 使用 Zstandard 演算法結構（定義於 RFC 8878）的格式。
dcb 實驗性: 使用字典壓縮 Brotli 演算法的格式。參見壓縮字典傳輸。
dcz 實驗性: 使用字典壓縮 Zstandard 演算法的格式。參見壓縮字典傳輸。