requests-html 的 encoding 属性返回错误编码，因其优先用 w3lib.html_to_unicode 解析 HTML 字节流，若实际为 GBK 但被误按 UTF-8 解码，将产生乱码并反推错误编码（如 'utf-8'），导致 html.find() 失效；应检查 raw_html 字节特征，必要时强制 decode('gbk')。
requests-html 中 encoding 属性为什么返回错误编码
因为 requests-html 的 encoding 属性不是直接读取 response.encoding，而是先尝试用 w3lib.encoding.html_to_unicode() 解析 HTML 字节流，再 fallback 到 requests 自动检测结果。一旦 HTML 字节本身是 GBK 编码，但 <meta charset="UTF-8"> 又存在（声明与实际不符），html_to_unicode 就会强行按 UTF-8 解码 GBK 字节，产生乱码字符串，然后把这串乱码的“解码结果”当作有效文本反推编码，最终 encoding 返回一个看似合理实则错误的值（比如 'utf-8'）。
常见错误现象：html.html 显示为 "030809"，但 html.encoding 却是 'utf-8'；调用 html.find('h1') 返回空或错乱文本。
- 不要依赖
html.encoding的返回值做判断，它只是启发式推导，不是真相 - 优先检查
html.raw_html的原始字节 —— 用len(html.raw_html)和html.raw_html[:20]看前几个字节是否符合 UTF-8 编码特征（如中文通常以\xe4、\xe5开头） - 若原始字节明显是 GBK（如含
\xc4\xe3这类双字节序列），就该跳过html.text，直接用html.raw_html.decode('gbk')
强制指定 encoding 后仍乱码的三个关键点
显式设置 html.encoding = 'gbk' 或 response.encoding = 'gbk' 后还是乱码，大概率不是编码设错，而是字节流本身已被污染 —— 常见于文件保存时误加 BOM 或编辑器二次转码。
使用场景：爬取国内老网站（如政府旧站、校园网）、本地打开的 .html 文件、火狐导出的 bookmarks.html。
立即学习“前端免费学习笔记（深入）”；
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 用
file -i filename.html（Linux/macOS）或 PowerShell 的Get-Content filename.html -Encoding Byte | Select -First 3检查开头三字节：如果是239 187 191（即ef bb bf），说明有 UTF-8 BOM；如果是255 254，则是 UTF-16 LE BOM；都不是则大概率是纯 GBK/ANSI - VS Code 打开后右下角显示 “UTF-8 with BOM”，必须点它 → “Save with Encoding” → 选 “UTF-8”（不带 BOM）；Notepad++ 要选“转为 UTF-8”而非“UTF-8-BOM”
- 如果原始文件是 GBK，但你用 VS Code 默认以 UTF-8 打开并保存，它会把每个 GBK 双字节当两个 UTF-8 字符重写，彻底损坏 —— 此时只能用 Notepad++ “以 ANSI 编码打开”，再“转为 UTF-8”保存
chardet.detect() 返回 None 或 gb2312 怎么办
chardet.detect() 对短文本（{'encoding': None, 'confidence': 0.0} 或错误地判为 'gb2312'（其实它是 GBK 的子集，但 decode 时用 'gb2312' 会崩）。
性能影响：调用 chardet.detect() 是纯 CPU 密集型，对大页面延迟明显；cchardet 可提速 3–5 倍，但依然解决不了逻辑缺陷。
- 先试
'utf-8'，失败再试'gbk'，最后试'gb18030'（兼容性最强，能解几乎所有中文编码） - 用
try/except UnicodeDecodeError包裹，而不是依赖chardet结果 —— 实际工程中 90% 的中文网页就这两个编码来回切 - 避免在循环里反复调用
chardet.detect()；对同一批来源 URL，可缓存域名对应的编码策略（如gov.cn→'gbk'，github.io→'utf-8'）
HTML 文件本地打开时乱码的根源
用 file:// 协议打开 HTML 文件时，浏览器完全忽略 HTTP 响应头，只认 <meta charset> 和文件 BOM。但很多编辑器（尤其是 Windows 记事本）保存 UTF-8 时默认加 BOM，而 BOM 会卡在 前面，导致 <meta charset="UTF-8"> 实际位置超出浏览器扫描前 1024 字节范围，失效。
容易踩的坑：<meta charset> 写在 <title></title> 后面、注释之后、或前面有空行 —— 这些都会让浏览器错过它。
- 确保
<meta charset="UTF-8">是内第一个标签，前面不能有任何字符（包括空格、换行、BOM） - 用
xxd filename.html | head -n 5查看真实字节布局；若开头是ef bb bf，立刻删掉 BOM 再试 - 本地开发时，用 Python 快速起服务：
python3 -m http.server 8000，这样就能走 HTTP 协议，让Content-Type头生效，绕过所有 BOM 和 meta 位置问题
<meta charset> 位置冲突是本地 HTML 最隐蔽的乱码源头，比编码选错更难排查 —— 因为它让“明明写了 UTF-8 却还是乱码”这件事变得完全合理。 
