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 必须放在 <head> 最前面
它得是 <head> 里第一个可解析的标签（DOCTYPE 之后、任何 <script> 或 <style> 之前）。否则浏览器已按错误编码开始解析后续 HTML，再读到 meta 也晚了。
立即学习“前端免费学习笔记（深入）”；
尤其注意：
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- VS Code 默认保存为 UTF-8 无 BOM，安全；Sublime Text / Notepad++ 默认带 BOM，BOM 会卡在
<!DOCTYPE html>前面，导致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"> 或 <link rel="stylesheet" href="style.css"> 文件本身是 ISO-8859-1 编码，里面含中文字符串（如 alert("提交成功")）照样报 Uncaught SyntaxError: Invalid or unterminated string literal。
解决办法很简单：
- 所有 JS/CSS 文件保存为 UTF-8 无 BOM
- 在
<script>标签上显式声明：<script src="app.js" charset="UTF-8"></script>（虽然现代浏览器通常能自动推断，但加上更稳） - 避免在 CSS 中用
content: "你好";这类内联中文，改用伪元素 + data 属性或字体图标替代，减少编码依赖
真正麻烦的从来不是“怎么写”，而是“谁在偷偷覆盖”：编辑器 BOM、PHP 文件编码、HTTP 头、CDN 缓存旧头、甚至构建工具（如 Webpack 的 file-loader）输出时未指定 encoding。每层都得单独验，漏一层就前功尽弃。
