內容編碼

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

鼓勵伺服器儘可能壓縮資料，並在適當的情況下使用內容編碼。壓縮壓縮媒體型別（如 .zip 或 .jpeg）可能不合適，因為這會導致內容變大。如果原始媒體已以某種方式編碼（例如，.zip 檔案），則此資訊將不會包含在 Content-Encoding 頭中。

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

頭型別 表示頭
禁止的頭名稱 否

語法

http
Content-Encoding: gzip
Content-Encoding: compress
Content-Encoding: deflate
Content-Encoding: br
Content-Encoding: zstd

// 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 程式，該程式實現了此演算法。與 compress 程式（已從大多數 UNIX 發行版中消失）一樣，這種內容編碼如今未被許多瀏覽器使用，部分原因是專利問題（已於 2003 年過期）。

deflate

使用 zlib 結構（在 RFC 1950 中定義）和 deflate 壓縮演算法（在 RFC 1951 中定義）。

br

使用 Brotli 演算法結構（在 RFC 7932 中定義）的格式。

zstd

使用 Zstandard 演算法結構（在 RFC 8878 中定義）的格式。

示例

使用 gzip 壓縮

在客戶端，您可以宣傳將在 HTTP 請求中傳送的壓縮方案列表。 Accept-Encoding 頭用於協商內容編碼。

http
Accept-Encoding: gzip, deflate

伺服器使用 Content-Encoding 響應頭指示使用的方案進行響應。

http
Content-Encoding: gzip

請注意，伺服器沒有義務使用任何壓縮方法。壓縮高度依賴於伺服器設定和使用的伺服器模組。

規範

規範
HTTP 語義
# field.content-encoding

瀏覽器相容性

BCD 表格僅在瀏覽器中載入

另請參見