别让浏览器猜谜：一份 UTF-8 避坑速查表
157
0
0
先讲个真事。
有位同事把网页上传到服务器，本地看一切正常，上线后所有中文变成“央”。他折腾一下午，最后发现是记事本默认用 ANSI 存盘，而浏览器按 UTF-8 猜。——编码不对，再漂亮的排版也救不回来。
1. 把“字符集”想成字典
浏览器收到的是 0 和 1，它得查字典才能把这些比特翻译成字。
字典不同，同一个字节序列会被译成完全不同的字符。
所以，先告诉浏览器用哪本字典，再确保文件本身按这本字典排版，是网页发布的第一步，不是最后一步。
2. 常见字典速览（知道就行）
| 字典名 | 适用场景 | 缺点 |
|---|---|---|
| ASCII | 1963 年的老美键盘 | 没有中文 |
| GB2312/GBK | 早期国内 Windows | 繁体、 emoji 会失踪 |
| UTF-8 | 全世界 | 几乎没有 |
结论：2025 年了，直接选 UTF-8，别给自己加戏。
3. 声明方式：一句话放最前
<!doctype html>
<html lang="zh-CN">
<head>
<meta charset="utf-8"> <!-- 就这一行，放<title>之前 -->
<title>我的页面</title>HTML5 只要 charset，老项目可能看到 http-equiv="Content-Type"，功能一样，写法啰嗦。
4. 文件怎么存？
- VS Code → 右下角“UTF-8”点一下 → “保存时使用无 BOM”。
- Sublime → File → Save with Encoding → UTF-8.
- 记事本 → 另存为 → 编码选“UTF-8”（不要“UTF-8-BOM”）。
BOM 三字节 EF BB BF 会在某些语言（PHP、旧版 CSS）里产生“页面顶部多出一行空白”的灵异事件，无 BOM 最稳妥。
5. 服务器也要开口
浏览器先看 HTTP 响应头，再看 <meta>。
两者不一致时，HTTP 头优先，所以别让它们打架。
Nginx
charset utf-8;Apache
AddDefaultCharset UTF-8Node/Express
res.set('Content-Type', 'text/html; charset=utf-8');上传后打开 DevTools → Network → 看 Response Headers 里的 Content-Type 是否带 charset=utf-8，确认无误再收工。
6. 乱码急救三步
- 用编辑器重新“另存为 UTF-8 无 BOM”。
- 检查
<meta charset>是否顶到<head>第一行。 - 确认服务器响应头同 UTF-8。
三步做完仍乱码，99% 是文件里混进了其他编码的字符——全选→剪切→另存新文件→粘贴，干净利索。
7. 混合语言？表情？特殊符号？
UTF-8 全部原生支持，直接写就行：
<p>中文简体 / 繁體 / 🎉 / émoji / Мир</p>不用实体 &#xxxx;，除非你需要兼容 20 年前的浏览器。
8. 一句话总结
“先声明，后保存，再配服务器，三处统一 UTF-8。”
把这句话贴在桌前，比任何长篇大论都管用。
0
快来点个赞吧
发表评论
评论列表