内容编码

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 表格仅在浏览器中加载

另请参见