基本可断定文件保存编码与浏览器解析编码不一致；需验证真实字节编码（如file -i或xxd），再用编辑器重解码为GBK/GB2312后保存为无BOM的UTF-8，并确保<meta charset="UTF-8">紧贴<head>开头且无前置字符。
直接用浏览器打开下载的 HTML 文件，中文显示为方块、问号或乱码符号，基本可以断定：文件保存时的编码 ≠ 浏览器解析时默认尝试的编码。这不是“坏了”，而是“说错了语言”——你手里的文件是用 GBK 写的，浏览器却按 UTF-8 读；或者反过来。
确认当前文件真实编码（别信编辑器右下角）
VS Code 或 Sublime 右下角显示的 “UTF-8” 很可能只是它“猜”的，尤其当文件开头有 BOM 或混杂了非 ASCII 字符时。必须验证真实字节：
- Linux/macOS：运行
file -i filename.html，看输出中的charset=值；更准一点用head -c 100 filename.html | xxd查看前几字节是否为ef bb bf（UTF-8 BOM） - Windows PowerShell：运行
Get-Content filename.html -Encoding Byte | Select -First 5，若前三字节是239 187 191，就是 UTF-8 BOM - 如果显示
charset=iso-8859-1或charset=us-ascii，但页面里明显有中文——那几乎肯定是 GBK/GB2312 编码，只是没 BOM，工具误判了
用编辑器强制重解码再保存为 UTF-8
乱码文件还能“救回来”，关键不是改内容，而是告诉编辑器：“请用 XX 编码重新解读这些字节，再以 UTF-8 写出”。操作路径因编辑器而异：
- VS Code：打开乱码文件 → 右下角点击当前编码（如 “GBK” 或 “ISO-8859-1”）→ 选
Reopen with Encoding→ 从列表中选GBK（常见于国内老网站源码）或GB2312→ 确认文字正常显示 → 再点右下角编码 → 选Save with Encoding→ 选UTF-8（注意：不要选UTF-8 with BOM，HTML5 不需要） - Notepad++：菜单栏
编码→字符集→ 依次试ANSI（Windows 默认即 GBK）、GBK、GB2312→ 找到能正确显示中文的 → 再点编码→转为 UTF-8 无 BOM→ 保存 - Sublime Text：菜单
File→Reopen with Encoding→ 试Chinese (GBK)→ 正常后 →File→Save with Encoding→UTF-8
补全并校验 <meta charset="UTF-8"> 的位置和写法
即使文件已存为 UTF-8，浏览器仍可能乱码——因为 <meta charset="UTF-8"> 没放对位置，或被其他东西挡住了：
立即学习“前端免费学习笔记（深入）”；
- 必须紧贴
<head>开始，且是<head>内第一个非空、非注释节点。错误示例：<head><!-- 注释 --><meta charset="UTF-8">（注释在前，失效） - 不能写成
<meta charset="utf8">或<meta charset="UTF8">—— 必须是"UTF-8"，连短横都不能少 - 删掉所有重复声明，比如同时存在
<meta charset="UTF-8">和<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">，后者在 HTML5 中已过时，还可能干扰解析 - 检查有没有隐藏字符：把
<meta charset="UTF-8">整行删掉，手动重打，确保前面没空格、不可见 Unicode 字符（如零宽空格）
本地双击打开（file://）时的特殊处理
如果你是直接双击 HTML 文件在浏览器中打开（没走 HTTP 服务器），那 HTTP 响应头完全不存在，<meta charset> 就是唯一依据。此时最容易踩的坑是：
- BOM 冲突：文件存为
UTF-8 with BOM，但<meta charset="UTF-8">又写在 BOM 后面 → 浏览器先看到 BOM，认定是 UTF-8，但某些旧内核会因 BOM 和 meta 冲突而 fallback 到系统默认编码（Windows 是 GBK） - 文件名含中文：部分浏览器（尤其旧版 IE/Edge）对 file:// 下含中文路径的文件，会错误地用系统编码解析整个文件，哪怕内容是 UTF-8。解决办法：把文件移到纯英文路径下再打开
- 没加
<meta charset>：file:// 协议下浏览器无服务端兜底，缺了这行就必然 fallback 到系统编码，Windows 用户大概率看到 GBK 乱码
真正麻烦的不是文件本身，而是“你以为它已经是 UTF-8”——结果编辑器显示正常，但字节流里藏着 BOM 或 GBK 字节。每次处理下载的 HTML，先 file -i 或 xxd 看真实编码，比盲目改 meta 标签有用十倍。
