15.5 Content-Encoding：内容编码

• HTTP 应用程序有时在发送之前需要对内容进行编码。常见的比如服务器利用 gzip 进行压缩，减少传输实体的时间。

1. 内容编码过程

• 内容编码的过程：
  
  1. 网站服务器生成原始响应报文，其中有原始的 Content-Type 和 Content- Length 首部。
  2. 内容编码服务器(也可能就是原始的服务器或下行的代理)创建编码后的报文。编码后的报文有同样的 Content-Type 但 Content-Length 可能不同(比如主体被压缩了)。内容编码服务器在编码后的报文中增加 Content-Encoding 首部，这样接收的应用程序就可以进行解码了。
  3. 接收程序得到编码后的报文，进行解码，获得原始报文。
     
• 注意，编码后：
  
  • Content-Length 首部代表的是编码之后的主体长度；
  • Content-Type 首部代表的还是实体的原始格式。

2. 内容编码类型

• HTTP 定义了一些标准的内容编码类型，并允许用扩展编码的形式增添更多的编码。由互联网号码分配机构(IANA)对各种编码进行标准化，它给每个内容编码算法分配了唯一的代号。Content-Encoding 首部就用这些标准化的代号来说明编码时使用的算法。
• 常用的内容编码代号：

Content-Encoding 值 描述 gzip 表明实体采用 GNU zip 编码 compress 表明实体采用 Unix 的文件压缩程序 deflate 表明实体是用 zlib 的格式压缩的 identity 表明没有对实体进行编码。当没有 Content-Encoding 首部时，就默认为这种情况

• gzip、compress 以及 deflate 编码都是无损压缩算法，用于减少传输报文的大小，不 会导致信息损失。这些算法中，gzip 通常是效率最高的，使用最为广泛。

3. Accept-Encoding 首部

• 我们不希望服务器用客户端无法解码的方式来对内容进行编码。为了避免服务器使用客户端不支持的编码方式，客户端就把自己支持的内容编码方式列表放在请求的 Accept-Encoding 首部里发出去。如果 HTTP 请求中没有包含 Accept-Encoding 首部，服务器就可以假设客户端能够接受任何编码方式(等价于发送 Accept-Encoding: *)。
  
• Accept-Encoding 字段包含用逗号分隔的支持编码的列表，下面是一些例子:
  Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
• 客户端可以给每种编码附带 Q(质量)值参数来说明编码的优先级。Q 值的范围从 0.0 到 1.0，0.0 说明客户端不想接受所说明的编码，1.0 则表明最希望使用的编码。