今天就跟大家聊聊有关HTTP协议中需要知道的三种数据格式分别是什么，可能很多人都不太了解，为了让大家更加了解，小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。
实习中的一个主要工作就是分析 HTTP 中的协议，自己也用 Python 写过正则表达式对 HTTP 请求和响应的内容进行匹配，然后把关键字段抽离出来放到一个字典中以备使用(可以稍微改造一下就是一个爬虫工具)。
HTTP 协议中的很多坑，自己都遇到过，我就针对自己遇到的几种 HTTP 常见的数据格式，来做一个总结。
Zlib 压缩数据
对于 Zlib，一点也不陌生，我们平时用它来压缩文件，常见类型有 zip、rar 和 7z 等。Zlib 是一种流行的文件压缩算法，应用十分广泛，尤其是在 Linux 平台。当应用 Zlib 压缩到一个纯文本文件时，效果是非常明显的，大约可以减少70%以上的文件大小,这取决于文件中的内容。
Zlib 也适用于 Web 数据传输，比如利用 Apache 中的 Gzip (后面会提到，一种压缩算法) 模块，我们可以使用 Gzip 压缩算法来对 Apache 服务器发布的网页内容进行压缩后再传输到客户端浏览器。这样经过压缩后实际上降低了网络传输的字节数，最明显的好处就是可以加快网页加载的速度。
网页加载速度加快的好处不言而喻，节省流量，改善用户的浏览体验。而这些好处并不仅仅限于静态内容，PHP 动态页面和其他动态生成的内容均可以通过使用 Apache 压缩模块压缩，加上其他的性能调整机制和相应的服务器端 缓存规则，这可以大大提高网站的性能。因此，对于部署在 Linux 服务器上的 PHP 程序，在服务器支持的情况下，建议你开启使用 Gzip Web 压缩。
Gzip 压缩两种类型
压缩算法不同，可以产生不同的压缩数据(目的都是为了减小文件大小)。目前 Web 端流行的压缩格式有两种，分别是 Gzip 和 Defalte。
Apache 中的就是 Gzip 模块，Deflate 是同时使用了 LZ77 算法与哈夫曼编码(Huffman Coding)的一个无损数据压缩算法。Deflate 压缩与解压的源代码可以在自由、通用的压缩库 zlib 上找到。
更高压缩率的 Deflate 是 7-zip 所实现的。AdvanceCOMP 也使用这种实现，它可以对 gzip、PNG、MNG 以及 ZIP 文件进行压缩从而得到比 zlib 更小的文件大小。在 Ken Silverman的 KZIP 与 PNGOUT 中使用了一种更加高效同时要求更多用户输入的 Deflate 程序。
deflate 使用 inflateInit()，而 gzip 使用 inflateInit2() 进行初始化，比 inflateInit() 多一个参数: -MAX_WBITS，表示处理 raw deflate 数据。因为 gzip 数据中的 zlib 压缩数据块没有 zlib header 的两个字节。使用 inflateInit2 时要求 zlib 库忽略 zlib header。在 zlib 手册中要求 windowBits 为 8..15，但是实际上其它范围的数据有特殊作用，如负数表示 raw deflate。
其实说这么多，总结一句话，Deflate 是一种压缩算法,是 huffman 编码的一种加强。 deflate 与 gzip 解压的代码几乎相同，可以合成一块代码。
更多知识请见 维基百科 zlib。
Web 服务器处理数据压缩的过程
Web服务器接收到浏览器的HTTP请求后，检查浏览器是否支持HTTP压缩(Accept-Encoding 信息);
如果浏览器支持HTTP压缩，Web服务器检查请求文件的后缀名;
如果请求文件是HTML、CSS等静态文件，Web服务器到压缩缓冲目录中检查是否已经存在请求文件的***压缩文件;
如果请求文件的压缩文件不存在，Web服务器向浏览器返回未压缩的请求文件，并在压缩缓冲目录中存放请求文件的压缩文件;
如果请求文件的***压缩文件已经存在，则直接返回请求文件的压缩文件;
如果请求文件是动态文件，Web服务器动态压缩内容并返回浏览器，压缩内容不存放到压缩缓存目录中。
举个栗子
说了这么多，下面举一个例子，打开抓包软件，访问我们学校的官网( www.ecnu.edu.cn )，请求头如下:
GET /_css/tpl2/system.css HTTP/1.1 Host: www.ecnu.edu.cn Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.59 Safari/537.36 Accept: text/css,**;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://aram/~martind/banner.htm Content-Type: multipart/form-data; boundary=::287032381131322 Content-Length: 514 --::287032381131322 Content-Disposition: form-data; name="datafile1"; filename="r.gif" Content-Type: image/gif GIF87a.............,...........D..; --::287032381131322 Content-Disposition: form-data; name="datafile2"; filename="g.gif" Content-Type: image/gif GIF87a.............,...........D..; --::287032381131322 Content-Disposition: form-data; name="datafile3"; filename="b.gif" Content-Type: image/gif GIF87a.............,...........D..; --::287032381131322—http 协议本身的原始方法不支持 multipart/form-data 请求，那这个请求自然就是由这些原始的方法演变而来的，具体如何演变且看下文：
multipart/form-data 的基础方法是 post，也就是说是由 post 方法来组合实现的
multipart/form-data 与 post 方法的不同之处：请求头，请求体。
multipart/form-data 的请求头必须包含一个特殊的头信息：Content-Type，且其值也必须规定为 multipart/form-data，同时还需要规定一个内容分割符用于分割请求体中的多个 post 内容，如文件内容和文本内容自然需要分割，不然接收方就无法正常解析和还原这个文件。具体的头信息如：Content-Type: multipart/form-data; boundary=${bound}，${bound} 代表分割符，可以任意规定，但为了避免和正常文本重复，尽量使用复杂一点的内容，如::287032381131322
multipart/form-data 的请求体也是一个字符串，不过和 post 的请求体不同的是它的构造方式，post 是简单的 name=value 值连接，而 multipart/form-data 则是添加了分隔符等内容的构造体。
维基百科上关于 multipart 的介绍。
multipart 的数据格式有一定的特点，首先是头部规定了一个 ${bound}，上面那个例子中的 ${bound} 为 ::287032381131322，由多个内容相同的块组成，每个块的格式以--加 ${bound} 开始的，然后是该部分内容的描述信息，然后一个\r\n，然后是描述信息的具体内容。如果传送的内容是一个文件的话，那么还会包含文件名信息，以及文件内容的类型。
要发送一个 multipart/form-data 的请求，需要定义一个自己的 ${bound} ，按照格式来发请求就好，对于 multipart 的数据格式并没有过多介绍，感觉和 chunked 很类似，不难理解。
看完上述内容，你们对HTTP协议中需要知道的三种数据格式分别是什么有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注编程网行业资讯频道，感谢大家的支持。
