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 缺少闭合标签、<img src="a.jpg"></img> 错误闭合。它不触碰字节解码环节——也就是说，如果输入已经是 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="/?> 被 W3C 验证器标为 Illegal character in path segment，不是 HTML 标准禁止该字符，而是验证器底层 Java 库（galimatias）在计算字符串索引时，把增补字符（如 ?，U+1F308）当成两个 char 处理，导致路径解析器在 /? 这种极短路径中错误递减索引，把问号当作非法分隔符。BMP 字符（如 ⭐，U+2B50）单 char 表示，反而逃过此 bug。
这意味着：
- 你的 HTML 实际可安全使用
/?，浏览器完全支持 - 该错误已在新版 galimatias 中修复，但旧版验证器仍广泛部署
- 不要因验证器报这个错就转义路径——
/🌈反而可能破坏 CDN 缓存或服务端路由
meta charset="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> 都只是摆设。
