HTML文件实际编码需通过命令行工具验证：Linux/macOS用file -i查声明、xxd看BOM（ef bb bf）；Windows用PowerShell查字节（239 187 191为BOM）；Sublime可试不同编码重开。编辑器右下角显示仅为当前解读方式，不等于真实字节。
怎么确认 HTML 文件实际保存的编码
编辑器右下角显示的“UTF-8”只是当前打开方式，不代表文件真实字节。VS Code、Sublime 或 Notepad++ 都可能用 UTF-8 解码一个实际是 GBK 的文件，看起来正常，但一提交或部署就乱码。
- Linux/macOS 下用
file -i index.html查声明，再用head -c 4 index.html | xxd看前几个字节：出现ef bb bf是 UTF-8 with BOM；若输出charset=unknown-8bit或charset=us-ascii，大概率是 GBK 或其他单字节编码 - Windows PowerShell 运行
Get-Content index.html -Encoding Byte | Select -First 3：结果为239 187 191就是 BOM；若前两字节是178 179（常见于 GBK 中文开头），基本可断定是 GBK - Sublime Text 可直接点右下角编码名 → “Reopen with Encoding”，挨个试 UTF-8 / GBK / ISO-8859-1，哪一种让中文恢复就说明原始编码是它
为什么 <meta charset="UTF-8"> 写了还是乱码
这个标签只有在没 HTTP 响应头干扰、且自身位置正确时才生效。它不是万能开关，而是一个 fallback 补救机制。
-
<meta charset="UTF-8">必须位于最前面，前面不能有任何空白、BOM、注释或<title></title>—— 否则浏览器在解析到它之前已按默认编码（如 ISO-8859-1）开始解码，后续再声明也晚了 - 服务器返回的响应头
Content-Type: text/html; charset=gbk优先级高于<meta>，此时改标签毫无作用；需查 Nginx 的charset gbk;、Apache 的AddDefaultCharset或 Express 中是否手动设了 header - 本地双击打开（
file://协议）时，响应头不存在，全靠<meta>和文件实际编码匹配；但若文件带 BOM，某些旧版 IE 或脚本加载器会把 BOM 当作非法字符抛错
如何验证三者是否真正统一
“统一”不是指你主观觉得都写了 UTF-8，而是指浏览器实际使用的解码路径完全一致。关键看浏览器从哪一层拿到 charset 信息。
Convert Markdown To HTML And PDF - Markdown和HTML、PDF互转
下载
实现 Markdown↔ HTML 互转，支持导出 PDF，用于用户请求的文档格式转换。
- 打开 Chrome DevTools → Network → 刷新页面 → 点开 HTML 请求 → 查
Response Headers中的content-type字段：有charset=utf-8？没有？值是gbk？这决定第一优先级 - 再看 HTML 源码前 1024 字节内是否真有
</meta charset="UTF-8">（注意拼写：必须是UTF-8，utf8或UTF8无效），且前面无空格/BOM/注释 - 最后确认文件本身：用上面命令查出的真实编码，是否和前两项声明一致。三者只要差一个，就可能 fallback 到 Windows-1252 或 GBK，显示成
æç±或方框
容易被忽略的隐性破坏点
很多乱码不是发生在保存或声明环节，而是在中间链路被悄悄改写。
立即学习“前端免费学习笔记（深入）”；
- 用 Windows 记事本另存为 UTF-8，它默认加 BOM —— 这个 BOM 会卡在
<meta>前面，导致标签失效；务必换 VS Code 或 Notepad++，选 “UTF-8” 而非 “UTF-8 with BOM” - 通过模板引擎（如 EJS、Thymeleaf）动态生成 HTML 时，
<meta charset>写在模板里，但后端拼接字符串时用了错误编码读取数据，结果整个 HTML 输出流已经乱码，meta 标签再准也没用 - 前端 JS 动态插入内容（比如
document.title = "中文"），如果 JS 文件本身保存为 GBK，而页面是 UTF-8，浏览器会按 UTF-8 解析 JS 字节，把 GBK 字节当 UTF-8 解，产生二次乱码
