必须同时满足三个条件：HTML文件以UTF-8保存、位于开头1024字节内、HTTP响应头Content-Type含charset=utf-8；任一缺失均会导致浏览器fallback至GBK或ISO-8859-1而乱码。

必须同时满足三个条件，缺一不可：HTML 文件以 UTF-8（含 BOM 或不含 BOM）保存、 出现在 开头 1024 字节内、HTTP 响应头 Content-Type 包含 charset=utf-8。只做其中一项，乱码概率极高。

为什么 必须紧贴 开头

浏览器解析 HTML 时，只扫描文件开头 1024 字节来查找 meta charset。如果前面有注释、空行、BOM 错位或非 ASCII 字符（比如中文 ），就可能跳过它，转而 fallback 到系统默认编码（Windows 是 GBK，macOS/Linux 是 ISO-8859-1），直接导致 JS 报 Invalid or unexpected token 或页面文字全变成方块。

常见错误写法：

• —— 占了位置，meta 超出扫描范围
• —— 注释算字符，同样干扰扫描
• —— 拼写错误，utf8 不被识别，等效于没写

正确写法只有一种： ，且 前不能有任何空白、注释或 BOM 冲突。

怎么确认 HTML 文件实际保存为 UTF-8

编辑器显示“UTF-8”不等于文件真是 UTF-8。VS Code 右下角写着 UTF-8，但点开“Save with Encoding”可能发现它其实是 UTF-8 with BOM 或 GBK。BOM（EF BB BF）在某些旧环境（如 IE）会引发问题，现代推荐用 UTF-8 without BOM。

验证方法：

• VS Code：右键状态栏编码 → “Save with Encoding” → 明确选 UTF-8（不是带 BOM 的那个）
• 命令行（macOS/Linux）：head -c 4 index.html | xxd，输出不含 ef bb bf 才是无 BOM
• PowerShell（Windows）：Get-Content index.html -Encoding Byte | Select -First 3，前三字节不是 239, 187, 191

若发现是 GBK 或 ANSI，别改 meta 标签凑数——先用编辑器转存为 UTF-8，再检查是否生效。

HTML Text Extract

从HTML页面（URL、文件或标准输入）中提取主体内容文本，去除导航、页脚、广告和模板文本。可直接传递给readability_check或其他文本工具。

下载

HTTP 响应头 Content-Type 比 meta 更优先

当服务器返回 HTML 时，Content-Type: text/html; charset=utf-8 的优先级高于 。如果服务器发的是 charset=GBK，哪怕你写了十遍 UTF-8，Chrome 和 Firefox 都会按 GBK 解码。

常见配置方式：

• Apache：.htaccess 中加 AddDefaultCharset UTF-8 或 Header set Content-Type "text/html; charset=UTF-8"
• Nginx：server 或 location 块中加 charset utf-8;
• Express（Node.js）：res.set('Content-Type', 'text/html; charset=utf-8');
• 本地测试（file:// 协议）：没有 HTTP 头，此时 meta 是唯一依据，务必确保前两项 100% 正确

验证方法：浏览器打开 DevTools → Network → 刷新 → 点 HTML 请求 → 查看 Response Headers → 找 Content-Type 字段。

最容易被忽略的细节：大小写、引号、拼写全敏感

这串字符里，每个符号都必须精确：

• 属性名是 charset，不是 encoding 或 char-set
• 值必须是 "UTF-8" 或 "utf-8"，"UTF8"、"utf_8"、"UFT-8" 全部无效
• 引号必须是英文双引号 "，中文引号 “” 或单引号 ' 在部分解析器中会失败
• 不能自作聪明加斜杠闭合： 在 HTML5 中虽合法，但某些老旧工具链会误判

最稳妥的做法：复制粘贴标准写法，不要手打，尤其注意连字符 - 和大小写。一旦出错，浏览器不会报错，只会静默 fallback 到错误编码——这是调试乱码最头疼的地方。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！