requests默认支持gzip和deflate自动解压，但brotli需额外安装brotlipy或brotli包并手动注册解码器，否则Content-Encoding: br响应将保持压缩态，导致.text解码失败。
requests 默认能处理 gzip，但 brotli 需要额外安装和注册
Python 的 requests 库默认支持 gzip 和 deflate 压缩，收到 Content-Encoding: gzip 响应时会自动解压，你拿到的 response.text 或 response.content 已是明文。但 brotli 不在默认支持列表里——即使服务器返回 Content-Encoding: br，requests 也不会解压，而是原样返回压缩后的二进制数据，直接调用 .text 会报 UnicodeDecodeError。
解决方法很简单：
- 运行
pip install brotlipy（轻量、纯 Python，兼容性好）或pip install brotli（更快，但依赖编译） -
brotlipy会自动被requests检测并注册为br解码器；brotli包则需手动注册（见下一点） - 验证是否生效：打印
response.headers.get("Content-Encoding")，再检查len(response.content)是否明显小于原始响应头里的Content-Length（说明已解压）
手动注册 brotli 解码器（当用 brotli 而非 brotlipy 时）
如果你装的是 brotli（不是 brotlipy），它不会自动注入到 requests 的编码器链中。此时必须显式注册，否则仍会收到未解压的 br 数据。
在发起请求前加入这段代码：
立即学习“Python免费学习笔记（深入）”；
import requests
import brotli
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry
<h1>手动注册 br 解码器</h1><p>requests.utils.DEFAULT_ACCEPT_ENCODING += ", br"</p><div class="aritcle_card flexRow">
<div class="artcardd flexRow">
<a class="aritcle_card_img" href="/xiazai/skill11526" title="Python Hardener"><img
src="https://img.php.cn/upload/skill/001/246/273/6adaf20dbae7c507.jpg" alt="Python Hardener" ></a>
<div class="aritcle_card_info flexColumn">
<a href="/xiazai/skill11526" title="Python Hardener">Python Hardener</a>
<p>通过完整的安全审查、代码整洁重构、健壮的错误处理、正确的日志记录以及完整的文档字符串覆盖，强化 Python 脚本。</p>
</div>
<a href="/xiazai/skill11526" title="Python Hardener" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a>
</div>
</div><h1>然后注册解码逻辑（关键）</h1><p>def decode_brotli(data):
return brotli.decompress(data)</p><h1>替换 urllib3 的解码器映射（requests 2.25+ 推荐方式）</h1><p>from urllib3.response import HTTPResponse
HTTPResponse._decode_methods["br"] = decode_brotli
注意：brotli.decompress() 对空字节或已损坏的 br 数据会抛 brotli.Error，建议在外层加 try/except 包裹。
如何判断响应是否被正确解压？别只信 response.text
很多同学看到 response.text 能打印就以为解压成功，其实未必。常见陷阱：
- 服务器返回
Content-Encoding: gzip, br（多编码叠加）——requests只处理第一个（gzip），后面br被忽略，结果仍是压缩态 - 某些 CDN（如 Cloudflare）对小响应体不压缩，但 header 仍带
br，实际 body 未压缩，此时解压会失败 -
response.content是原始字节，response.text是解码后字符串；如果.text报错但.content长度很小（比如几十字节），大概率是未解压的压缩数据
稳妥做法是：先检查 response.headers.get("Content-Encoding")，再用 len(response.content) 对比响应头中的 Content-Length（若有），若两者接近，说明没解压；若 content 明显更大，则可能已解压或根本没压缩。
使用 httpx 替代 requests 可省去大部分麻烦
如果你可以切换 HTTP 客户端，httpx 对压缩的支持更现代、更透明：
- 默认支持
gzip、deflate、br（只要系统有对应模块，pip install httpx[all]会一并装brotli和zstandard） - 无需手动注册，
httpx.get(url).text在遇到br时自动解压 - 底层基于
httpcore，解码逻辑更清晰，错误提示也更明确（例如直接抛httpx.DecodingError）
不过要注意：httpx 默认是异步接口，同步用法要写 httpx.get(...)（不是 httpx.AsyncClient），且不兼容 requests.Session 的所有高级特性（如 mount adapter、retry 策略需重配）。
真正容易被忽略的是：压缩类型协商发生在请求头 Accept-Encoding，而很多爬虫会删掉它或设为空。务必保留默认值（或显式设为 "gzip, deflate, br"），否则服务器根本不会返回 br，你也无从处理。
