一个 Accept-Encoding 引发的 requests 爬虫乱码问题

作者 | 阿文

出品 | CSDN（ID：CSDNnews）

头图 | CSDN 下载自东方IC

最近在写一个内部的 RPA 项目，由于需要模拟请求一些网页的接口，拿到数据，但是发现通过 Python 的 requests 库 模拟请求 response 返回的数据是乱码的。使用 requests 无法通过 repsonse.json() 拿到 JSON 返回值，而浏览器返回以及 Postman 调试却是正常的。

来看下请求信息，请求头是这样的

Accept: application/jsonAccept-Encoding: gzip, deflate, brAccept-Language: zh-CN,zh;q=0.9,en;q=0.8Authorization: Bearer XXXXCache-Control: no-cacheConnection: keep-aliveContent-Length: 21Content-Type: application/json;charset=UTF-8Cookie: XXXXDNT: 1Host: techs.qima-inc.comOrigin: https://XXXXPragma: no-cacheReferer: https://XXXXSec-Fetch-Dest: emptySec-Fetch-Mode: corsSec-Fetch-Site: same-originUser-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.135 Safari/537.36

requests 去请求代码，由于希望模拟的更像一点，我直接把浏览器的请求信息全部拿过来了

headers = {'Accept': 'application/json','Accept-Encoding': 'gzip, deflate, br','Accept-Language': 'zh-CN,zh;q=0.9,en;q=0.8','Cache-Control': 'no-cache','Connection': 'keep-alive','Content-Type': 'application/json;charset=UTF-8','DNT': '1','Host': 'xxx','Origin': 'https://xxx','Pragma': 'no-cache','Referer': 'https://xxx','Sec-Fetch-Dest': 'empty','Sec-Fetch-Mode': 'cors','Authorization': "Bearer {}".format(self.request_session.cookies.get("TOKEN")),'Sec-Fetch-Site': 'same-origin','User-Agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) ''AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.111 Safari/537.36'}
response = self.request_session.put(url, headers=headers, json=payload)if response.status_code != 200:return 1resp_json = response.json()

正常预期下 resp_json 会返回一段 json 格式的数据，而我却得到的是

json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)

这说明无法解析json内容，我们将response 打印看看,如下所示，一堆乱码

|e;Q-,*,CD'Pl4J6E[bPHddF-)1jRX4~ApWmoD0

经过排查，发现是'Accept-Encoding' 的问题，我们直接把这个头去掉,发现可以正常返回数据了

{"code":0,"msg":null,"data":"[……}

这是为啥？事实上，在网页请求的时候，为了减少网页请求所消耗的带宽，提高数据传输的速度，通常会把数据进行压缩传输，这里就需要用到'Accept-Encoding'，它的值'gzip, deflate, br'，这里的值代表的意思是数据压缩采用的编码方式。通常我们还需要关注一个值，那就是响应头里面的'Content-Encoding'。

'Content-Encoding'是指服务端使用了哪种压缩方式传输数据给你，'Accept-Encoding'表示你发送请求时告诉服务器，我可以使用哪些编码解压缩你返回的数据。

服务端会根据你发送的'Accept-encoding'来决定用什么格式'Content-Encoding'压缩数据传输。

在 requests 中我们可以使用下面的方法打印该请求头

>>> response.request.headers["Accept-Encoding"]gzip, deflate, br

同时输出下服务端响应的压缩

>>> r.headers['Content-Encoding']'br'

发现服务端给我们返回的是通过 'br' 进行解码数据，但是很遗憾，'requets' 库支持 'gzip' 压缩和 'deflate' 压缩类型，但是不支持'br'。所以问题的点就出在了这里。

这里的 'br '是指 Brotli，它是 Google 推出的一款通用无损压缩算法，高压缩且性能快的编码方式，使用brotli取代[deflate](https://zh.wikipedia.org/wiki/DEFLATE)来对[文本文件](https://zh.wikipedia.org/wiki/文本文件)压缩通常可以增加20%的压缩密度，而压缩与解压缩速度则大致不变，项目地址见 https://github.com/google/brotli

所以我们发现了问题根源，解决方案有2种，一种是本地请求去掉 'br' 编码。另外一种就是本地获取到数据使用 'br'编码进行解码，下面重点说下第二种，其实也很简单：

1.首先，我们需要安装 Brotli

pip3 install Brotli

2.然后先获取到 'Content-Encoding' 判断是否是 'br' 编码，如果是，则进行解码

if response.headers["Content-Encoding"] == 'br':resp_json = brotli.decompress(response.content)

这样就可以完美的解决问题。