根本原因是file://协议下浏览器忽略HTTP响应头，仅依赖文件编码与<meta charset>匹配；须用记事本另存为UTF-8（无BOM），且<meta charset="UTF-8">必须为<head>内首个子节点。

本地直接双击打开 HTML 文件出现中文乱码，根本原因只有一个：file:// 协议下浏览器**完全忽略 HTTP 响应头**，只依赖文件本身的字节序列 + <meta charset> 标签，而这两者又极易不匹配。

记事本保存为 UTF-8（无 BOM）最稳妥

Windows 自带记事本默认用 GBK 保存，这是乱码主因。必须手动改：

• 用记事本打开 HTML 文件 → 点「文件」→ 「另存为」
• 在「编码」下拉菜单中，**必须选「UTF-8」**（不是「UTF-8-BOM」，也不是「ANSI」）
• 确认文件名后缀仍是 .html，点击保存
• 关闭再重开，乱码通常立刻消失

注意：记事本里「UTF-8」选项实际就是无 BOM 的 UTF-8；「UTF-8-BOM」会额外写入 EF BB BF 三个字节到文件开头，反而可能让某些老浏览器或工具误判。

<meta charset="UTF-8"> 必须紧贴 <head> 开始

即使文件已存为 UTF-8，如果 <meta charset="UTF-8"> 写错位置，浏览器照样 fallback 到 GBK：

立即学习“前端免费学习笔记（深入）”；

Wechat Article Html

将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。

下载

• 它必须是 <head> 标签内的**第一个子节点**，前面不能有任何字符（包括空格、换行、注释、BOM）
• 错误写法：<head>\n <!-- 注释 -->\n <meta charset="UTF-8"> → 失效
• 正确写法：<head><meta charset="UTF-8">（中间无换行、无空格、无注释）
• 大小写敏感：utf8、UTF8、utf-8 全部无效，只能是 UTF-8

验证文件真实编码是否为 UTF-8（无 BOM）

别信记事本右下角显示的「编码」，它经常误判。用命令行确认更可靠：

• PowerShell 中运行：Get-Content yourfile.html -Encoding Byte | Select -First 3
• 如果输出是 239 187 191，说明有 BOM → 需重存为「UTF-8」（去掉 BOM）
• 如果输出是其他数字（比如 60 63 120），大概率是无 BOM 的 UTF-8 或 GBK → 再结合内容判断
• Linux/macOS 用：head -c 3 yourfile.html | xxd，看是否有 ef bb bf

记事本本身无法查看十六进制，所以这一步不能跳过——很多所谓「已存为 UTF-8」的文件，其实只是记事本自作主张显示了错误的编码名称。

为什么不用 <meta http-equiv="Content-Type">？

这个写法在 HTML5 中已废弃，且对本地文件完全无效：

• 它模拟 HTTP 响应头，但 file:// 下根本没有响应头可模拟
• 现代浏览器（Chrome/Firefox/Edge）直接忽略它
• 写成 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> 不仅冗余，还可能干扰解析顺序
• 坚持用标准的 <meta charset="UTF-8"> 即可

真正容易被忽略的是：**BOM 和 <meta> 位置冲突时，浏览器优先信任 BOM**。而记事本的「UTF-8-BOM」选项会强制加 BOM，一旦加了，又没删干净，<meta> 就彻底白写了。