utf-8是html5唯一合法的编码声明值，因规范强制要求写为“utf-8”（含短横），而“utf8”“utf_8”等均无效，浏览器会忽略并退回到默认编码导致乱码；且meta charset必须置于head最前、http响应头优先级更高、所有资源文件也需统一utf-8。

UTF-8 是唯一推荐且实际可行的页面编码方案，其他如 GBK、ISO-8859-1 或拼写错误的 utf8、UTF_8 都会导致乱码或解析失败。

为什么只认 UTF-8，不接受 utf8？

HTML5 规范明确定义合法值只有 UTF-8（全大写 U、T、F，中间短横，末尾数字 8）。浏览器遇到 charset="utf8" 会当作无效值忽略，退回到默认编码（可能是系统 locale 或旧版 ISO 编码），结果就是中文变方块、日文假名错位、emoji 显示为 。

常见错误包括：

• <meta charset="utf8"> —— 少了横线，无效
• <meta charset="UTF_8"> —— 下划线替代短横，无效
• <meta charset="UTF8"> —— 缺少短横，部分老浏览器可能勉强支持，但不符合标准，Nginx/Apache 日志里常报 warning

meta charset 必须放在 最前面

它得是 里第一个可解析的标签（DOCTYPE 之后、任何 <script></script> 或 <style></style> 之前）。否则浏览器已按错误编码开始解析后续 HTML，再读到 meta 也晚了。

尤其注意：

Article To Html

文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。

下载

• VS Code 默认保存为 UTF-8 无 BOM，安全；Sublime Text / Notepad++ 默认带 BOM，BOM 会卡在 前面，导致 <code>meta charset 实际不是第一个标签，直接失效
• PHP 模板中若 PHP 文件本身是 GBK 编码，echo "<meta charset='\"UTF-8\"'>" 输出时会被转成 GBK 字节流，浏览器收到的是乱码字节，meta 标签本身就被破坏

HTTP 响应头比 meta 更优先

如果服务器返回的 HTTP 头是 Content-Type: text/html; charset=GBK，哪怕 HTML 里写了正确的 <meta charset="UTF-8">，浏览器也以响应头为准——这是规范强制行为。

验证方式：

• 打开 DevTools → Network → 点击 HTML 请求 → 查看 Response Headers 中的 Content-Type
• Nginx 配置需加：charset utf-8;（注意这里是小写 utf-8，和 HTML 中的 UTF-8 不同）
• Apache 需确认 AddDefaultCharset UTF-8 已启用，且没被 .htaccess 覆盖

外部资源（JS/CSS）也要 UTF-8

HTML 页面设对了，但引入的 <script src="app.js"></script> 或 <link rel="stylesheet" href="style.css"> 文件本身是 ISO-8859-1 编码，里面含中文字符串（如 alert("提交成功")）照样报 Uncaught SyntaxError: Invalid or unterminated string literal。

解决办法很简单：

• 所有 JS/CSS 文件保存为 UTF-8 无 BOM
• 在 <script></script> 标签上显式声明：<script src="app.js" charset="UTF-8"></script>（虽然现代浏览器通常能自动推断，但加上更稳）
• 避免在 CSS 中用 content: "你好"; 这类内联中文，改用伪元素 + data 属性或字体图标替代，减少编码依赖

真正麻烦的从来不是“怎么写”，而是“谁在偷偷覆盖”：编辑器 BOM、PHP 文件编码、HTTP 头、CDN 缓存旧头、甚至构建工具（如 Webpack 的 file-loader）输出时未指定 encoding。每层都得单独验，漏一层就前功尽弃。

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