Content-Encoding
是一个实体消息首部,用于对特定媒体类型的数据进行压缩。当这个首部出现的时候,它的值表示消息主体进行了何种方式的内容编码转换。这个消息首部用来告知客户端应该怎样解码才能获取在 Content-Type
中标示的媒体类型内容。
一般建议对数据尽可能地进行压缩,因此才有了这个消息首部的出现。不过对于特定类型的文件来说,比如jpeg图片文件,已经是进行过压缩的了。有时候再次进行额外的压缩无助于负载体积的减小,反而有可能会使其增大。
Header type | Entity header |
---|---|
Forbidden header name | no |
语法
Content-Encoding: gzip Content-Encoding: compress Content-Encoding: deflate Content-Encoding: identity Content-Encoding: br
指令
gzip
- 表示采用 Lempel-Ziv coding (LZ77) 压缩算法,以及32位CRC校验的编码方式。这个编码方式最初由 UNIX 平台上的 gzip 程序采用。处于兼容性的考虑, HTTP/1.1 标准提议支持这种编码方式的服务器应该识别作为别名的
x-gzip
指令。 compress
- 采用 Lempel-Ziv-Welch (LZW) 压缩算法。这个名称来自UNIX系统的 compress 程序,该程序实现了前述算法。
与其同名程序已经在大部分UNIX发行版中消失一样,这种内容编码方式已经被大部分浏览器弃用,部分因为专利问题(这项专利在2003年到期)。 deflate
- 采用 zlib 结构 (在 RFC 1950 中规定),和 deflate 压缩算法(在 RFC 1951 中规定)。
identity
- 用于指代自身(例如:未经过压缩和修改)。除非特别指明,这个标记始终可以被接受。
br
- 表示采用 Brotli 算法的编码方式。
示例
使用 gzip 方式进行压缩
客户端可以事先声明一系列的可以支持压缩模式,与请求一齐发送。 Accept-Encoding
这个首部就是用来进行这种内容编码形式协商的:
Accept-Encoding: gzip, deflate
服务器在 Content-Encoding
响应首部提供了实际采用的压缩模式:
Content-Encoding: gzip
需要注意的是,服务器端并不强制要求一定使用何种压缩模式。采用哪种压缩方式高度依赖于服务器端的设置,及其所采用的模块。
规范
Specification | Title |
---|---|
RFC 7231, section 3.1.2.2: Content-Encoding | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |
http://www.ietf.org/id/draft-alakuijala-brotli | Brotli Compressed Data Format |
浏览器兼容性
The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out https://github.com/mdn/browser-compat-data and send us a pull request.
Feature | Chrome | Firefox | Edge | Internet Explorer | Opera | Safari |
---|---|---|---|---|---|---|
Basic Support | (Yes) | (Yes) | (Yes) | (Yes) | (Yes) | (Yes) |
br | 50 | 44.0 | (No) | (No) | 36.0 | (No) |
Feature | Android | Chrome for Android | Edge mobile | Firefox for Android | IE mobile | Opera Android | iOS Safari |
---|---|---|---|---|---|---|---|
Basic Support | (Yes) | (Yes) | (Yes) | (Yes) | (Yes) | (Yes) | (Yes) |
br | 51 | 51 | (No) | 44.0 | (No) | (No) | (No) |