html表格乱码根源在于页面编码三要素不一致：文件实际编码、声明（须置于最前且无bom）、http响应头content-type: text/html; charset=utf-8，三者必须统一为utf-8无bom，表格中文才能正常显示。
HTML 表格本身不决定字符编码，乱码根源在整页的编码声明、文件保存格式和 HTTP 响应头三者是否一致。只要这三点对齐，<table> 里的中文自然正常显示。
<h3>meta charset 必须放在 最前面</h3>
<p>浏览器解析 HTML 时，前 1024 字节内遇到 <code><meta charset="UTF-8"> 才会切换解码器；如果它被 <title></title> 或注释挡在后面，前面的中文（包括表格标题、单元格文字）可能已按默认 ISO-8859-1 解错了。
-
<meta charset="UTF-8">必须是中第一个标签，前面不能有任何空格、换行、注释或<script></script> - 写成
<meta charset="utf-8">也有效，但推荐统一用大写UTF-8，避免某些旧版工具误判 - 不要混用
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">，HTML5 只认<meta charset>，后者更简洁且无歧义
文件实际编码必须是 UTF-8 无 BOM
编辑器里写了 <meta charset="UTF-8">，但文件物理上存成了 GBK 或带 BOM 的 UTF-8，浏览器照样解错——BOM 会干扰 <meta> 位置判断，GBK 字节流用 UTF-8 解就是一堆 。
- VS Code：保存时选
Save with Encoding → UTF-8（不是UTF-8 with BOM） - Notepad++：编码 → 转为 UTF-8（去掉“BOM”勾选）
- 验证方法：
xxd -l 3 index.html输出不含ef bb bf；或者用file -i index.html看是否显示charset=utf-8
HTTP 响应头 charset 不能覆盖 meta
当服务器返回 Content-Type: text/html; charset=GBK 时，Chrome/Firefox 会无视 <meta charset="UTF-8">，直接按 GBK 解析整页——表格内容当然乱码。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 本地双击打开
file://页面时，HTTP 头不存在，全靠<meta>和文件编码 - 线上环境务必检查 DevTools → Network → HTML 请求 → Response Headers →
Content-Type - Nginx 配置加
charset utf-8;；Apache 加AddDefaultCharset UTF-8；Express 用res.set('Content-Type', 'text/html; charset=UTF-8')
form accept-charset 不影响表格渲染，只管提交
表格里嵌了 <form></form>？accept-charset 属性只控制表单数据提交时的编码转换，和表格内容显示无关。它不会让 <td>张三</td> 变成乱码，也不会修复页面初始渲染问题。
- 除非后端明确要求 GBK 提交（极少见），否则不用设
accept-charset，默认继承页面编码 - 设了
accept-charset="GBK"却提交 UTF-8 字节，后端收到的仍是乱码，这不是前端能解决的 - 真正要调的是整个请求链路：前端文件编码 + meta 声明 + HTTP 头 + 后端接收逻辑
最容易被忽略的是文件实际编码和 HTTP 头的隐性冲突——改了 <meta> 却忘了重存文件，或部署后 Nginx 没配 charset，表格看着像好了，一提交就露馅。三者缺一不可。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
