HTML5中唯一可靠支持的字符编码是UTF-8；非UTF-8编码需用<meta charset>声明且限前1024字节，但浏览器已基本不支持GBK等旧编码，混用会导致乱码或解析错误。
HTML5 中实际有效的字符编码声明方式只有 UTF-8
HTML5 规范明确要求：如果文档使用非 UTF-8 编码（如 GBK、GB2312、ISO-8859-1），必须通过 <meta charset> 声明，且该声明必须出现在文档前 1024 字节内；但浏览器对非 UTF-8 的支持已严重退化。现代实践中，UTF-8 是唯一被完整、可靠支持的编码。
常见误区是以为 <meta http-equiv="Content-Type" content="text/html; charset=GBK"> 还能生效 —— 实际上，这种旧式写法在 HTML5 中已被废弃，且多数浏览器（尤其是 Chrome/Firefox/Edge）会忽略它，转而依赖 BOM 或 HTTP 头。若 HTTP 头中 Content-Type 指定为 charset=GBK，而 HTML 内容实际是 UTF-8 编码，就会直接乱码，且无明确错误提示。
UTF-8 与 GBK 在解析时的核心差异
本质不是“解析逻辑不同”，而是字节流与字符映射关系错位导致的解码失败：
-
UTF-8是变长编码，中文通常占 3 字节；GBK是双字节编码，中文固定占 2 字节 - 若用
GBK解码器去读 UTF-8 字节流，会把一个中文字符的 3 字节拆成“1+2”或“2+1”，结果是出现或乱码（如浣犲ソ） - 若用
UTF-8解码器读GBK字节流，会把两个 GBK 字节误判为不合法 UTF-8 序列，同样报错或替换为 - XML 解析器（如浏览器内置 DOMParser 或 Python 的
xml.etree.ElementTree）默认只接受 UTF-8 或带 BOM 的 UTF-16；若传入 GBK 编码的 XML 字符串，会直接抛UnicodeDecodeError或DOMException: InvalidCharacterError
如何安全处理含中文的 HTML5 / XML 文档
关键原则：源头统一为 UTF-8，杜绝混用。具体操作：
立即学习“前端免费学习笔记（深入）”；
- 保存文件时，编辑器必须选
UTF-8 without BOM（BOM 在 HTML5 中不推荐，可能干扰脚本执行） - HTTP 服务端必须返回准确的
Content-Type: text/html; charset=utf-8（Nginx/Apache/Node.js 都需配置） - XML 文档开头若含声明，必须写成
<?xml version="1.0" encoding="UTF-8"?>—— 注意这里encoding值仅作提示，实际解码仍以传输层为准 - 用 JavaScript 动态加载 XML 时，避免用
XMLHttpRequest.responseType = 'text'后手动转码；应设为'document'，由浏览器自动按编码解析 - Python 读取本地 XML 文件时，显式指定编码：
tree = ET.parse('file.xml', parser=ET.XMLParser(encoding='utf-8'))，否则默认用系统 locale（Windows 上常是GBK，必出错）
遇到乱码时最有效的排查顺序
不要猜编码，要验证字节：
- 用
xxd file.html | head -c 32（Linux/macOS）或 VS Code 的 “Hex Editor” 扩展，看开头是否有ef bb bf（UTF-8 BOM）或ff fe（UTF-16 LE） - 检查响应头：
curl -I https://example.com/page.html，确认Content-Type中的charset是否存在且匹配 - 在浏览器开发者工具的 Network → Headers → Response Headers 中，比对
Content-Type和 Preview 标签页显示效果是否一致 - 若后端是 Node.js，检查
res.setHeader('Content-Type', 'text/html; charset=utf-8')是否被覆盖（例如 Express 默认不设 charset，需手动加）
真正棘手的永远不是“该用什么编码”，而是 HTTP 头、文件存储、编辑器设置、XML 声明四者不一致 —— 其中任意一个脱节，都会让浏览器或解析器陷入自相矛盾的解码逻辑。
