lxml解析html时遇非法unicode字符会报错，因libxml2在字节流解码阶段校验失败；recover=true仅修复html语法错误，不处理unicode编码问题，需提前确保输入为bytes并指定编码或清洗str中的非法字符。
lxml解析HTML时遇到非法Unicode字符会直接报错
默认情况下，lxml.html.fromstring() 遇到无法解码的字节（比如 UTF-8 中截断的代理对、0x00–0x08 控制字符、未配对的 UTF-16 代理项）会抛 UnicodeDecodeError 或 ParserError。这不是 HTML 规范问题，而是底层 libxml2 在读取原始字节流时的编码校验失败。
常见触发场景：
- HTTP 响应体被错误地用
gbk解码成字符串后再喂给fromstring() - 爬虫抓取的页面混入了 Windows-1252 编码的乱码字节（如
\x96、\x97） - 用户提交的表单字段含剪贴板带入的零宽空格（
\u200b）或 BOM（\ufeff），且未清洗就拼进 HTML 字符串
recover=True 不能修复 Unicode 编码错误，只能修标签结构
recover=True 是 HTMLParser 的开关，它只作用于**语法层面的 HTML 错误**：比如 <div>
<p>hello 缺少闭合标签、<code><img src="a.jpg"> 错误闭合。它不触碰字节解码环节——也就是说，如果输入已经是 Python str，但里面含非法 Unicode 码点（如孤立的高代理项 \ud800），recover=True 完全无效，照样抛 ValueError: All strings must be XML compatible。
真正要处理非法 Unicode，得在调用 fromstring() 前做两件事：
- 确保输入是
bytes类型，并显式指定编码（如fromstring(html_bytes, parser=HTMLParser(recover=True))） - 若必须用
str输入，先用html.escape()或正则过滤掉[\x00-\x08\x0b\x0c\x0e-\x1f]和未配对代理项（re.sub(r'[\ud800-\udbff](?![\udc00-\udfff])|(?）
W3C 验证器对 Unicode 路径的“误报”源于 Java 的 UTF-16 实现缺陷
像 <img src="/?>%20%E8%A2%AB%20W3C%20%E9%AA%8C%E8%AF%81%E5%99%A8%E6%A0%87%E4%B8%BA%20Illegal%20character%20in%20path%20segment%EF%BC%8C%E4%B8%8D%E6%98%AF%20HTML%20%E6%A0%87%E5%87%86%E7%A6%81%E6%AD%A2%E8%AF%A5%E5%AD%97%E7%AC%A6%EF%BC%8C%E8%80%8C%E6%98%AF%E9%AA%8C%E8%AF%81%E5%99%A8%E5%BA%95%E5%B1%82%20Java%20%E5%BA%93%EF%BC%88galimatias%EF%BC%89%E5%9C%A8%E8%AE%A1%E7%AE%97%E5%AD%97%E7%AC%A6%E4%B8%B2%E7%B4%A2%E5%BC%95%E6%97%B6%EF%BC%8C%E6%8A%8A%E5%A2%9E%E8%A1%A5%E5%AD%97%E7%AC%A6%EF%BC%88%E5%A6%82%20?%EF%BC%8CU+1F308%EF%BC%89%E5%BD%93%E6%88%90%E4%B8%A4%E4%B8%AA%20char%20%E5%A4%84%E7%90%86%EF%BC%8C%E5%AF%BC%E8%87%B4%E8%B7%AF%E5%BE%84%E8%A7%A3%E6%9E%90%E5%99%A8%E5%9C%A8%20/?%20%E8%BF%99%E7%A7%8D%E6%9E%81%E7%9F%AD%E8%B7%AF%E5%BE%84%E4%B8%AD%E9%94%99%E8%AF%AF%E9%80%92%E5%87%8F%E7%B4%A2%E5%BC%95%EF%BC%8C%E6%8A%8A%E9%97%AE%E5%8F%B7%E5%BD%93%E4%BD%9C%E9%9D%9E%E6%B3%95%E5%88%86%E9%9A%94%E7%AC%A6%E3%80%82BMP%20%E5%AD%97%E7%AC%A6%EF%BC%88%E5%A6%82%20%E2%AD%90%EF%BC%8CU+2B50%EF%BC%89%E5%8D%95%20char%20%E8%A1%A8%E7%A4%BA%EF%BC%8C%E5%8F%8D%E8%80%8C%E9%80%83%E8%BF%87%E6%AD%A4%20bug%E3%80%82
%E8%BF%99%E6%84%8F%E5%91%B3%E7%9D%80%EF%BC%9A
%0A- %0A
- %E4%BD%A0%E7%9A%84%20HTML%20%E5%AE%9E%E9%99%85%E5%8F%AF%E5%AE%89%E5%85%A8%E4%BD%BF%E7%94%A8%20
/?%EF%BC%8C%E6%B5%8F%E8%A7%88%E5%99%A8%E5%AE%8C%E5%85%A8%E6%94%AF%E6%8C%81 %0A - %E8%AF%A5%E9%94%99%E8%AF%AF%E5%B7%B2%E5%9C%A8%E6%96%B0%E7%89%88%20galimatias%20%E4%B8%AD%E4%BF%AE%E5%A4%8D%EF%BC%8C%E4%BD%86%E6%97%A7%E7%89%88%E9%AA%8C%E8%AF%81%E5%99%A8%E4%BB%8D%E5%B9%BF%E6%B3%9B%E9%83%A8%E7%BD%B2 %0A
- %E4%B8%8D%E8%A6%81%E5%9B%A0%E9%AA%8C%E8%AF%81%E5%99%A8%E6%8A%A5%E8%BF%99%E4%B8%AA%E9%94%99%E5%B0%B1%E8%BD%AC%E4%B9%89%E8%B7%AF%E5%BE%84%E2%80%94%E2%80%94
/%F0%9F%8C%88%20%E5%8F%8D%E8%80%8C%E5%8F%AF%E8%83%BD%E7%A0%B4%E5%9D%8F%20CDN%20%E7%BC%93%E5%AD%98%E6%88%96%E6%9C%8D%E5%8A%A1%E7%AB%AF%E8%B7%AF%E7%94%B1 %0A
meta%20charset=" utf-8>
</meta charset="UTF-8"> 不生效，90% 情况下不是写错了，而是被更底层的机制覆盖：
-
BOM 干扰：文件以
\xef\xbb\xbf开头，但<meta>前有空格或换行，导致浏览器忽略它（BOM 后第一个非空白字符必须是） -
HTTP header 优先级更高：Nginx/Apache 返回
Content-Type: text/html; charset=GBK，浏览器直接按 GBK 解码，<meta>被当作文本内容而非指令 -
JS/CSS 文件未同步编码：HTML 是 UTF-8，但内联
<script>alert("你好")</script>若被编辑器存为 GBK，JS 引擎解析时就会卡在第一个中文字符上，报Invalid or unexpected token
最稳的排查顺序：用 curl -I 看响应头 → 用 xxd -l 8 your.html 确认 BOM → 在 Chrome DevTools 的 Network 标签下检查实际解码结果。任何一环不一致，<meta charset> 都只是摆设。
