我们在获取网页源码并解析它的时候,如果在源码上看到Accept-Encoding 是 gzip
。
这表明,网页对我们接收到的源码进行了压缩打包,在发送网页内容到我们的客户端之前,对其进行压缩。
具体Gzip的处理原理如下:
Gzip是一种广泛使用的压缩算法和文件格式。客户端(如浏览器)接收到压缩后的内容,并在本地解压缩以显示网页。这个过程可以显著减少网页的加载时间(因为它可以压缩网络传输的数据量),特别是在网络带宽较低的情况下。
从而提高网页加载速度,和降低服务器的带宽消耗。
在HTTP协议中,客户端可以通过设置Accept-Encoding
头部来告知服务器它支持的压缩格式,如gzip, deflate
等。服务器将会根据这个信息决定是否启用GZIP压缩。
同样,服务器在响应中会通过Content-Encoding
头部告知客户端数据已被压缩,以便客户端进行解压。
有时候,如果我们在使用urllib.request 或者urllib3 .request的 响应response.read()的时候,就会返回奇怪的编码,输出的内容为【字节流】,而非字符串。给我们解析网页源码增加麻烦。
这个时候,网页的review上有数据,但是我们响应返回的内容没有有效信息。
这是因为在headers 上缺少了'Accept-Encoding': 'gzip, deflate'
这个参数,
解决方法如下:
-
检查网页源码的
Content-Encoding
响应头,如果值为gzip
,说明服务器返回的数据是GZIP压缩的。 -
在请求头中添加
Accept-Encoding: gzip
,告诉服务器客户端支持GZIP压缩。解决方法:在header上新增参数。
(有时候,我们在网页上看到源码有数据,但是如果没有在响应头加上’Accept-Encoding’,返回的内容会不显示完整的源码内容)
headers = {
,'Host': 'www.XXX.cn'
,'Accept-Encoding': 'gzip, deflate'#需要找到对应的网页上能接受的编码格式
,'Origin': 'www.XXX.cn'
,'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.51 Safari/537.36'
}
-
如果上面的方法不成,可能是网页设置了压缩格式,可以这样解决:
-
有可能我们遇到的不是压缩问题,而是解码问题的时候,例如以下的这种错误,就用
decode('utf_8')
的方法:
‘gbk’ codec can’t decode byte 0x8b in position 1: illegal multibyte
sequence
- 上面的方法是对应 urllib 和urllib3的request请求的。如果是使用
requests
,它会自动解压。也可以改为使用requests
方法,来获取响应试一试!