在Network面板中查看Response Headers的Content-Type字段，若为text/html且无charset=utf-8（注意必须小写、连字符），即为缺失；UTF8、utf8、UTF-8等均无效。
怎么看 Network 里 Response Headers 缺不缺 charset
打开 Chrome 或 Edge 的 DevTools，切到 Network 标签页，刷新页面，点开第一个 HTML 请求（通常是 index.html 或根路径），在右侧的 Response Headers 区域找 Content-Type 字段。如果值是 text/html 而没有 charset=utf-8，就属于缺失；如果写成 text/html; charset=gbk 或 text/html; charset=iso-8859-1，也属于错误设置。注意大小写：浏览器只认 utf-8（小写连字符），UTF8、utf8、UTF-8（大写 U）都不生效。
怎么验证 <meta charset="UTF-8"> 是否被真正读取
<meta charset="UTF-8"> 只有在 开头、且前 1024 字节内无干扰时才有效。常见失效原因包括：
- 文件开头有 BOM（
ef bb bf）——用xxd -l 8 index.html（Linux/macOS）或Get-Content index.html -Encoding Byte | Select -First 3（PowerShell）检查； -
<meta>前有空格、换行、注释或 BOM，比如：\n <!-- comment -->\n <meta charset="UTF-8">； - 写了
<meta charset="utf8">或<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">——后者是 HTML4 写法，HTML5 中与前者共存会引发解析冲突； - 服务端返回了
Content-Type: text/html; charset=gbk，此时<meta>完全被忽略。
怎么确认 HTML 文件本身是不是 UTF-8 编码
编辑器显示“UTF-8”不代表文件真是 UTF-8。VS Code 显示为 GBK 却写了 <meta charset="UTF-8">，页面必然乱码。验证方法：
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- Linux/macOS：
file -i index.html看输出中charset=后的值； - Windows PowerShell：
Get-Content index.html -Encoding Byte | Select -First 3，若输出239 187 191就是 UTF-8-BOM； - VS Code：右下角点击编码名称 → 选
Reopen with Encoding，分别试UTF-8、GBK、ISO-8859-1，看哪一种能正常显示中文； - 确认后务必点
Save with Encoding→ 选UTF-8（不要选UTF-8 with BOM，BOM 会破坏<meta>生效）。
为什么本地双击打开 HTML 就乱码，但服务器上正常
因为 file:// 协议下浏览器收不到 HTTP 响应头，只能依赖 <meta charset> 和系统 fallback。Windows 默认 fallback 是 GBK，Linux/macOS 是 ISO-8859-1。所以：
立即学习“前端免费学习笔记（深入）”；
- 本地测试必须确保文件是纯 UTF-8（无 BOM）、
<meta charset="UTF-8">在最前面； - 不能依赖
file://判断线上效果，必须走 HTTP 服务（如python3 -m http.server、Live Server 插件或 Nginx）； - Python 自带的
http.server默认发charset=iso-8859-1，要手动加响应头，否则即使文件和 meta 都对，也会乱码。
BOM 和 file:// 是最容易被跳过的两个点，改完 <meta> 还乱码？先查这两处。
