char符号扩展陷阱：枚举转字符串超过127乱码的定位与修复

昨天在排查一个通信模块的报文序列化问题时，撞上一个特别典型的“每日小问题”：协议里定义的状态码枚举，只要数值超过127，编码成字符串后完全不对；127及其以下全部正常，128开始集体翻车。现象越典型，越值得记录——这类问题在C/C++项目里几乎每年都会遇到一次，尤其做嵌入式、网络协议、编解码和日志系统的团队。很多时候它并不会导致崩溃，而是以“看起来莫名其妙的乱码”形式出现，等你意识到是char的符号位在作怪，往往已经花掉了半天时间。

先交代一下具体背景。协议里用一字节表示状态码，代码里定义了一组枚举常量，比如 STATUS_BUSY = 127、STATUS_FAULT = 128。序列化时要将状态码拼进报文的ASCII字符串段，用于日志和设备调试口输出。在设备A上一切正常，换到设备B上报文突然出现大串“FFFFFF”前缀。如果你也在调试类似的枚举转字符串问题，看到这种非预期输出，大概率就是char和符号扩展在背后捣乱。这篇文章就把完整链路拆开：现象怎么复现、排查怎么走、根因是什么、修复怎么做，最后再顺带扫一遍同类陷阱。

1. 从127到128：一个枚举转字符串的翻车现场

1.1 一个看起来人畜无害的状态码序列化

假设手头有一个通信协议，状态码用一个字节承载，代码大概长这样：

c复制typedef enum {
    STATUS_OK = 0,
    STATUS_WAIT = 1,
    STATUS_RUN = 2,
    STATUS_BUSY = 127,
    STATUS_FAULT = 128,
    STATUS_ABORT = 255
} status_t;

序列化时，需要把状态码转成可读的十六进制字符串，方便打日志。常见的写法是先给枚举值分配一个char类型的临时变量，再套sprintf或snprintf：

c复制char code = (char)s->status;
snprintf(out, sizeof(out), "status=%02X", code);

逻辑看起来没问题：code从枚举转过来，%02X要求按十六进制输出，至少两位。可实际运行结果却非常刺激：

从128开始全部多出FFFFFF前缀。如果你对C语言的整型提升和符号扩展不敏感，第一反应往往是“我的sprintf写错了”“格式化字符串不对”“映射表有问题”。但仔细看，这里根本没有映射表，就是一个直接的类型转换和一串格式化输出。

1.2 最小复现：三段代码锁定问题范围

为了排除协议结构体、编译器优化等因素，我把问题压缩成一个独立可运行的小程序。这里的思路是：同一个枚举值，分别用char、unsigned char、int三种类型接收，然后统一用printf打印十六进制和十进制。

c复制#include <stdio.h>

typedef enum {
    STATUS_FAULT = 128
} status_t;

int main(void) {
    status_t s = STATUS_FAULT;

    char c = (char)s;
    unsigned char uc = (unsigned char)s;
    int i = (int)s;

    printf("char         : dec=%d hex=%02X\n", c, c);
    printf("unsigned char: dec=%u hex=%02X\n", uc, uc);
    printf("int          : dec=%d hex=%02X\n", i, i);

    return 0;
}

在我本地的x86 Linux环境下，输出是：

text复制char         : dec=-128 hex=FFFFFF80
unsigned char: dec=128  hex=80
int          : d