从python爬虫引发出的gzip,deflate,sdch,br压缩算法分析

今天在使用python爬虫时遇到一个奇怪的问题,使用的是自带的urllib库，在解析网页时获取到的为b'\x1f\x8b\x08\x00\x00\x00\x00...等十六进制数字，尝试使用chardet来检查编码格式时发现encoding为None,因为以前一直用的是requests库，所以没有仔细注意过这个问题，经过详细搜索后分析如下（下面代码是修改后加入gzip的）：

转载注明http://www.cnblogs.com/RainLa/p/8057367.html 

一.HTTP 内容协商

有时候，同一个 URL 可以提供多份不同的文档，这就要求服务端和客户端之间有一个选择最合适版本的机制，这就是内容协商

HTTP 的内容协商的其中一种方式：服务端根据客户端发送的请求头中某些字段自动发送最合适的版本。可以用于这个机制的请求头字段又分两种：内容协商专用字段（Accept 字段）、其他字段

字段情况，详见下表：

请求头字段	说明	响应头字段
Accept	告知服务器发送何种媒体类型	Content-Type
Accept-Language	告知服务器发送何种语言	Content-Language
Accept-Charset	告知服务器发送何种字符集	Content-Type
Accept-Encoding	告知服务器采用何种压缩方式	Content-Encoding

例如客户端发送以下请求头：

Accept-Encoding:gzip,deflate,br

表示支持采用 gzip、deflate 或 br 压缩过的资源

浏览器的响应头可能是这样的：

Content-Encoding: gzip

二.服务器返回response-header中Content-Encoding:gzip

　可以发现是服务器使用了压缩算法，而且压缩算法为gzip，而且gzip压缩算法的特点是以1f8b开头，具体字节顺序分析为（下面解释摘抄自http://blog.csdn.net/jison_r_wang/article/details/52068962，本人实际测试过，都对应的上，不过原作者解释的很好，所以直接摘抄过来）

 

0000 0000h, 0~1，开始的两个字节是标识符1F8B；

0000 0000h, 2，CM (Compression Method)，压缩方式，08表示deflate算法；

0000 0000h, 3，FLG (FLaGs)，标志位，十六进制08，即二进制0000 1000，从右往左分别是bit0~bit7，现在bit3置位，对应FNAME，即该gzip头后面的扩展部分是带着原始文件名的；

0000 0000h,4~7，这四个字节是时间，分别是十六进制“38 DA 71 57”，这是存储的顺序，我们转换成人们正常读取的顺序“57 71 DA 38”，将其转换成时间，先把5771DA38转换成十进制即1467079224，转换为时间为2016/6/28 10:0:24

0000 0000h, 8，XFL (eXtra FLags)，十六进制02，这个地方我也有点糊涂，但我估计应该是用的XFL = 4 - compressorused fastest algorithm；

0000 0000h, 9，00，即0 - FAT filesystem (MS-DOS, OS/2,NT/Win32)，我用的是win7，也是对应的。

0000 0000h, a~00000010h, 1，共8个字节，存储的是原始文件的文件名“abc.txt”，末尾还有个'\0'表示结束，从这里可以看出，这个文件名只是个文件名，没携带路径信息。从这里往后，就是实际的压缩数据信息了；

0000 0030h, b~e，这四个字节是CRC32校验码，分别是十六进制“45 2D F1 80”，这是存储的顺序，我们转换成人们正常读取的顺序“80 F1 2D 45”，原文件内容为“abcabcabcdeabcdefghijklmnopqrstopqrstuvvvvabcabcabcdeabcdefghijklmnopqrstuv”，使用CRC计算器算得结果如下图所示