C語言 printf 十六進制輸出 0xffffff 現象完整解析（進階版）

從博問真實案例看 char 型別提升陷阱

網路程式開發中常見困惑：byte 真實值 0xc9，打印卻顯示 0xffffffc9。本文通過完整代碼演示、記憶體佈局圖解、補碼運算推導，系統性拆解此現象本質，並給出工業級修正最佳實踐。

問題復現代碼

#include <stdio.h>

int main() {
    char c = 0xc9;                      // 有號 char，值 -55
    printf("A: c = %2x\n", (unsigned char)c);  // 方案 A
    printf("B: c = %2x\n", c & 0xff);          // 方案 B
    printf("C: c = %2x\n", c);                 // 方案 C（問題現場）
    return 0;
}

輸出：

A: c = c9
B: c = c9
C: c = ffffffc9

核心機制三步拆解

步驟 1：printf 參數提升規則

C 標準規定：%x 對應 unsigned int。可變參函數觸發整型提升，char → int。

步驟 2：有號 char 的補碼表示

• 0xc9 = 1100 1001
• 最高位 1 → 負數（-55）
• 補碼即為 1100 1001

步驟 3：符號擴展至 32 位 int

char (8 bit)  : 1 100 1001
int  (32 bit) : 1111 1111 1111 1111 1111 1111 1 100 1001
                ↑ 符號位複製 24 次
結果           : 0xFFFFFFC9

三種情況對比表

| 情況 | 代碼 | 關鍵動作 | 記憶體變化 | 結果 | |------|------|----------|------------|------| | **A** | `(unsigned char)c` | 先轉無號 → 零擴展 | 高 24 位填 0 | `0x000000C9` ✓ | | **B** | `c & 0xff` | 位元 AND 遮罩 | 高 24 位強制清 0 | `0x000000C9` ✓ | | **C** | `c` (直接) | 有號提升 → 符號擴展 | 高 24 位填 1 | `0xFFFFFFC9` ✗ |

方案 A 為何更規範？

• 語意明確：明確告訴編譯器「這是一個無號 8 位值」
• 無副作用：不依賴特定位寬假設（`0xff` 假設 8 位 byte）
• 標準合規：C 標準保證無號型別提升為零擴展

Linux 核心傾向方案 B（`& 0xff`），主要考慮歷史效能與宏定義便利性，現代編譯器優化下兩者機器碼通常一致。

工程落地檢查清單

1. ✅ 所有網路/序列化緩衝區使用 uint8_t/unsigned char
2. ✅ 打印 byte 時統一用 printf("%02x", (unsigned char)byte)
3. ✅ 代碼審查檢查點：char 是否混用作數值與字元
4. ✅ 靜態分析工具（如 Clang Static Analyzer）啟用隱式轉換警告

延伸思考：若改用 %hhx 格式化符

C99 引入 hh 長度修飾符，printf("%hhx", c) 直接按 unsigned char 處理，**無需顯式轉型**。但需確認編譯器支援度（MSVC 2013+、GCC/Clang 全支援）。

總結

0xffffff 前綴本質是 有號 char → int 符號擴展 的必然結果。掌握「提升 → 擴展 → 解讀」鏈路，配合 unsigned char 強型別或 %hhx 現代寫法，即可從根源消除此類困擾。