python requests 乱码 ��“��`�Fj��#d��{_��s%x� “accept-encoding“: “gzip, deflate, br“

python requests 乱码 ��"��`�Fj��#d��{_��s%x� 问题

感谢 CSDN 阿文 ID：CSDNnews

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

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

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

Accept: application/json Accept-Encoding: gzip, deflate, br Accept-Language: zh-CN,zh;q=0.9,en;q=0.8 Authorization: Bearer XXXX Cache-Control: no- cache Connection: keep-alive Content- Length: 21 Content- Type: application/ json;charset=UTF-8 Cookie: XXXX DNT: 1 Host: techs.qima-inc.com Origin: https://XXXX Pragma: no- cache Referer: https://XXXX Sec- Fetch-Dest: empty Sec- Fetch- Mode: cors Sec- Fetch-Site: same-origin User- 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) ifresponse.status_code != 200: return1resp_json = response.json

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

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

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

� �ϵ|e;Q-�,��*��,C�D�� 'P�Ȫ�l��4Jަ6E��[��bP�Hdd��F��-)�1äj�ӼRX4�~�A��p�Wmo�D��0�

‍经过排查，发现是'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' 编码，如果是，则进行解码

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

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