http 传输格式之客户端还记得上篇文章中我们说了request header 表示的是浏览器传递给服务器的带有浏览器的

前言

上期我们说到 http 请求的伪标头，先回顾一下：伪标头是http2带来的新字段，他们的作用是用来表示 URI 的不同部分，从协议一直到 fragment。

还记得上篇文章中我们说了request header 表示的是浏览器传递给服务器的带有浏览器的一些”个人信息“吗？今天我们就来看看其中的几条吧。 ~~（我也不知道我怎么跳到这里来的~~

accept

request accept.png 首先我们来看看 accept字段

Accept 请求头用来告知（服务器）客户端可以处理的内容类型，这种内容类型用MIME 类型来表示。借助内容协商机制, 服务器可以从诸多备选项中选择一项进行应用，并使用 Content-Type 应答头通知客户端它的选择。浏览器会基于请求的上下文来为这个请求头设置合适的值，比如获取一个 CSS 层叠样式表时值与获取图片、视频或脚本文件时的值是不同的。 MDN

这很明显的就是浏览器的“个人信息”，它告诉接受对象（服务器）自己可以处理媒体类型有哪些。那什么是媒体类型呢？

媒体类型 MIME

为 Multipurpose Internet Mail Extensions 的简称。是一种标准，用来表示文档、文件或字节流的性质和格式。

语法
```
Accept: <MIME_type>/<MIME_subtype>
Accept: <MIME_type>/*
Accept: */*
```
MIME 的组成结构非常简单；由类型与子类型两个字符串中间用'/'分隔而组成。不允许空格存在。type 表示可以被分多个子类的独立类别。subtype 表示细分后的每个类型。

MIME 类型对大小写不敏感，但是传统写法都是小写。

那我们上图中就有很多的 type 如：text，application，image；

text：表明文件是普通文本，理论上是人类可读
application：表明是某种二进制数据
image：表明是某种图像。不包括视频，但是动态图（比如动态 gif）也使用 image 类型

那q=0.9，v=b3，又有冒号又有分号，分别是什么意思呢？

q=0.9：哈哈哈，错了！是 ;q= (q-factor weighting)

此值代表优先顺序，用相对质量价值表示，又称为权重。不填默认为1，比如上面的 text/heml 权重就是1。值是0到1之间的三位小数。

了解更多关于相对质量价值
v=b3：这个东西呢其实也错了，是;v=b3，是叫一个 SXG（签名交换）的东西的版本号，很明显的，它和 application/signed-exchange 这个字段相关联。

签名交换 (SXG) 是一种交付机制，可以独立于资源的交付方式来验证资源的来源。这种解耦推进了各种用例，例如保护隐私的预取、离线互联网体验和从第三方缓存提供服务。此外，实施 SXG 可以改善某些站点的 Largest Contentful Paint (LCP，最大内容绘制：用于测量可视区域中最大内容元素变为可见的时间点。该项指标可用于确定页面主要内容在屏幕上完成渲染的时间点)。

了解更多关于 SXG 和 LCP
还记得 MDN 对accept的说明中出现了一个内容协商机制吗，简单了解下其规则：通过为同一 URI 指向的资源提供不同的展现形式，可以使用户代理选择与用户需求相适应的最佳匹配（例如，文档使用的自然语言，图片的格式，或者内容编码形式）。（暂时跳过）

了解更多关于内容协商机制

accept-encoding

首先这个字段是干啥呢？先顾名思义，接受（的）编码，然后根据语境，补足上下文：客户端告知服务端自己可以接受的数据编码方式？好，Google 一下：

HTTP 请求头 Accept-Encoding 会将客户端能够理解的内容编码方式——通常是某种压缩算法——进行通知（给服务端）。通过内容协商的方式，服务端会选择一个客户端提议的方式，使用并在响应头 Content-Encoding 中通知客户端该选择。 from MDN

好！大差不差，我们看看它接受的值有哪些:

Accept-Encoding: gzip
Accept-Encoding: gzip, compress, br,identity
Accept-Encoding: br;q=1.0, gzip;q=0.8, *;q=0.1

gzip，compress，deflate，br 都表示某些压缩算法（~~好想展开，~~ 但是抑制住了）
;q= 权重我们知道了
* 的意思是匹配其他任意未在该请求头字段中列出的编码方式。假如该请求头字段不存在的话，这个值是默认值。它并不代表任意算法都支持，而仅仅表示算法之间无优先次序。
identity：用于指代自身（例如：未经过压缩和修改）。除非特别指明，这个标记始终可以被接受。

只要 identity —— 表示不需要进行任何编码——没有被明确禁止使用（通过 identity;q=0 指令或是 *;q=0 而没有为 identity 明确指定权重值），则服务器禁止返回表示客户端错误的 406 Not Acceptable 响应。

看到这里你是不是以为压缩就是编码？但是我要告诉你，压缩只是编码的一种方式。

首先，为什么要编码呢？是因为我们不想未授权的其他人看到我们的内容。
其次，编码这个过程是如何进行的呢？浏览器会对内容（也就是body部分）进行编码。
那么，为什么选择了压缩这种形式呢？很简单，为了提高收发效率，而且压缩算法很 diao 的，不觉得吗？

好，让我们看看 accept-language。

accept-language

有了上一部分的经验，我们直接先对它做个一句话概括：浏览器告知服务器自己可以理解的语言？验证一下：

Accept-Language 请求头允许客户端声明它可以理解的自然语言，以及优先选择的区域方言。借助内容协商机制，服务器可以从诸多备选项中选择一项进行应用，并使用 Content-Language 应答头通知客户端它的选择。

OK，~~你已经掌握了如何理解HTTP头部字段了~~，看看语法

Accept-Language: <language>
Accept-Language: *

这里的 <language> 规则好新鲜也好合理：用含有两到三个字符的字符串表示的语言码或完整的语言标签。除了语言本身之外，还会包含其他方面的信息，显示在中划线（"-"）后面。最常见的额外信息是国家或地区变种（如"zh-CN"）或者表示所用的字母系统（如"sr-Lat"）。也接受通配符（表示发啥我就显示啥）和权重因子 ;q=

~~他真的好简单~~，因为我暂时只逛中英文网站，我有错。

最后浅浅了解一下，不发送也没事的 accept-charset

accept-charset

熟能生巧，这是一个送分题： __ __ __ _ , __ ****.

但是要注意一个细节，服务器使用 Content-Type 应答头通知客户端它的选择。浏览器通常不会设置此项值，因为每种内容类型的默认值通常都是正确的（目前每一种内容类型都有自己的默认字符集），但是发送它会更有利于识别。

例如我们例子中的类型为 document 的请求就没传这个字段，但是正确返回了下面的响应

request accept-charset.png

好，前面的区域，以后再来探索吧。

小结

本次我们了解到了http报文传输时，客户端的一些字段在传输的时候发挥了什么作用，它的值决定了它怎么发挥作用的。简单来说，在客户端这里，它会告诉服务器，”虽然我是个文盲，只能看得懂拼音，我用的纸是厕纸，笔是炭笔，但我用了字典里这个字后一位的编码方式“。~~好像是个间谍，~~ 真的很牛的哦。

拜拜，下次，我们将继续了解request header 的其他部分，是一个很经典的技术哦。

ps：我正在参与掘金技术社区创作者签约计划招募活动，点击链接报名投稿。