fprintf 格式化输出：%f、%d、%s、\n 占位符对照，保留两位小数 %.2f 示例

一、格式化输出的本质：从接口契约说起

要真正理解 fprintf，不能只停留在"记住占位符"的层面。格式化字符串本质上是一份运行时的接口契约：它用纯文本描述了一组待传入参数的类型、顺序和布局。编译器在大多数情况下无法验证这份契约是否被遵守，于是类型不匹配的代价被推迟到运行时，表现为乱码、崩溃或更隐蔽的内存破坏。

这一设计源于 C 语言的变参函数（variadic function）机制。1970 年代 Dennis Ritchie 在贝尔实验室设计 printf 家族时，选择了"格式串驱动"的方案，而非后来 C++ 的流式操作符重载。本文评述：这一选择在当时是务实的——它让格式化逻辑与语言核心解耦，代价是把类型检查的责任完全交给了程序员。半个世纪后，C++20 的 std::format 用编译期格式串解析重新收回了这份责任，某种程度上是对当年妥协的"技术债偿还"。

从信息论角度看，格式化字符串携带的信息量远大于它表面上显示的字符数。一个 "%d" 至少编码了三层信息：参数位置（下一个）、参数类型（有符号整数）、输出形式（十进制）。当格式串与实参在任一层不匹配时，契约即告破裂。理解这一点，是掌握所有占位符的前提。

二、fprintf 函数族全景与调用链

C 标准库（ISO/IEC 9899）定义了一组以 printf 为原型的格式化输出函数，它们共享同一套转换说明语法，区别仅在于输出目标。

这些函数最终都汇聚到 vfprintf 这一核心实现上。以 glibc 为例，其内部通过 printf_buffer 结构体管理输出缓冲，逐字符扫描格式串，遇到 % 便进入转换说明解析状态机。笔者认为，理解这条调用链对性能调优至关重要：高频日志场景下，fprintf 的格式串解析开销不可忽略，这也是后来许多日志库（如 spdlog）在编译期预解析格式串的动因。

一个常被忽视的事实是：fprintf 的返回值是成功写入的字符数，负数表示出错。在写文件或网络流时，检查这个返回值是健壮代码的基本要求，但实践中大量代码直接忽略它。本文评述：忽略返回值在本地文件场景下问题不大，但在管道、套接字或磁盘满的情况下，静默的数据丢失往往比崩溃更难排查。

三、转换说明的完整语法结构

一个完整的转换说明（conversion specification）并非只有 %d 这么简单。它的标准形式为：

%[flags][width][.precision][length]specifier

五个部分各司其职，缺一不可地构成了完整的输出语义。下面逐段拆解。

3.1 标志位（flags）

3.2 宽度与精度

宽度（width）指定最小字段宽度，不足时按标志位填充；精度（precision）以点号开头，对浮点数表示小数位数，对字符串表示最大字符数。二者都可以用 * 动态指定，从参数中取值。

printf("%*.*f\n", 10, 2, 3.14159);  // 输出 "      3.14"

动态宽度在生成对齐表格时极为有用，但也是类型错误的温床——* 对应的参数必须是 int，传 long 或 size_t 会在 64 位平台上引发未定义行为。

3.3 长度修饰符（length modifier）

长度修饰符解决的是"参数实际宽度与默认宽度不符"的问题。这是格式化输出中最容易出错的部分之一。

本文评述：%zu 是 C99 引入的实用改进，专门用于 sizeof 和容器大小输出。在 32 位向 64 位迁移的历史中，把 %d 直接用于 size_t 是导致大量移植 bug 的经典原因。GCC 的 -Wformat 系列警告能捕获大部分此类问题，务必开启。

四、整数占位符：%d、%i、%u、%x、%o 详解

4.1 %d 与 %i 的微妙差异

在 printf 输出场景下，%d 与 %i 完全等价，都输出有符号十进制整数。它们的差异只体现在 scanf 输入场景：%i 会根据前缀自动识别进制（0x 十六进制、0 八进制），而 %d 只认十进制。本文评述：这种"同名不同义"的设计是 C 标准库的历史包袱，建议输出场景统一用 %d，避免团队协作时的认知负担。

4.2 无符号与进制转换

unsigned int n = 255;
printf("%u\n", n);    // 255      十进制无符号
printf("%o\n", n);    // 377      八进制
printf("%x\n", n);    // ff       十六进制小写
printf("%X\n", n);    // FF       十六进制大写
printf("%#x\n", n);   // 0xff     带前缀
printf("%#o\n", n);   // 0377     带前缀

十六进制输出在调试内存、颜色值、哈希摘要时无处不在。一个实用技巧是用 %02x 保证每个字节固定两位，这在打印字节数组时能避免对齐错乱：

for (size_t i = 0; i < len; i++)
    fprintf(fp, "%02x", buf[i]);   // 输出如 "0a1b2c"

这里 %02x 中的 0 是零填充标志，2 是最小宽度。注意 buf[i] 是 unsigned char，会经历默认实参提升（default argument promotion）变为 int，因此 %x 是安全的；若用 %hhx 则更精确地表达意图。

4.3 指针与 %p

%p 专门用于输出 void* 指针，标准未规定具体格式，glibc 输出 0x 前缀加小写十六进制。把其他类型指针传给 %p 在严格意义上需要显式转换为 void*，虽然实践中几乎总是可行，但标准并不保证。

五、浮点占位符：%f、%e、%g 与 %.2f 精度控制

5.1 三种浮点转换的本质

注意 %f 默认精度是 6 位小数，这是很多初学者看到 3.14 被打印成 3.140000 时困惑的原因。

5.2 %.2f 保留两位小数：精度控制的核心

%.2f 是工程中最常用的浮点格式，用于金额、测量值、百分比等需要固定小数位的场景。它的语义是：输出定点格式，小数点后恰好两位。

double price = 19.9;
printf("%.2f\n", price);      // 19.90
printf("%.2f\n", 3.14159);    // 3.14
printf("%.2f\n", 2.675);      // 2.67  ← 注意！
printf("%.2f\n", 2.685);      // 2.69  ← 注意！

上面 2.675 输出 2.67 而非直觉上的 2.68，这是格式化输出最经典的"坑"之一。原因在于 2.675 在 IEEE 754 双精度下无法精确表示，其实际存储值略小于 2.675，因此舍入到 2.67。

本文评述：这不是 printf 的 bug，而是二进制浮点的固有特性。任何声称"四舍五入"的浮点格式化都受此影响。对金额等要求精确十进制的场景，正确做法是使用整数分单位存储，或采用十进制浮点库（如 GCC 的 _Decimal64、Intel 的 Decimal Floating-Point 库）。

5.3 舍入模式与 IEEE 754

C 标准规定 printf 的浮点转换使用当前舍入方向（rounding direction），默认是"就近舍入，偶数优先"（round-half-to-even）。这意味着 2.5 会舍入到 2，3.5 舍入到 4。可通过 fesetround() 修改，但会影响整个线程的浮点行为，需谨慎。

关于 IEEE 754 浮点格式的权威参考，可查阅 IEEE 标准文档及 David Goldberg 的经典论文《What Every Computer Scientist Should Know About Floating-Point Arithmetic》（ACM Computing Surveys, 1991）。国内可参考 cplusplus.com 的 printf 参考 与 cppreference 的 fprintf 条目。

5.4 %f 与 double/long double 的类型对应

一个关键细节：在变参函数中，float 会被自动提升为 double，因此 %f 对应的是 double 而非 float。要输出 long double，必须用 %Lf（大写 L）。

float  f = 1.5f;
double d = 1.5;
long double ld = 1.5L;

printf("%f\n",  f);    // OK，f 提升为 double
printf("%f\n",  d);    // OK
printf("%Lf\n", ld);   // 必须用 %Lf
printf("%f\n",  ld);   // 未定义行为！

六、字符串与字符：%s、%c 与空指针陷阱

6.1 %s 的精度语义

对 %s 而言，精度表示最大输出字符数，而非小数位数。这是一个常被误用的特性：

printf("%.3s\n", "hello");   // hel  只输出前 3 个字符
printf("%10.3s\n", "hello"); //        hel  宽度 10，右对齐
printf("%-10.3s|\n", "hello"); // hel       |  左对齐

本文评述：%s 的精度是防止缓冲区溢出的天然工具。在日志系统中截断超长字符串时，用 %.256s 比先 strncpy 再输出更简洁高效。但要注意：精度限制的是输出字符数，printf 仍会读取源字符串直到遇到 \0 或达到精度上限，因此它不能防止源字符串本身未终止的问题。

6.2 NULL 指针的未定义行为

把 NULL 传给 %s 是未定义行为。glibc 出于兼容性会打印 (null)，但这是实现扩展，不可依赖。跨平台代码必须显式判空：

fprintf(fp, "%s\n", name ? name : "(null)");

6.3 %c 与宽字符 %lc

%c 输出单个 int 参数（会转换为 unsigned char）。处理多字节字符（如中文）时，%c 只能输出单字节，需要配合 %s 输出整个 UTF-8 序列，或用 %lc 配合 wchar_t。在 UTF-8 环境下，%c 输出中文单字会得到乱码，这是新手常见困惑。

七、宽度、精度与标志位的组合艺术

把标志、宽度、精度组合起来，fprintf 能生成相当规整的文本报表。下面是一个对齐的财务表格生成示例：

struct Item { const char *name; int qty; double price; };

fprintf(fp, "%-20s %8s %12s\n", "商品", "数量", "金额");
fprintf(fp, "%-20s %8s %12s\n", "----", "----", "----");
for (size_t i = 0; i < n; i++) {
    fprintf(fp, "%-20s %8d %12.2f\n",
            items[i].name, items[i].qty, items[i].qty * items[i].price);
}

输出效果：

商品                       数量         金额
----                       ----         ----
苹果                          10        39.80
香蕉                           5        12.50

这里 %-20s 左对齐字符串，%8d 右对齐整数，%12.2f 右对齐两位小数金额。本文评述：这种"手工对齐"在纯 C 项目里依然是最轻量的方案，但一旦涉及中文（等宽字体下中文占 2 个字符宽度）就会错位，此时需要按显示宽度而非字节数计算填充。

一个进阶技巧是用 %+d 显示带符号的差值，用 % d 保持正负号占位一致，在生成对比报表时非常实用。

八、类型安全陷阱与未定义行为

8.1 最常见的五类错误

1. 类型不匹配：用 %d 输出 long long，在 64 位平台上会读取错误的栈偏移。
2. 参数数量不符：格式串要求 3 个参数却只传 2 个，后续读取的是栈上的垃圾值。
3. 长度修饰符缺失：size_t 用 %d 而非 %zu。
4. 格式串注入：把用户输入直接作为格式串传给 printf，攻击者可用 %n 写内存。
5. 缓冲区溢出：用 sprintf 而非 snprintf。

8.2 %n 的危险性

%n 是唯一会写入内存的转换说明，它把已输出字符数写入对应 int* 参数。这使它成为格式化字符串漏洞（format string vulnerability）的核心武器。C11 标准附录 K 建议实现禁用 %n，glibc 2.35 起默认在 _FORTIFY_SOURCE 下限制其使用。

本文评述：格式化字符串漏洞在 CWE 分类中编号 CWE-134，是 OWASP Top 10 的常客。防御原则很简单——永远不要把不可信输入作为格式串，正确写法是 printf("%s", user_input) 而非 printf(user_input)。关于该漏洞的经典分析，可参考 OWASP 格式化字符串攻击条目。

8.3 编译期检查工具

现代编译器提供了强大的格式串检查能力：

🔒 复制本站文章内容需登录并达到 L3。当前：未登录