HTML5乱码主因是文件编码与声明/响应头不一致：需确保文件为UTF-8无BOM、meta声明准确置于head首行、服务器响应头未覆盖charset。BOM和响应头冲突占90%案例。

HTML5 文件保存编码不匹配导致乱码

最常见的情况是：编辑器用 UTF-8 无 BOM 保存了 index.html，但服务器或浏览器没按 UTF-8 解析。HTML5 默认要求 UTF-8，但不会自动强制生效——它依赖你显式声明和文件实际编码一致。

• 检查文件真实编码：用 VS Code、Sublime 或 Notepad++ 查看右下角状态栏，确认显示的是 UTF-8（不是 UTF-8 with BOM 或 GBK）
• 确保 声明在 最前面，且拼写准确：

• 不要写成 charset=UTF8、charset=utf8（少横线）或 content="text/html; charset=utf-8"（这是旧式 HTTP-equiv 写法，已过时）

服务器响应头覆盖了 HTML 中的 charset 声明

即使 写对了，如果服务器返回的 HTTP 响应头里有 Content-Type: text/html; charset=gbk，浏览器会优先信任响应头，直接忽略 HTML 内声明。

• 用浏览器开发者工具（F12 → Network → 刷新页面 → 点开 HTML 请求 → Headers 标签）查看 Response Headers 中的 content-type
• 本地测试时若用双击打开 file:// 协议，浏览器不发请求头，此时完全依赖 ，务必保证文件编码和声明一致
• Apache 用户可在 .htaccess 加：

  AddDefaultCharset utf-8

  ；Nginx 用户在 server 块中加：

  charset utf-8;

IDE 或构建工具自动转码引入 BOM 或编码污染

某些编辑器（如老版 Windows 记事本）、前端构建工具（如 gulp-htmlmin 默认可能移除 ）、甚至 Git 在换行符转换时，都可能悄悄插入 BOM 或改变编码。

• 用命令行检测 BOM：

  xxd index.html | head

  ，如果开头出现 00000000: efbb bf...，说明有 UTF-8 BOM，需另存为「UTF-8 无 BOM」
• Webpack/Vite 项目中，检查插件是否误处理 HTML 模板；html-webpack-plugin 一般安全，但自定义 minify 配置时禁用 removeAttributeQuotes 等可能干扰 meta 的选项
• VS Code 用户确认设置中 "files.encoding": "utf8" 且 "files.autoGuessEncoding": false（避免猜错）

中文路径或文件名在 URL 中未正确编码

这不属于 HTML 渲染乱码，但常被误认为“页面乱码”：当链接含中文路径（如 ），而服务器未配置 URL 解码支持，点击后可能 404 或返回错误内容。

• 开发阶段尽量用英文文件名和路径，避免这类问题
• 必须用中文时，服务端需支持 URI decoding；例如 Node.js 的 express 默认支持，但 Nginx 需开启：

  underscores_in_headers on;

  并确保 location 块未错误重写 URI
• 浏览器地址栏中看到 %E4%BD%A0%E5%A5%BD.html 是正常编码，不是乱码——只要服务端能正确 decode 就行