此頁面由社群從英文翻譯而來。了解更多並加入 MDN Web Docs 社群。
Accept-Encoding 標頭
Baseline Widely available *
This feature is well established and works across many devices and browser versions. It’s been available across browsers since 2015年7月.
* Some parts of this feature may have varying levels of support.
HTTPAccept-Encoding請求和回應標頭表示發送方可以理解的內容編碼（通常是壓縮演算法）。在請求中，伺服器使用內容協商從用戶端的編碼提案中選擇一個，並使用Content-Encoding 回應標頭通知用戶端選擇。在回應中，它提供有關伺服器可以理解的內容編碼的訊息，以便在後續對資源的請求中使用該編碼。例如，如果對資源的請求（例如PUT）使用了不支援的編碼，則Accept-Encoding 會包含在415 Unsupported Media Type 回應中。
即使用戶端和伺服器都支援相同的壓縮演算法，如果是identity 值也是可接受的，伺服器可能選擇不壓縮回應的主體。這在兩種常見情況下發生：
- 資料已經壓縮，這意味著第二輪壓縮不會減少傳輸的資料大小，甚至在某些情況下可能會增加內容大小。這對於預壓縮的圖像格式（例如 JPEG）是正確的。
- 伺服器過載，無法分配計算資源來執行壓縮。例如，Microsoft 建議如果伺服器使用超過 80% 的計算能力，則不要壓縮。
只要identity;q=0 或*;q=0 指令沒有明確禁止identity 值（即無編碼），伺服器絕不能返回406 Not Acceptable 錯誤。
備註：IANA 維護官方內容編碼列表。bzip 和bzip2 編碼是非標準的，但在某些情況下可能會使用，包括對舊版的支援。
語法
Accept-Encoding: gzipAccept-Encoding: compressAccept-Encoding: deflateAccept-Encoding: brAccept-Encoding: zstdAccept-Encoding: dcbAccept-Encoding: dczAccept-Encoding: identityAccept-Encoding: *// 使用品質值語法加權多個演算法：Accept-Encoding: deflate, gzip;q=1.0, *;q=0.5指令
gzip使用Lempel-Ziv 編碼（LZ77）和 32 位元的 CRC 的壓縮格式。
compress使用Lempel-Ziv-Welch（LZW）演算法的壓縮格式。
deflatebr使用Brotli 演算法的壓縮格式。
zstd使用Zstandard 演算法的壓縮格式。
dcb實驗性質使用Dictionary-Compressed Brotli 演算法的壓縮格式。參見壓縮字典傳輸指南。
dcz實驗性質使用Dictionary-Compressed Zstandard 演算法的壓縮格式。參見壓縮字典傳輸指南。
identity表示恆等函數（即無修改或壓縮）。即使省略，此值始終被視為可接受的。
*（萬用字元）匹配標頭中尚未列出的任何內容編碼。如果標頭不存在，則這是預設值。此指令不表示支援任何演算法，而表示不表達任何偏好。
;q=（加權 q 值）任何值都按照使用相對品質值（稱為權重）表示的偏好順序。
範例
預設 Accept-Encoding 值
瀏覽器導航通常具有以下Accept-Encoding 請求標頭值：
GET /en-US/ HTTP/2Host: developer.mozilla.orgAccept-Encoding: gzip, deflate, br, zstd加權 Accept-Encoding 值
以下標頭顯示使用品質值的Accept-Encoding 偏好，範圍在0（最低優先級）和1（最高優先級）之間。Brotli 壓縮的權重為1.0，使br 成為用戶端的首選，其次是權重為0.8 的gzip，然後是任何其他內容編碼，權重為0.1：
Accept-Encoding: br;q=1.0, gzip;q=0.8, *;q=0.1規範
| Specification |
|---|
| HTTP Semantics # field.accept-encoding |