深色模式
弄懂 Unicode
概述
编码问题最容易让人烦躁，因为一旦乱码出现，屏幕上的每个字都在提醒“有东西没对齐”。但乱码的根源通常并不神秘，核心就一句话：字符和字节之间的约定没有统一。
想把这件事说明白，最好先拆开三个层次：字符是什么，字符编号是什么，编号如何编码成字节。Unicode、UTF-8、UTF-16、GBK 这些名字混在一起时，往往就是因为三个层次被说成了一层。
字符、码点、编码先分开
可以先记住这三个概念：
| 概念 | 说明 |
|---|---|
| 字符 | 人类理解的文字或符号，例如“你”“A”“😊” |
| 码点 | 给字符分配的编号，例如 U+4F60 表示“你” |
| 编码 | 把码点变成字节序列的方法，例如 UTF-8、UTF-16 |
Unicode 本身主要解决的是“给全世界字符统一编号”的问题。它不是单一字节编码，而是一套字符集合和编号体系。
为什么早期会有很多本地编码
在 Unicode 普及之前，不同地区通常使用自己的编码方案。
例如中文环境里常见过：
GB2312GBKGB18030
它们的出发点很现实：覆盖本地区常用字符，节省存储空间，也兼容当时的软件生态。问题在于，这类编码彼此不统一，跨地区、跨系统传输时很容易出错。
于是开发者很快就会遇到经典问题：
- 发送方按
GBK编码 - 接收方按
UTF-8解码 - 结果屏幕上开始长草
Unicode 到底是什么
Unicode 可以理解为一套统一字符标准。它给每个字符分配一个码点，例如：
A是U+0041中是U+4E2D- 😀 是
U+1F600
有了统一码点，世界上不同语言的字符就可以放进同一套体系里处理。这样数据库、编程语言、传输协议就不必每到一个地区都换一套字符编号规则。
UTF-8、UTF-16 是什么
它们都是 Unicode 的编码方式。
也就是说：
Unicode负责“这个字符编号是多少”UTF-8、UTF-16负责“这个编号在文件和内存里怎么存成字节”
UTF-8
UTF-8 是当前最常见的文本编码。它的特点是：
- 兼容
ASCII - 按需使用 1 到 4 个字节
- 英文占用空间小
- 网络、文件、前后端传输里几乎默认都是它
一个非常现实的经验是：没有特殊理由时，文本默认优先选 UTF-8。它已经接近现代系统里的普通话。
UTF-16
UTF-16 使用 2 字节或 4 字节表示字符，很多系统和运行时内部曾广泛使用它，例如早期 Windows、Java、部分 JavaScript 语义历史。
它对东亚字符相对友好，但在英文大量文本里不一定比 UTF-8 更省空间。碰到超出基本多文种平面的字符时，还会涉及代理对问题。
为什么 UTF-8 这么常见
它同时兼顾了几个现实优势：
- 和
ASCII完全兼容 - 互联网协议和工具链支持非常成熟
- 对英文内容节省空间
- 对多语言文本也能统一处理
这也是为什么：
HTML页面通常声明UTF-8JSON默认就是Unicode文本，实际传输里常常用UTF-8- 数据库新项目通常也优先选
utf8mb4
GBK 还会在哪些地方出现
虽然新系统里 UTF-8 更常见，但 GBK 还没完全退出历史舞台，尤其在：
- 老 Windows 程序
- 某些旧数据库或导出文件
- 早年接口文档和报文格式
- 本地工具生成的文本文件
所以编码问题并不是“学会 Unicode 就结束”，而是要知道现代系统和遗留系统可能会同时存在。
乱码通常是怎么来的
乱码最常见的根因，不是字符丢了，而是编码和解码不一致。
例如：
- 文本原本按
UTF-8编码成字节。 - 某个程序误以为它是
GBK。 - 解码时使用了错误规则。
- 结果出现乱码。
这就像同一串数字，本来应该按经纬度解释，却被当成门牌号读，自然看不出原意。
开发里几个特别常见的坑
数据库字符集配错
应用层是 UTF-8，数据库连接、字段、表、库却不是统一编码，最容易出问题。MySQL 场景里，通常应优先使用 utf8mb4，而不是旧的 utf8。
文件编码和编辑器识别不一致
源文件是 GBK，编辑器按 UTF-8 打开，保存一次后内容可能直接坏掉。
HTTP 头或页面声明缺失
浏览器或客户端不知道该按什么编码解释响应内容，就会猜。猜对了叫运气，猜错了叫工单。
只按“字符个数”理解长度
字符数、码点数、字节数，在不同场景下不是一回事。数据库字段长度、网络报文长度、前端截断逻辑都可能踩坑。
一个更稳妥的实践
新项目里通常可以采用一条简单策略：
- 文本文件统一用
UTF-8 - 数据库统一用
utf8mb4 - 接口传输明确声明字符集
- 日志、导入导出、脚本都避免混用本地旧编码
编码问题不难，难的是系统里总有几处默认值不肯老实说话。先把“字符”“码点”“编码”分开，排查就会清楚很多。