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 算法的格式。参见压缩字典传输。