字符编码与Unicode：从ASCII到UTF-8的演进之路
字符编码这事儿，说白了就是给每个字符发一张「身份证」。但问题是，不同国家、不同系统发的身份证格式不一样，这就导致了乱码——你想想看，打开一个文本文件，满屏的「锟斤拷」，是不是很崩溃？
我在嵌入式项目里遇到过太多次这种问题了。有一次调试一块LCD屏，明明字库烧进去了，显示出来却是乱七八糟的符号。查了两天，最后发现是编码转换时少处理了一个字节序标记。从那以后，我对编码原理就格外上心。
ASCII：一切的开端
上世纪60年代，美国人搞出了ASCII。它用7个bit表示一个字符，总共128个编码点。0-31是控制字符（比如换行、回车），32-126是可打印字符（字母、数字、标点）。
ASCII编码范围
- 0x00 - 0x1F：控制字符（33个）
- 0x20 - 0x7E：可打印字符（95个）
- 0x7F：DEL删除符
嗯，这里要注意：ASCII只覆盖了英文字母和基本符号。你想想看，中文怎么办？日文怎么办？阿拉伯文怎么办？
GB2312：中文的第一次尝试
中国在1980年发布了GB2312标准。它用两个字节表示一个汉字，理论上能表示65536个字符。但实际上它只收录了6763个汉字，外加一些符号。
我记得第一次在嵌入式设备上做中文显示时，用的就是GB2312。当时有个坑：GB2312的高位字节范围是0xA1-0xF7，低位字节范围是0xA1-0xFE。如果你不小心把低位字节写成了0x00-0x20，那显示出来的就是乱码。
GB2312的局限
- 只覆盖常用汉字，生僻字没有
- 不支持繁体中文
- 与其他编码（如Shift-JIS、Big5）完全不兼容
- 一个文件里混用GB2312和ASCII时，解析容易出错
Unicode：一统江湖的野心
为了解决编码混乱的问题，Unicode应运而生。它的目标很简单：给世界上所有字符分配一个唯一的编号。目前Unicode已经收录了超过14万个字符，涵盖了154种文字。
Unicode的编码空间从U+0000到U+10FFFF，总共约111万个码点。它被划分为17个平面（Plane），每个平面65536个码点。
| 平面 | 范围 | 说明 |
|---|---|---|
| BMP（基本多文种平面） | U+0000 - U+FFFF | 最常用字符，包括ASCII、CJK统一汉字 |
| SMP（多文种补充平面） | U+10000 - U+1FFFF | 古代文字、音乐符号等 |
| SIP（表意文字补充平面） | U+20000 - U+2FFFF | CJK统一汉字扩展B区 |
| SSP（专用平面） | U+E0000 - U+EFFFF | 标签字符、变体选择符 |
但Unicode只是一个字符集，它只定义了字符和编号的对应关系。至于怎么存储这些编号，那是另一回事。
UTF-8：存储的艺术
UTF-8是Unicode的一种存储方式。它的设计很巧妙：兼容ASCII，同时支持变长编码。
UTF-8的编码规则是这样的：
- 单字节：0xxxxxxx（兼容ASCII，范围U+0000-U+007F）
- 双字节：110xxxxx 10xxxxxx（范围U+0080-U+07FF）
- 三字节：1110xxxx 10xxxxxx 10xxxxxx（范围U+0800-U+FFFF）
- 四字节：11110xxx 10xxxxxx 10xxxxxx 10xxxxxx（范围U+10000-U+10FFFF）
我个人习惯：在嵌入式项目中，如果内存够用，我优先用UTF-8。原因很简单：它没有字节序问题，而且ASCII字符只占1个字节，对英文为主的日志输出很友好。
编码转换实战
在驱动开发中，最常遇到的就是GB2312和UTF-8之间的转换。我曾经在一个项目里需要把字库从GB2312转成UTF-8索引，踩了不少坑。
下面是一个简单的转换思路：
// GB2312转Unicode码点
// 1. 读取GB2312双字节编码
// 2. 查GB2312-unicode映射表
// 3. 得到Unicode码点
// Unicode码点转UTF-8
// 1. 判断码点范围
// 2. 按规则填充字节
// 3. 输出UTF-8字节序列
// 示例：汉字"中"的转换
// GB2312: 0xD6 0xD0
// Unicode: U+4E2D
// UTF-8: 0xE4 0xB8 0xAD我曾经踩过的坑：GB2312转UTF-8时，要注意GB2312的0xA1A1-0xA9FE区域是符号区，不是汉字。如果直接按汉字映射表查，会得到错误的Unicode码点。正确的做法是先判断字符类型，再选择对应的映射表。
编码选择建议
在字体驱动适配中，编码选择直接影响显示效果和内存占用。我的建议是：
- 纯英文环境：用ASCII就够了，省空间
- 中文为主，内存紧张：用GB2312，每个汉字固定2字节
- 多语言支持：用UTF-8，兼容性好
- 内部处理：统一用Unicode码点，避免反复转换
你想想看，如果一开始就选对了编码，后面能省多少调试时间？
编码转换流程图
下面这张图展示了从原始文本到最终显示的编码转换路径：
这张图的核心逻辑是：不管输入是什么编码，最终都要统一转成Unicode码点，再通过Unicode索引去字库里找字形数据。这样做的好处是——字库只需要维护一套索引表，不用为每种输入编码都准备一套字库。
嗯，关于字符编码，今天就聊这么多。记住一点：编码转换是字体驱动的基础，搞懂了它，后面字库适配、渲染优化才能顺风顺水。