UTF-8是强制前提而非可选项，必须全程统一：HTML文件存为UTF-8无BOM、meta charset="UTF-8"置于head首位、HTTP头声明charset=utf-8、表单与AJAX显式指定，任一环节偏离即致乱码或损坏。
UTF-8 是唯一应被采用的字符编码，不是“可选项”，而是强制前提。其他编码（如 GBK、Shift_JIS）在现代多语言网页中已无合理存在空间——它们无法覆盖 emoji、生僻汉字、阿拉伯数字变体、梵文字母等，且浏览器兼容性差、服务端处理成本高。
必须把 <meta charset="UTF-8"> 放在
浏览器解析 HTML 时，一旦遇到非 ASCII 字符（比如中文、日文），会立即回退到默认编码（通常是 ISO-8859-1 或系统 locale 编码）去解码；此时若 <meta charset> 还没读到，乱码就已发生，后续再声明也无效。
- ✅ 正确顺序：
<meta charset="UTF-8"> <title>...</title>——<meta>必须是内第一个标签，前面不能有<script></script>、<style></style>或注释 - ❌ 错误写法：
<script>...</script><meta charset="UTF-8">—— JS 执行前浏览器已按错误编码解析了部分 HTML - ⚠️ 注意：该标签不能出现在
中，也不支持http-equiv形式替代（HTML5 已废弃<meta http-equiv="content-type">的 charset 功能）
lang 属性和 charset 完全无关，别混着配
lang="zh-CN" 不影响字节怎么解码，只告诉浏览器“这段文本是简体中文”，用于屏幕阅读器发音、拼写检查、:lang() CSS 选择器、翻译按钮触发等。它和 <meta charset="UTF-8"> 各司其职，改一个不等于另一个自动生效。
- ❌ 典型误区：以为设了
lang="ja"就能“让日文显示正常”——实际显示是否乱码，只取决于编码是否为UTF-8+ 字节流是否真实用 UTF-8 编码保存 - ✅ 正确做法：静态页硬编码
；SSR 根据请求头注入；SPA 切换语言时整页刷新（window.location.href = '/en'），而非仅改document.documentElement.lang - ⚠️ 混排内容必须显式标注：
<p lang="en">API</p>、<pre class="brush:php;toolbar:false;" lang="bash">curl -X POST</pre>，否则辅助技术会用中文引擎读英文单词
服务端与前端必须全程保持 UTF-8 一致
从文件保存、HTTP 响应头、表单提交、AJAX 请求到数据库存储，任一环节偏离 UTF-8，都会导致多语言字符被截断、替换或静默损坏。
立即学习“前端免费学习笔记（深入）”；
- ✅ 文件保存：用 VS Code 等编辑器存为 “UTF-8 无 BOM”（BOM 会导致 PHP 输出前置空白、Node.js 解析 JSON 失败）
- ✅ HTTP 响应头：确保服务器返回
Content-Type: text/html; charset=utf-8，优先级高于<meta>；可用浏览器 DevTools 的 Network 面板验证 - ✅ 表单提交：
<form accept-charset="UTF-8"></form>显式声明，避免旧浏览器回退到ISO-8859-1 - ✅ AJAX（fetch）：
headers: { 'Content-Type': 'application/x-www-form-urlencoded; charset=UTF-8' }，尤其注意后端是否默认接受此 header
最容易被忽略的是：HTML 文件本身是否真用 UTF-8 编码保存。很多编辑器默认用系统 locale 编码（如 Windows-1252 或 GBK）存文件，即使写了 <meta charset="UTF-8">，浏览器拿到的仍是错编码的字节流——此时所有设置都白搭。务必用十六进制编辑器或 file -i filename.html 命令确认原始字节编码。
