HTML表格乱码根源在于文档整体编码链断裂：meta charset未置于最前、文件非UTF-8无BOM、HTTP响应头charset不匹配三者任一失效，均导致中文显示为乱码或问号。
表格本身不决定编码，乱码根源在 HTML 文档整体的字符编码链断裂——meta charset位置错、文件实际编码不是 UTF-8 无 BOM、HTTP 响应头 charset 不匹配，三者任一出问题，<table>里的中文照样显示为或乱码。<h3>meta charset 必须是 的第一个子节点</h3>
<p>浏览器只扫描前 1024 字节找 <code>meta charset，一旦开头有 BOM（EF BB BF）、空行、注释（<!-- -->）、<script></script> 或全角空格，它就跳过这个标签，fallback 到系统默认编码（Windows 是 GBK，Linux/macOS 常是 ISO-8859-1）。
-
<meta charset="UTF-8"> <title>...</title>✅ 正确：紧贴开始，无前置内容 -
<title>...</title> <meta charset="UTF-8">❌ 失效：被<title></title>挤到第二位 -
<!-- 注释 --><meta charset="UTF-8">❌ 失效：注释占了前 1024 字节位置 -
<meta charset="utf-8">⚠️ 可用但不规范：W3C 推荐写"UTF-8"（带短横线、大写 U/T/F），部分 CI 工具或 WebView 会报 warning
HTML 文件必须是 UTF-8 无 BOM 编码
编辑器里“看起来正常”不等于文件编码正确。VS Code 显示“GBK”，你却保存为 GBK，浏览器按 UTF-8 解析，<td>你好</td> 就变成 ä½ å¥½。
- VS Code：右下角点编码 → “Reopen with Encoding” → 选
UTF-8（**不是 “UTF-8 with BOM”**）→ 再点 “Save with Encoding” → 选UTF-8 - Notepad++：菜单栏“编码” → “转为 UTF-8 编码”（**不勾选 BOM**）
- 命令行验证（Linux/macOS）：
xxd -l 3 index.html，输出不含ef bb bf才算干净；若有，用sed -i '1s/^\xEF\xBB\xBF//' index.html删除 - 别用 Windows 记事本直接改 HTML 模板——它默认保存为 ANSI（GBK），极易埋坑
HTTP 响应头 Content-Type 必须含 charset=utf-8
本地双击打开（file://）时，HTTP 头无效，全靠 meta；但只要走 http:// 或 https://，响应头优先级就高于 meta。如果服务器返回 Content-Type: text/html; charset=gbk，哪怕页面写了 UTF-8，Chrome 也会强制用 GBK 解码。
立即学习“前端免费学习笔记（深入）”；
- Chrome DevTools → Network → 刷新 → 点 HTML 请求 → Headers → Response Headers → 查
Content-Type是否为text/html; charset=utf-8 - Nginx 配置（server 或 location 块内）：
charset utf-8;（小写，分号不能少） - Apache
.htaccess：AddDefaultCharset UTF-8（注意大小写） - Express.js：
res.set('Content-Type', 'text/html; charset=utf-8')必须在res.send()或res.render()之前调用
真正容易被忽略的是模板引擎和外部资源：Thymeleaf 可能往 前注入注释，把 meta 挤到第二位；CSS/JS 文件若用 GBK 保存，也会污染整个页面解码逻辑。验证时得同时看 document.characterSet、Network 的响应头、以及 file -i your.html 的实际编码三者是否一致。
