必须用 UTF-8，因其能无损表示所有 Unicode 字符且兼容 ASCII；meta charset="UTF-8"须置于 head 最前；HTTP 响应头 Content-Type 与 meta 必须一致；文件须保存为 UTF-8 no BOM。
只要页面声明 UTF-8 编码、文件实际保存为 UTF-8、服务端响应头不冲突，HTML 就能兼容所有现代输入法（包括中文拼音、五笔、日文 IME、韩文 Hangul、Emoji 面板等）——不是“适配某种输入法”，而是让浏览器和系统按 Unicode 标准正确收发字符。
meta charset 必须写在 head 最前面
浏览器解析到 <meta charset="UTF-8"> 才开始按 UTF-8 解码后续内容。如果它出现在 <title> 之后或被注释包裹，部分浏览器（尤其是旧版 IE 和某些嵌入式 WebView）会先用默认编码（如 GBK）解析前面的字节，导致乱码已发生、再改也无效。
- 必须放在
<head>内第一个非空行，紧挨<head>开始标签 - 不能写成
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">—— 这是 HTML4 兼容写法，但解析优先级低于charset属性，且在某些安卓 WebView 中失效 - 不要加 BOM：VS Code 保存时选 “UTF-8” 而非 “UTF-8 with BOM”，BOM 会导致
<!DOCTYPE html>前多出不可见字节，引发怪异渲染
文件保存编码必须是 UTF-8（无 BOM）
光写 <meta charset="UTF-8"> 没用。如果编辑器把文件存成了 GBK，浏览器看到的是乱码字节流，再怎么声明也是对错误数据做正确解码，结果还是错的。
- VS Code：右下角点击编码名称（如 “GBK”），选 “Save with Encoding” → “UTF-8”
- Sublime Text：File → Save with Encoding → UTF-8
- 记事本（Windows）：另存为 → 编码选 “UTF-8”，**不要选 “UTF-8-BOM”**
- 验证方法：用 hex editor 打开文件，开头三字节应为
EF BB BF（BOM）或直接是文档内容（无 BOM）。生产环境推荐无 BOM
服务端 Content-Type 响应头不能覆盖 meta
HTTP 响应头里的 Content-Type: text/html; charset=GBK 会强制覆盖 HTML 内的 <meta charset>，这是浏览器标准行为。你看到页面局部乱码（比如导航栏正常、表单文字变问号），大概率是这个原因。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- Apache：在
.htaccess或虚拟主机配置中加AddDefaultCharset UTF-8，并确保没其他地方覆盖了Header set Content-Type - Nginx：在
server或location块里写charset utf-8;，**不要**用add_header Content-Type手动拼，容易漏掉text/html类型 - Node.js（Express）：
app.use((req, res, next) => { res.set('Content-Type', 'text/html; charset=utf-8'); next(); }); - 验证方式：打开 Chrome DevTools → Network → 点开 HTML 请求 → Headers → Response Headers → 查看
content-type字段值
输入法兼容的关键不在前端设置，而在不破坏中间态
中文输入法（IME）本身不依赖页面编码设置，它输出的是 Unicode 字符。真正出问题的地方，是前端 JS 在用户还没完成输入时就强行读取、清洗或重置 input.value，导致 composition 中断。
- 不要在
oninput里对value做正则替换（如删空格、转大写），这会让拼音候选框瞬间消失 - 防抖校验必须绕过
compositionstart到compositionend之间的时间段：用useRef（React）或闭包变量标记isComposing，只在!isComposing时触发 - 避免给
input同时设type="number"和监听input事件——Safari 会把中文输入当成非法输入而清空字段 - Emoji 不需要特殊处理，只要 UTF-8 生效，它就是合法字符；后端存不进数据库？那是 MySQL 没用
utf8mb4，不是前端问题
最常被忽略的一点：三个地方（文件编码、meta 声明、HTTP 响应头）必须全部一致且真实生效。少一个，或者其中一个值是假的（比如文件存的是 GBK 却声明 UTF-8），输入法就能正常打字，但提交后后端收到的就是乱码字节——这时候查 JS 逻辑毫无意义。
