HTML中文乱码本质是字节流与字符映射失败，需确保文件实际编码、（须位于开头1024字节内且格式正确）、HTTP响应头Content-Type: text/html; charset=utf-8三者严格一致，任一不匹配即触发fallback至GBK等默认编码导致乱码。
HTML 中文乱码不是“页面坏了”，而是浏览器在字节流和字符之间翻译失败——charset 声明、文件实际编码、HTTP 响应头三者只要有一处不一致，就大概率出“”或“é”这类错译。
怎么确认 HTML 文件实际保存为 UTF-8？
编辑器显示“UTF-8”不等于文件真是 UTF-8。VS Code 默认保存为 UTF-8，但 Windows 下常默认存成 UTF-8 with BOM（BOM 是开头三个字节 ef bb bf），而 BOM 会干扰 <meta charset="UTF-8"> 的识别。
- Linux/macOS：运行
xxd -l 4 index.html，输出含ef bb bf就有 BOM；用file -i index.html看charset=utf-8才算实锤 - Windows PowerShell：运行
Get-Content index.html -Encoding Byte | Select -First 3，若前三字节是239 187 191，就是 BOM - VS Code：右下角点击编码名 → 选
Reopen with Encoding→ 试UTF-8和GBK，哪边中文正常哪边就是真实编码；再点Save with Encoding→ 强制选UTF-8（不要勾with BOM）
为什么 <meta charset="UTF-8"> 写了还是乱码？
这个标签只在 HTTP 响应头没指定 charset 时才生效，且浏览器只扫描 开头约 1024 字节内的第一个 <meta>。常见失效场景：
-
<meta charset="UTF-8">写在之后，或前面有空行/BOM/注释/非 ASCII 字符（比如中文注释） - 写了
<meta charset="utf8">或<meta charset="UTF8">—— 只有utf-8（带短横、小写）是标准值 - 服务端返回了
Content-Type: text/html; charset=gbk，此时<meta>完全被忽略 - 用
file://直接打开 HTML，没有 HTTP 头，只能靠<meta>，但若文件实际是 GBK 编码，<meta>就成了“用 UTF-8 解释 GBK 字节”，必然乱码
如何验证 HTTP 响应头的 charset 是否生效？
这是优先级最高的编码来源，必须用 DevTools Network 面板实测，不能只信配置文件。
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
立即学习“前端免费学习笔记（深入）”；
- 在 Chrome / Edge 中按
F12→ 切到Network→ 刷新页面 → 点击左侧第一个document类型请求 → 右侧看Response Headers→ 找Content-Type字段 - 值必须是
text/html; charset=utf-8（注意小写、短横、无空格），不是gbk、iso-8859-1，也不能缺失charset=部分 - Nginx 配置要写在
http、server或location块里：charset utf-8;（结尾分号不能少） - Apache 要在
.htaccess或虚拟主机配置中加：AddDefaultCharset UTF-8 - Node.js（如 Express）需显式设置：
res.set('Content-Type', 'text/html; charset=utf-8')
哪些地方容易漏掉 UTF-8 统一？
乱码常来自“周边环节”没对齐，而非主 HTML 文件本身：
- CSS/JS 文件也要声明
charset=utf-8：外部 CSS 用<link rel="stylesheet" href="a.css" charset="utf-8">（虽现代浏览器默认继承 HTML，但稳妥起见可加） - AJAX 返回的 JSON 接口，响应头也得是
Content-Type: application/json; charset=utf-8，否则中文字段可能变\u4f60\u597d或直接乱码 - 模板引擎（如 EJS、Thymeleaf）生成 HTML 时，确保模板文件本身是 UTF-8 编码，且引擎未强制转义或覆盖 charset
- GitHub Pages、Vercel 等托管平台默认用 UTF-8，但若上传了带 BOM 的文件，某些旧版微信内置浏览器会误判为非标准 UTF-8，导致
<meta>失效
BOM 是最隐蔽的坑：它让文件“看起来是 UTF-8”，却让浏览器跳过 <meta>，直接 fallback 到系统默认编码（Windows 是 GBK）。删 BOM 不仅解决乱码，还能避免 Webpack/Vite 构建时报 Invalid character。
