写C语言这么多年，跟进制打交道大概是每个程序员都绕不过去的事。你以为只是“加个前缀”而已，结果真到项目里，被八进制010、十六进制0xFF、甚至那个永远不存在的%b格式符折腾过的人，绝不在少数。前段时间调试一个串口协议，需要在代码里硬编码一串位掩码，为了可读性我全用十六进制0x3F、0xC0去写，旁边同事看了一会儿问了一句：“这对应的二进制到底是几位？”我愣了一下，突然意识到，二进制、八进制、十六进制整数的书写和输出这套东西，看似简单，真要说清楚、写顺手、排错不迷糊，其实有相当多细节。今天把这一整套整理出来：包括书写规则、类型推导、printf格式化、手写二进制输出函数，以及我在项目里踩过的那些坑。

1. 先搞清楚一件事：整数在内存里只有二进制

1.1 进制只是“写法”，内存只有0和1

计算机内存里没有“十进制”和“十六进制”之分，只有高低电平，对应0和1。一个int变量，不管你在源代码里写的是255、0377还是0xFF，编译之后存到内存里的位模式都是一样的，都是00000000 00000000 00000000 11111111。

理解这一点很重要。很多初学者会问：“这个变量到底是十进制还是十六进制的？”答案是：变量本身没有进制属性，进制只是源代码里的书写形式。编译器把你写的字面量解析成一个数值，然后以二进制位模式存入内存。等到输出时，printf再按照你指定的格式把这个位模式翻译成人类可读的形式。

所以“进制”这个概念，只在两个阶段有意义：写代码时的字面量书写，以及输出时的格式化转换。中间的内存存储和运算，全部是二进制。

1.2 十进制、八进制、十六进制的书写规则与来历

C语言里，不同进制的整数书写规则如下：

八进制之所以用前导0表示，是C语言从更早的B语言继承下来的。这么设计的好处是词法解析简单：看到数字开头是0，后面跟着0-7，就按八进制处理。这个习惯还直接影响了UNIX生态，比如文件权限0755、0644，就是典型的八进制写法，每一位对应一组rwx权限位。0755的含义是：所有者为7（rwx），组为5（r-x），其他为5（r-x）。这种按位拆分的可读性，是八进制在系统编程里存活至今的原因。

十六进制的0x前缀里的x就取自hexadecimal的x。十六进制适合做位运算和内存地址表示，因为每4个二进制位对应1位十六进制数码，换算极其直观。比如0xF0一眼就能看出是1111 0000，用十进制写240反而要心算很久。

1.3 整数字面量的类型推导规则，以及一个经典反直觉案例

这部分是很多人的知识盲区。C语言标准规定，不带后缀的十进制字面量，类型按顺序尝试：int、long int、long long int，哪个能放下就用哪个。而不带后缀的八进制和十六进制字面量，类型尝试顺序是：int、unsigned int、long int、unsigned long int、long long int、unsigned long long int。

注意，八进制和十六进制在int放不下时，会先尝试unsigned int，而不是直接跳到long int。为什么？因为八进制和十六进制字面量经常用来表示位模式，比如0xFFFFFFFF，如果强制按有符号int解释，它就是-1，在很多场景下不是程序员想要的结果。标准把无符号类型提前，就是为了让这类位模式字面量能保持“无符号的大整数”语义。

这带来一个非常经典的坑。在32位int平台上：

if (0xFFFFFFFF > 0) { printf("大于0\n"); } else { printf("不大于0\n"); }

很多人想当然认为0xFFFFFFFF是-1，于是推测会输出“不大于0”。但实际上，0xFFFFFFFF在int放不下、unsigned int刚好放得下的情况下，其类型是unsigned int，值是4294967295，所以输出是“大于0”。如果你把它赋值给int变量，又会发生截断：

int x = 0xFFFFFFFF; printf("%d\n", x); // 输出 -1

同一个字面量，用在不同上下文，表现完全不同。这是我见过的高频面试题，也是实际调试时的真实困惑来源。

2. 二进制字面量：标准缺失时代的三种应对方案

2.1 没有标准支持的二进制写法

很多初学者兴冲冲写下int x = 0b1010;，然后发现编译器报错，一脸懵。事实上，在C23标准之前，C语言标准里一直没有二进制整数字面量的正式写法。虽然有几种编译器扩展支持0b前缀，但这并不是所有平台都能依赖的特性。

比如GCC和Clang很早就支持0b1010这种写法，但部分编译器不默认启用，某些嵌入式平台的工具链更是五花八门。如果你的代码要跨平台、跨编译器，直接写0b前缀是有风险的，至少要先确认目标工具链支持。

2.2 用宏模拟二进制的常见套路

既然标准不支持，嵌入式程序员们就发明了一些替代方案。最常见的一种是用宏把一个“看起来像二进制的十进制数字”解析成真正的二进制值。比如我想写10100101，宏能把数字串拆开、逐位加权。

一个经典实现是“按位宏组合”，写起来直观但不优雅：

#define B8(b7,b6,b5,b4,b3,b2,b1,b0) \ ((b7)<<7 | (b6)<<6 | (b5)<<5 | (b4)<<4 | \ (b3)<<3 | (b2)<<2 | (b1)<<1 | (b0))

调用时这样写：

int reg = B8(1,0,1,0,0,1,0,1);

这条语句最终展开成(1)<<7 | (0)<<6 | ... | (1)，正好得到二进制10100101。好处是编译器能把它当常量表达式处理，不会产生运行时开销；坏处是每次写8位就要列8个数位，很啰嗦。

如果你不想定义一堆宏，也可以用十六进制代替二进制。这是我在实际项目里最推荐、最通用的做法。因为每一个十六进制数字对应4个二进制位，换算固定且无歧义：0xF就是1111，0x5就是0101。所以0b10100101写成0xA5，然后在旁边加注释/* 1010 0101 */就够了。既漂亮又不会踩跨平台坑。

2.3 C23怎么看，以及要不要等

C23标准终于加入了二进制字面量，支持0b1010和0B1010，类型推导规则与十六进制字面量相同：会在适当时候尝试unsigned int。可以说，C语言在这个问题上终于补上了长期缺口。

但要不要立刻全面铺开使用？我的建议是：如果项目工具链明确支持C23或对应的扩展，当然可以用；如果还在维护老代码、老工具链，那稳妥方案仍然是“十六进制+二进制注释”。毕竟代码首先要能在所有目标平台上编译通过，写法观赏性是第二位的。等工具链全面跟上，二进制字面量自然会成为主流，但眼下没必要为了这个特性放弃可移植性。

3. 格式化输出：%d、%o、%x背后那点门道

3.1 五个基础转换说明符与#修饰符

printf家族里跟整数进制输出相关的格式符，核心是这几个：

需要注意，%o、%x、%X在语义上都是“无符号格式”。即使你传了一个int变量，printf在内部也是把它解释成无符号位模式来输出。这就是为什么上一节中的int x = -1，用printf("%#x", x)打印出来是0xffffffff，而不是“负的0x1”之类的形式。C语言的有符号负数本质上就是一个位模式，格式化输出时按无符号解释，所以看到的是无符号十六进制的结果。

同理，printf("%o", 8)的输出是10，这个10是八进制，表示“1个8加0个1”，不是十进制十。很多人第一次看到会懵，其实就是八进制进位规则造成的：八进制里根本没有数码8，所以8的自然表示就是10。

3.2 宽度、精度、补零：让输出对齐

实际调试时，光会%x还不够，输出的对齐和补零同样关键。printf的格式控制里有几个重要修饰符：

int v = 0xABC; // 十进制2748 printf("|%8x|\n", v); // | abc| 右对齐，至少8字符宽 printf("|%-8x|\n", v); // |abc | 左对齐 printf("|%08x|\n", v); // |00000abc| 用0填充宽度 printf("|%#08x|\n", v); // |0x000abc| 带前缀，宽度8包含0x两个字符 printf("|%.8x|\n", v); // |00000abc| 精度8，数字部分至少8位 printf("|%#.8x|\n", v); // |0x00000abc| 带前缀，数字部分8位

这里最容易混淆的坑是%#08x和%#.8x的区别。%#08x表示“总显示宽度为8，宽度包含0x前缀”，所以数字部分实际只占6个字符，对于0xABC来说，前三个是0x，后三个是数字abc，中间还要补两个0，得到0x000abc，总长8。而%#.8x表示“数字部分至少要显示8位”，前缀不算在精度里，所以得到0x00000abc，总长度是10。

如果你要打印一个固定位宽的十六进制数，比如RGB颜色值0x00FF7F，%06x就能保证至少6位数字；如果想保留0x前缀同时数字部分补零到6位，应写%#.6x，而不是%#06x——后者会把前缀也算进6个字符里，结果前缀过挤、数字位不足，效果往往不对劲。

3.3 负数和char类型的两个大坑

负数在上面已经提了一半，我再补全。int n = -1在位模式下是0xFFFFFFFF（32位环境）。不管用%d还是%x输出，底层那个位模式没变，变的只是解释方式。%d把它当有符号-1，%x把它当无符号4294967295。所以不要试图写“有符号十六进制”这种东西——C语言的十六进制输出本质上都是无符号位模式。

char类型的坑相比之下更隐蔽。假设你有一个字节数据0x80，想用十六进制打印出来：

char c = 0x80; printf("%02x\n", c);

这段代码在一个默认signed char的平台上，输出往往不是80，而是ffffff80。问题出在可变参数的类型提升上。char类型传给printf时，会被自动提升为int。c的存储值如果是0x80，在用有符号解释时就是-128，提升成int后，符号扩展会把高24位全部补成1，得到0xFFFFFF80，然后%x把这个位模式按无符号打印出来，自然就是ffffff80。

正确写法是先把c转成无符号字符：

printf("%02x\n", (unsigned char)c);

转换后，(unsigned char)c提升为int时值为128，高位不扩展，得到0x80，输出就是干净的80。这个坑在调试通信协议、解析二进制文件时几乎天天遇到，强烈建议把“打印字节值永远先转unsigned char”养成肌肉记忆。

4. 手写一个“能用、能看、能扩展”的二进制输出函数

4.1 最简版：从高位到低位逐位测试

既然标准没有%b，那我自己写一个。最朴素的思路是：从最高位开始，依次判断每一位是0还是1，当场打印。

#include <stdio.h> #include <limits.h> void put_bin_basic(int n) { int bits = CHAR_BIT * (int)sizeof(int); for (int i = bits - 1; i >= 0; --i) { putchar(((n >> i) & 1u) ? '1' : '0'); } putchar('\n'); }

这里的核心是((n >> i) & 1u)。把n右移i位，让第i位落到最低位，再和1做按位与。如果结果是1，就输出字符'1'，否则输出'0'。用1u是为了让无符号字面量和int做运算时，不会发生奇怪的符号转换。CHAR_BIT * sizeof(int)可以算出当前平台int的位数，大多数情况下是32，但在诡异平台上也能自动适应。

这个版本虽然能跑，但有个实用性问题：它固定输出整个int的位宽。你只想看一个字节0xA5时，它会打一堆没用的前导0。而且默认换行，不方便拼接输出。

4.2 升级版：指定位数、四位分组、写进缓冲区

调试时我更常需要的是“只看我关心的那几位”，所以给函数加一个bits参数。同时增加四位一组的空格分隔，让长串二进制肉眼可读。

void put_bin_grouped(unsigned int n, int bits) { for (int i = bits - 1; i >= 0; --i) { putchar(((n >> i) & 1u) ? '1' : '0'); if (i > 0 && i % 4 == 0) { putchar(' '); } } putchar('\n'); }

调用put_bin_grouped(0xA5, 8)会输出1010 0101，一眼就能看出高低四位。参数用unsigned int而非int，是为了避免负数的符号扩展影响i的移位，虽然单看最低位两种写法都能正确输出，但无符号版本语义更干净、不易误用。

如果想把结果保存下来而不是直接打印，可以改成写入缓冲区。实际调试场景里，我经常需要把多个变量的二进制拼进同一个日志字符串，所以“生成字符串”比“直接打印”更通用。

void append_bin_str(unsigned int n, int bits, char *out, size_t cap) { int idx = 0; for (int i = bits - 1; i >= 0 && (size_t)idx + 1 < cap; --i) { if (i != bits - 1 && i % 4 == 3) { if ((size_t)idx + 1 < cap) out[idx++] = ' '; } out[idx++] = ((n >> i) & 1u) ? '1' : '0'; } out[idx] = '\0'; }

这个函数把结果格式化进out缓冲区，cap是缓冲区容量，最后一定补'\0'。分组空格的位置放在每四位之间，生成结果与put_bin_grouped一致。以后你想打印、写文件、拼日志，都能复用。

4.3 查表提速版：适合高频调试

逐位循环优点是简单，缺点是在高频日志场景里有点浪费。每个字节要走8次循环，每次都有移位和按位与。更快的办法是查表：4位二进制对应1位十六进制，那我干脆把16个半字节的二进制字符串存成表，每次查两次就能输出一个字节。

static const char *NIBBLE_BIN[16] = { "0000", "0001", "0010", "0011", "0100", "0101", "0110", "0111", "1000", "1001", "1010", "1011", "1100", "1101", "1110", "1111" }; void put_byte_bin(unsigned char byte) { fputs(NIBBLE_BIN[byte >> 4], stdout); fputs(NIBBLE_BIN[byte & 0x0F], stdout); }

byte >> 4取出高四位作为表下标，byte & 0x0F取出低四位，两次查表后直接输出。少了循环和判断，性能比逐位版本好很多，代码逻辑也更接近“位模式映射”的本质。

如果你要输出多个字节，可以在外层循环里按字节处理，字节之间加空格。这个版本尤其适合嵌入式日志里大量打印寄存器和缓冲区内容的场景。

4.4 把这些函数放进一个可直接复制的小工具

整合一下，给出一个可以直接复制到项目里的完整小工具头。核心是三个函数：put_bin_grouped负责带分组打印，append_bin_str负责落字符串，put_bytes_bin负责按字节打印缓冲区。

#include <stdio.h> #include <limits.h> static const char *NIBBLE_BIN[16] = { "0000", "0001", "0010", "0011", "0100", "0101", "0110", "0111", "1000", "1001", "1010", "1011", "1100", "1101", "1110", "1111" }; static void put_bin_grouped(unsigned int n, int bits) { for (int i = bits - 1; i >= 0; --i) { putchar(((n >> i) & 1u) ? '1' : '0'); if (i > 0 && i % 4 == 0) putchar(' '); } putchar('\n'); } static void append_bin_str(unsigned int n, int bits, char *out, size_t cap) { int idx = 0; for (int i = bits - 1; i >= 0 && (size_t)idx + 1 < cap; --i) { if (i != bits - 1 && i % 4 == 3) { if ((size_t)idx + 1 < cap) out[idx++] = ' '; } out[idx++] = ((n >> i) & 1u) ? '1' : '0'; } out[idx] = '\0'; } static void put_bytes_bin(const unsigned char *buf, size_t len) { for (size_t i = 0; i < len; ++i) { fputs(NIBBLE_BIN[buf[i] >> 4], stdout); fputs(NIBBLE_BIN[buf[i] & 0x0F], stdout); if (i + 1 < len) putchar(' '); } putchar('\n'); } int main(void) { put_bin_grouped(0xA5, 8); // 1010 0101 char s[64]; append_bin_str(0x5A, 8, s, sizeof(s)); printf("buffer: %s\n", s); // buffer: 0101 1010 unsigned char data[] = {0xDE, 0xAD, 0xBE, 0xEF}; put_bytes_bin(data, 4); // 1101 1110 1010 1101 1011 1110 1110 1111 return 0; }

这几个函数足够覆盖九成调试需求。以后想打印寄存器值、协议字节、掩码位型，直接调用即可，不必再依赖调试器的二进制视图。

5. 常见问题与排查技巧实录

5.1 书写阶段：八进制里混入8和9

最典型的编译错误是：error: invalid digit "8" in octal constant。原因很简单，你在一个以0开头的八进制字面量里写了数字8或9，但八进制根本没有这两个数码。比如int a = 018;，编译器会直接报错。

这个错误常出现在你“想写十进制但随手加了前导0”的时候。比如从别处复制来的0644看着像数字，其实是八进制权限；又比如你在写测试数据时把09当成整数，直接编译失败。解决办法是：如果本意是十进制，就去掉前导0；如果本意是八进制，就要保证每一位都在0到7之间。

另外要注意：十六进制前缀是0x，不要写成Ox——那是字母O，不是数字0。这类错误编译器也会提示，但小写o和大写O在注释里尤其容易看混，我见过不止一次有人在注释里写0xFF结果被误看成O xFF。

5.2 输出阶段：前缀、宽度、类型对不上

%#x在值为0时不输出前缀，这是我查了标准实现才确认的细节。#标志的意思是“当结果包含可识别形式时保留它”，但0本身没有“多位形式”，所以不强制加0x。如果你确实需要打印0x0这种形式，只能自己判断并拼字符串。

类型不匹配的问题更要重视。printf的可变参数没有类型检查，你传long long却用%x，编译器顶多给个警告，运行时会按unsigned int大小去读参数，高位数据全部丢失或错位。这属于未定义行为，表现千奇百怪。结论是：格式符和实参类型必须严格对应，int用%x，unsigned int用%#x，long用%lx，long long用%llx。打印size_t值时最好用%zu，不要指望它和unsigned long永远一样大。

5.3 读取阶段：%d和%i的区别，以及scanf的“好心”

很多人不知道scanf里%d和%i是有区别的。%d永远按十进制读取；%i则会根据输入的前缀自动判断进制——0x开头按十六进制，0开头按八进制，否则按十进制。

int a, b; scanf("%d", &a); // 输入012 -> a = 12 scanf("%i", &b); // 输入012 -> b = 10，因为八进制012等于十进制10

这个特性在某些场景下很有用，比如你想让用户既能输入255、0377、0xFF，又能用%i一次搞定。但在大多数日常程序里，%d才是符合直觉的选择。如果你没意识到%i会自动识别进制，用户输入一个带前导0的电话号码或编号，值就会被悄悄解释成八进制，排查起来很头疼。

另外，我建议在需要严格解析“某进制字符串”时，优先用strtol家族，它接受base参数，能精确控制进制，还能通过endptr告诉你解析到哪个字符停止。比如strtol("0xFF", &end, 16)一定能得到255，不会受前缀影响。

结尾：一点实际经验

最后分享一个小习惯。我不管在什么平台写位相关的代码，只要用十六进制字面量表达位掩码，旁边一定跟上二进制注释：

#define MASK_STATUS 0x0F /* 0000 1111 */ #define MASK_CTRL 0xC0 /* 1100 0000 */

这个习惯帮我省了无数查表时间。调试协议时，put_bin_grouped和%#x搭配用，先看十进制/十六进制结果，再看二进制位型，基本能定位绝大多数位操作问题。如果你被某个“莫名奇妙的位运算结果”卡住了，我强烈建议先打印原始字节的二进制位型，再对照掩码逐步推演，而不是盯着十六进制结果硬猜。这一套下来，二进制、八进制、十六进制整数的书写和输出，就真的不会再成为你的绊脚石了。