HTML中文乱码主因有三：文件编码非UTF-8（应保存为UTF-8无BOM）、缺少或错放标签（须置于最前）、服务器Content-Type响应头覆盖声明（如Nginx需配置add_header）。
HTML 文件保存编码不是 UTF-8
浏览器默认按 UTF-8 解析网页，但如果你用记事本、VS Code 或其他编辑器保存时选了 GBK、ANSI 或 UTF-8 with BOM（尤其 Windows 记事本默认带 BOM），中文就会显示为方块或乱码。
实操建议：
- 用 VS Code 打开 HTML 文件，右下角看当前编码（如显示
GBK），点击它 → 选择Save with Encoding→ 选UTF-8（不带 BOM） - Sublime Text：菜单
File → Save with Encoding → UTF-8 - 确认文件头没多余字符：用十六进制编辑器或命令行
head -c 10 filename.html | xxd检查开头是否含EF BB BF（BOM），有就删掉再存
标签缺失或写错位置
即使文件是 UTF-8 编码，浏览器也可能因缺少声明而 fallback 到系统默认编码（比如 Windows 上是 GBK），导致乱码。这个标签必须放在 最前面，且不能晚于前 1024 字节。
常见错误现象：
立即学习“前端免费学习笔记（深入）”；
- 写了
<meta charset="utf8">—— 错，正确是UTF-8（带短横线） - 把
<meta>放在<title></title>后面，或嵌在<script></script>里 - 用了旧写法
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">，虽兼容但冗余，优先用新写法
正确写法只有一行，且紧贴 开始：
<head> <meta charset="UTF-8"> <title>页面标题</title> </head>
Web 服务器返回的 Content-Type 响应头覆盖了 meta 标签
本地双击打开 HTML 文件（file:// 协议）时，浏览器只看 <meta charset>；但通过 http:// 访问时，服务器返回的 Content-Type 响应头（如 text/html; charset=gbk）优先级更高，会直接覆盖 HTML 里的声明。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
检查方法：
- 浏览器按
F12→Network→ 刷新页面 → 点 HTML 请求 → 查看Response Headers中的Content-Type - 如果是 Python 的
http.server、PHP 内置服务器或某些老旧 Nginx 配置，可能默认设成charset=iso-8859-1
修复方向：
- Nginx：在
location块加add_header Content-Type "text/html; charset=utf-8";（注意别重复设置） - Apache：确保
AddDefaultCharset UTF-8在配置中启用 - Node.js/Express：响应前加
res.set("Content-Type", "text/html; charset=utf-8")
字体缺失导致中文显示为空心/方框，不是真乱码
有时候文字能正常解析（右键“查看网页源代码”可见中文），但页面上显示为小方块或空心字，这是字体问题，不是编码问题。
原因和应对：
- CSS 中
font-family指定了英文优先字体（如"Helvetica", "Arial"），而系统没装对应中文字体，浏览器 fallback 失败 - 解决办法：在 CSS 中显式指定中文字体，例如
font-family: "PingFang SC", "Microsoft YaHei", sans-serif; - 注意 Mac 和 Windows 默认中文字体名不同，用逗号分隔多个候选，最后保留
sans-serif保底
这种情况下，charset 和服务器头都对，但用户就是看不到中文——得去查渲染链路，而不是改编码。
真正容易被忽略的是：同一个 HTML 文件，在本地双击打开没问题，一放到服务器就乱码，十有八九是服务器响应头或反向代理层（比如 Nginx + CDN）悄悄改了 Content-Type，而不是文件本身的问题。
