4、字符编码与Unicode：UTF-8、UTF-16、GB2312在嵌入式中的选择策略
字符编码这事儿，看着简单，踩坑的人可不少。我早年做一款带中英文菜单的智能家居面板，就因为在编码上偷了个懒，差点导致整个UI显示乱码。从那以后，我对编码选择就特别较真。
嵌入式GUI里，字体数据怎么存、怎么读、怎么解析，全都绕不开编码。今天咱们就把UTF-8、UTF-16、GB2312这三兄弟掰扯清楚。
4.1 编码的本质：字符与字节的映射
说白了，编码就是一张“字符→数字→字节”的翻译表。计算机只认0和1，你要显示一个“中”字，就得告诉它：这个字对应哪个数字，这个数字又怎么拆成字节。
不同的编码方案，区别就在于：
- 字符集范围：能表示哪些字符
- 存储效率：每个字符占几个字节
- 处理复杂度：解析快不快，内存开销大不大
在嵌入式环境里，这三条直接决定了你的GUI能不能跑得流畅、存得下、不崩。
4.2 三大编码方案对比
| 特性 | UTF-8 | UTF-16 | GB2312 |
|---|---|---|---|
| 编码长度 | 1~4字节（变长） | 2或4字节（变长） | 1或2字节（变长） |
| ASCII兼容 | ✅ 完全兼容 | ❌ 不兼容 | ✅ 兼容（单字节区） |
| 中文存储 | 3字节/字 | 2字节/字（BMP内） | 2字节/字 |
| Unicode覆盖 | 全部 | 全部 | 仅简体中文（6763字） |
| 解析复杂度 | 低（自同步） | 中（需处理代理对） | 低（查表即可） |
| 内存对齐 | 字节流，无对齐要求 | 需2字节对齐 | 字节流，无对齐要求 |
核心结论：没有绝对的好坏，只有合不合适的场景。选编码就是选“存储成本 + 处理成本 + 兼容性”的平衡点。
4.3 嵌入式场景下的选择策略
4.3.1 什么时候选UTF-8？
我个人习惯，新项目默认首选UTF-8。原因有三：
- ASCII兼容：英文字符、数字、标点只占1字节，和传统C字符串无缝衔接。你想想看，很多嵌入式协议栈、文件系统底层都是ASCII的，UTF-8直接往里塞就行。
- 自同步特性：就算字节流中间断了，UTF-8也能从下一个有效字节重新同步。这在通信链路上特别有用。
- 无字节序问题：没有大小端之争，跨平台移植省心。
我在项目中遇到过一个问题：某款MCU的硬件CRC模块只支持按字节计算，如果用UTF-16，还得先处理字节序，麻烦得很。换成UTF-8，直接按字节流算，省了一堆代码。
适用场景：资源受限（Flash/RAM紧张）、以英文为主但需要少量中文、需要与现有ASCII系统交互、跨平台移植。
4.3.2 什么时候选UTF-16？
UTF-16在嵌入式里其实挺尴尬的。它最大的问题是：不兼容ASCII。一个英文字母'A'，在UTF-16里要占2字节（0x0041），比UTF-8多一倍。而且很多MCU是8位或16位架构，处理16位对齐反而增加开销。
但有一种情况我会选UTF-16：当你的字体渲染引擎原生支持UTF-16，且字符基本都在BMP（基本多语言平面）内。比如某些商业GUI库，内部用UTF-16做索引，你传UTF-8进去还得转码，反而多一道工序。
避坑提醒：我曾经在一个项目里用UTF-16存储中文字符串，结果忘了处理大小端，在ARM（小端）和某款DSP（大端）之间通信时，所有中文都变成了乱码。排查了两天才发现是字节序问题。如果你非要用UTF-16，记得在文件头加BOM（字节序标记），或者统一约定大小端。
4.3.3 什么时候选GB2312？
GB2312是国标，只覆盖简体中文。在纯国内项目里，它有两个明显优势：
- 存储效率高：中文2字节，英文1字节，和UTF-8比，纯中文场景省33%空间。
- 解析简单：查表即可，不需要复杂的Unicode算法。对低算力MCU很友好。
但它的缺点也很致命：不支持繁体中文、日文、韩文。如果你的产品有海外版本，或者需要显示生僻字（GB2312只有6763个汉字），那就别选它。
我记得有个做POS机的项目，客户要求显示“𠀀”（U+20000，扩展B区汉字），GB2312直接歇菜，最后只能换成UTF-8。
4.4 编码选择决策流程
下面这张图是我自己总结的决策流程，每次做新项目都拿出来过一遍：
4.5 实际项目中的编码转换策略
很多时候，你没法自由选择编码——上游数据是GB2312的，下游渲染引擎只认UTF-16。这时候就需要做编码转换。
我的建议是：在嵌入式里，尽量在编译时完成转换，不要在运行时做。运行时转码既占CPU又占RAM，还容易出bug。
具体做法：
- 方案一：用Python脚本在PC上把字符串文件统一转成目标编码，生成头文件或二进制数据。
- 方案二：用
iconv或libiconv的嵌入式精简版，但只保留你需要的转换表，别全量编译进去。 - 方案三：如果只有少量固定字符串，直接手动查表硬编码。
经验之谈：我做过一个项目，需要在运行时接收GB2312的JSON数据，然后显示在GUI上。一开始用了完整的libiconv，Flash直接爆了。后来改成只保留GB2312→UTF-8的转换表（约8KB），问题解决。记住，嵌入式里够用就好，别贪大求全。
4.6 编码与字体文件的关系
选定了编码，不等于字体文件就能直接用。字体文件（如FontConfig、FreeType加载的ttf/otf）内部有自己的编码映射表（cmap表）。
你需要确保：
- 字体文件的cmap表支持你的编码。比如一个只包含GB2312映射的字体，你传UTF-8的字符码进去，它找不到字形。
- 渲染引擎的字符输入编码和字体cmap表匹配。不匹配的话，要么转码，要么换字体。
嗯，这里要注意：很多免费的中文字体只带了Unicode cmap，没有GB2312 cmap。你用GB2312编码去查，它也能工作，因为GB2312的字符码和Unicode的BMP区域有对应关系，但这不是标准做法，容易出问题。
4.7 总结：我的选择清单
最后，给出一份我自己的选择清单，供你参考：
- 新项目、不确定未来需求 → UTF-8。这是最安全的选择。
- 纯简体中文、Flash极紧张（<1MB） → 可以考虑GB2312，但要做好未来扩展的准备。
- 渲染引擎强制要求UTF-16 → 用UTF-16，但注意大小端和代理对处理。
- 多语言、生僻字、海外版本 → 别犹豫，UTF-8。
- 运行时转码 → 尽量在编译时完成，实在不行也要用精简转换表。
最后一句忠告：不管你选什么编码，一定要在项目初期就定下来。中途换编码的代价，比你想象的大得多。我见过一个团队在项目中期从GB2312切UTF-8，光改字符串解析和字体配置就花了两周，还引入了一堆乱码bug。