2、字符编码不匹配：UTF-8编码的文本使用GB2312字体渲染，出现乱码

乱码，这大概是嵌入式开发里最让人头疼的问题之一了。你明明看到屏幕上显示了一堆字符，但就是看不懂——全是些奇怪的符号、问号，或者干脆就是空白。我刚开始做嵌入式UI那会儿，遇到这种情况第一反应就是怀疑硬件坏了。后来才发现，十有八九是编码没对上。

说白了，就是你的文本是用一种编码方式写的，但字体文件却用另一种编码方式去解读。这就好比两个人用不同的密码本对话，谁也看不懂谁在说什么。

2.1 编码不匹配的本质

咱们先理清一个概念。字符编码，就是给每个字符分配一个唯一的数字编号。比如汉字“中”，在UTF-8里是一串字节，在GB2312里是另一串字节。字体文件里存储的，则是这些编号对应的字形。

当你的程序读取文本时，它会按照某种编码规则把字节转换成字符编号，然后去字体里找对应的字形来画。如果文本的编码和字体的编码不一致，那查到的编号就是错的，画出来的自然就是乱码。

举个例子。UTF-8编码的“中”字，字节序列是 E4 B8 AD。如果字体是GB2312的，它会把这3个字节当成两个GB2312字符来解析。结果就是，它可能画出一个“涓”字和一个“­”符号。你看，完全对不上。

2.2 常见乱码现象速查

我在项目里遇到过好几种乱码表现，这里整理成一个表格，方便你对照排查。

乱码表现	可能原因	典型场景
全是问号 ????	字体中缺少对应字符的字形	UTF-8文本用只含ASCII的字体渲染
奇怪的汉字组合	编码被错误地按另一种编码解析	UTF-8文本用GB2312字体渲染
单字节乱码	UTF-8多字节字符被截断	缓冲区大小不足，只读了部分字节
部分正常部分乱码	混合编码文本	从不同来源拼接了字符串
显示为空白	编码转换后得到空字符或不可见字符	UTF-8 BOM头被当作字符显示

嗯，这里要注意。问号不一定就是编码问题。有时候是字体文件本身就没包含那个字符的字形。我遇到过一种情况：字体文件里只有英文和数字，中文全用问号代替。那其实是字体制作时偷懒了。

2.3 编码转换的底层逻辑

要解决乱码，你得理解编码转换到底在做什么。我画了一张图，帮你理清这个流程。

你看，正确的流程是：源文本 → 解码成Unicode码点 → 编码转换 → 目标编码 → 字体渲染。很多人图省事，直接从源文本跳到字体渲染，跳过了中间的编码转换步骤。这就是乱码的根源。

2.4 实战：如何修复编码不匹配

好了，理论说完了，咱们来点实际的。修复编码不匹配，我总结了三个步骤。

步骤一：确认文本的真实编码

你手头的文本文件，到底是用什么编码保存的？别只看文件名或者注释，那玩意儿经常骗人。我习惯用十六进制编辑器打开文件，看文件头。

• UTF-8 with BOM： 文件头三个字节是 EF BB BF
• UTF-8 without BOM： 没有特殊文件头，但字节序列符合UTF-8规则
• GB2312/GBK： 没有特殊文件头，汉字占两个字节，且每个字节都大于 0x7F
• UTF-16 LE： 文件头两个字节是 FF FE
• UTF-16 BE： 文件头两个字节是 FE FF

步骤二：确认字体的编码

字体文件本身也有编码属性。常见的嵌入式字体格式，比如 .bdf 和 .pcf，在文件头里会标明编码。用 bdftopcf 或者 fontconfig 的工具可以查看。

# 查看 BDF 字体文件的编码
grep "CHARSET_REGISTRY" myfont.bdf
# 输出示例：CHARSET_REGISTRY "ISO10646"  (表示 Unicode)
# 输出示例：CHARSET_REGISTRY "GB2312"    (表示 GB2312)

# 查看 PCF 字体文件的编码
pcf2bdf myfont.pcf | grep "CHARSET_REGISTRY"

我个人习惯在项目初期就把所有字体的编码信息记录到一个文档里。不然项目做到一半，几十个字体文件摆在那儿，谁还记得哪个是哪个编码？

步骤三：做编码转换

确认了两边的编码之后，要么转文本，要么转字体。一般来说，转文本更简单。

在嵌入式系统里，我常用 iconv 库来做编码转换。它支持几乎所有常见的编码格式。

#include <iconv.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>

/**
 * 将 UTF-8 字符串转换为 GB2312
 * @param utf8_str  输入的 UTF-8 字符串
 * @param out_len   输出缓冲区长度
 * @return          转换后的 GB2312 字符串，需要 free
 */
char* utf8_to_gb2312(const char* utf8_str, size_t* out_len) {
    iconv_t cd = iconv_open("GB2312", "UTF-8");
    if (cd == (iconv_t)-1) {
        perror("iconv_open failed");
        return NULL;
    }

    size_t in_len = strlen(utf8_str);
    // GB2312 每个汉字占 2 字节，ASCII 占 1 字节
    // 分配 2 倍输入长度作为输出缓冲区，通常够用
    size_t buf_size = in_len * 2 + 1;
    char* out_buf = (char*)malloc(buf_size);
    if (!out_buf) {
        iconv_close(cd);
        return NULL;
    }

    char* in_ptr = (char*)utf8_str;
    char* out_ptr = out_buf;
    size_t out_remain = buf_size;

    size_t result = iconv(cd, &in_ptr, &in_len, &out_ptr, &out_remain);
    if (result == (size_t)-1) {
        // 转换失败，常见原因：输入中有非法字符序列
        perror("iconv failed");
        free(out_buf);
        iconv_close(cd);
        return NULL;
    }

    *out_ptr = '\0';
    *out_len = buf_size - out_remain;

    iconv_close(cd);
    return out_buf;
}

// 使用示例
int main() {
    const char* utf8_text = "你好，世界！Hello!";
    size_t gb_len = 0;
    char* gb_text = utf8_to_gb2312(utf8_text, &gb_len);
    
    if (gb_text) {
        printf("转换成功，长度: %zu 字节\n", gb_len);
        // 这里可以把 gb_text 传给显示模块
        free(gb_text);
    } else {
        printf("转换失败\n");
    }
    return 0;
}

2.5 嵌入式环境下的特殊考量

在嵌入式系统里，资源有限，编码转换不能太任性。我有几点建议。

• 能提前转就别运行时转： 如果文本是固定的（比如菜单项、提示信息），在PC上提前转好，直接烧录到设备里。省掉运行时的转换开销。
• 统一编码标准： 整个项目组约定好，所有文本文件统一用UTF-8 without BOM，所有字体统一用Unicode编码。这样最省心。
• 注意内存碎片： iconv 内部会分配临时缓冲区，频繁调用可能导致内存碎片。我习惯在初始化时一次性分配好转换缓冲区，重复使用。
• 考虑用查表法： 如果只是少量固定字符需要转换，可以预先生成一个编码映射表。比如把常用的100个汉字从UTF-8映射到GB2312，运行时直接查表，比调用iconv快得多。

2.6 快速诊断清单

遇到乱码，别慌。按这个清单一步步排查。

1. 看乱码特征： 全是问号？奇怪的汉字？部分正常？——对照上面的表格缩小范围。
2. 确认文本编码： 用十六进制工具或 file 命令查看。
3. 确认字体编码： 查看字体文件的编码声明。
4. 检查转换代码： 确认你的代码里是否做了编码转换，转换方向对不对。
5. 测试最小用例： 用一个简单的字符串（比如“A中”）做测试，看转换结果是否正确。
6. 检查缓冲区： 确保输出缓冲区足够大，避免截断。

嗯，基本上按这个流程走一遍，90%的编码乱码问题都能解决。剩下的10%，可能是字体文件本身损坏，或者硬件显示驱动有问题——那就是另一章的内容了。