meta charset不生效主因是HTTP响应头覆盖、未置于开头1024字节内、文件实际编码非UTF-8（如含BOM或为GBK），或浏览器未读取到该标签；需优先检查Response Headers中content-type及文件真实编码。
meta charset 不生效，基本可以断定是编码设置被覆盖、忽略或根本没被读到——不是标签写错了，而是它压根没起作用。
为什么 meta charset 写了却还是乱码
浏览器只在找不到更权威的编码声明时，才 fallback 到 meta charset。它既不是最高优先级，也不是“写了就一定管用”的开关。
- HTTP 响应头里的
Content-Type有charset字段（比如text/html; charset=gbk），会直接覆盖meta标签，哪怕你写了UTF-8也没用 -
meta charset没放在开头 1024 字节内，某些老浏览器（尤其是 IE）会直接跳过 -
前存在 BOM（EF BB BF）、空格、换行、注释或<script></script>，都可能导致解析器提前终止 charset 检测 - 文件本身不是 UTF-8 编码，而是保存成了
UTF-8 with BOM或GBK，那meta标签里的UTF-8就是自欺欺人
怎么确认当前生效的是哪个编码
别猜，直接看 DevTools：
DeepBI DHTML 页面生成器
下载
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 打开 Chrome / Edge，F12 → Network → 刷新页面 → 找到 HTML 请求 → 点开 → Headers → 查看
Response Headers下的content-type - 如果值是
text/html; charset=iso-8859-1或gbk，说明服务器强制指定了编码，meta已被无视 - 如果
content-type里压根没charset，再去看Response Payload开头几百字节，确认有没有<meta charset="UTF-8">且位置正确 - Linux/macOS 下用
file -i index.html，Windows 下用Get-Content index.html -Encoding Byte | Select -First 3，检查是否含 BOM（ef bb bf）
服务端响应头比 meta 更优先
HTTP 头是第一道关卡，meta 是兜底手段。只要服务端发出了带 charset 的 Content-Type，浏览器就不会再看 meta。
立即学习“前端免费学习笔记（深入）”；
- Apache：
.htaccess里加AddDefaultCharset UTF-8；或者配置中关闭其他 charset 设置 - Nginx：server 或 location 块里写
charset utf-8;，**不要**写charset gbk;，也别漏掉分号 - Express（Node.js）：用
res.set('Content-Type', 'text/html; charset=utf-8')，必须在res.send()或res.sendFile()之前调用 - PHP：在输出任何 HTML 前调用
header('Content-Type: text/html; charset=utf-8');，且确保文件本身没 BOM（否则header()会报错）
本地双击打开（file://）时只能靠 meta
没有 HTTP 头，file:// 协议下浏览器完全依赖 meta charset 和文件自身编码。这时候出乱码，90% 是文件保存出了问题。
- VS Code 保存时选 “Save with Encoding” → “UTF-8”（**不是** “UTF-8 with BOM”）
- Sublime Text / Notepad++ 同样选纯 UTF-8，状态栏应显示 “UTF-8”，而非 “UTF-8-BOM” 或 “UTF-8-SIG”
-
meta charset必须是里第一个有效标签，前面不能有任何字符（包括空格、
