UTF-8是强制前提而非可选项，必须全程统一：HTML文件存为UTF-8无BOM、meta charset="UTF-8"置于head首位、HTTP头声明charset=utf-8、表单与AJAX显式指定，任一环节偏离即致乱码或损坏。

UTF-8 是唯一应被采用的字符编码，不是“可选项”，而是强制前提。其他编码（如 GBK、Shift_JIS）在现代多语言网页中已无合理存在空间——它们无法覆盖 emoji、生僻汉字、阿拉伯数字变体、梵文字母等，且浏览器兼容性差、服务端处理成本高。

必须把 放在 最开头

浏览器解析 HTML 时，一旦遇到非 ASCII 字符（比如中文、日文），会立即回退到默认编码（通常是 ISO-8859-1 或系统 locale 编码）去解码；此时若 还没读到，乱码就已发生，后续再声明也无效。

• ✅ 正确顺序： —— 必须是 内第一个标签，前面不能有 <script></script>、 或注释
• ❌ 错误写法：<script>...</script> —— JS 执行前浏览器已按错误编码解析了部分 HTML
• ⚠️ 注意：该标签不能出现在 中，也不支持 http-equiv 形式替代（HTML5 已废弃 的 charset 功能）

lang 属性和 charset 完全无关，别混着配

lang="zh-CN" 不影响字节怎么解码，只告诉浏览器“这段文本是简体中文”，用于屏幕阅读器发音、拼写检查、:lang() CSS 选择器、翻译按钮触发等。它和 各司其职，改一个不等于另一个自动生效。

HTML Text Extract

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

下载

• ❌ 典型误区：以为设了 lang="ja" 就能“让日文显示正常”——实际显示是否乱码，只取决于编码是否为 UTF-8 + 字节流是否真实用 UTF-8 编码保存
• ✅ 正确做法：静态页硬编码 ；SSR 根据请求头注入；SPA 切换语言时整页刷新（window.location.href = '/en'），而非仅改 document.documentElement.lang
• ⚠️ 混排内容必须显式标注：

  API

  、

  curl -X POST

  ，否则辅助技术会用中文引擎读英文单词

服务端与前端必须全程保持 UTF-8 一致

从文件保存、HTTP 响应头、表单提交、AJAX 请求到数据库存储，任一环节偏离 UTF-8，都会导致多语言字符被截断、替换或静默损坏。

• ✅ 文件保存：用 VS Code 等编辑器存为 “UTF-8 无 BOM”（BOM 会导致 PHP 输出前置空白、Node.js 解析 JSON 失败）
• ✅ HTTP 响应头：确保服务器返回 Content-Type: text/html; charset=utf-8，优先级高于 ；可用浏览器 DevTools 的 Network 面板验证
• ✅ 表单提交：
  显式声明，避免旧浏览器回退到 ISO-8859-1
• ✅ AJAX（fetch）：headers: { 'Content-Type': 'application/x-www-form-urlencoded; charset=UTF-8' }，尤其注意后端是否默认接受此 header

最容易被忽略的是：HTML 文件本身是否真用 UTF-8 编码保存。很多编辑器默认用系统 locale 编码（如 Windows-1252 或 GBK）存文件，即使写了 ，浏览器拿到的仍是错编码的字节流——此时所有设置都白搭。务必用十六进制编辑器或 file -i filename.html 命令确认原始字节编码。

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