为何Java允许printf用%c输出int，却禁止用%d直接输出char？

核心原因：Formatter类的参数转换逻辑不同 #

Java的System.out.printf底层依赖java.util.Formatter类，它对不同格式符的参数处理规则是分开设计的：

1. %c能接受int的原因 #

当使用%c格式符时，Formatter会自动处理int类型参数：

• 它会执行窄化原始类型转换，把int截断为16位的char（Java中char是无符号16位类型，范围0~65535）。
• 哪怕int值超出char的范围（比如大于65535或小于0），API依然允许这种转换——这是为了方便开发者直接用ASCII/Unicode码值输出对应字符，故意放宽了限制，哪怕存在值丢失风险。

对应示例：

System.out.printf("%c%n", 112); // 112是小写p的ASCII码，自动转char输出'p'
System.out.printf("%c%n", 'p'); // char类型直接匹配%c，正常执行

2. %d不能直接接受char的原因 #

当使用%d格式符时，Formatter要求参数必须是整数类型（byte、short、int、long、BigInteger），而char在Java类型体系里是独立的字符类型，不属于整数类型范畴：

• Formatter没有为%d设计自动将char转成int的逻辑，哪怕char的数值范围完全被int覆盖、不存在丢失风险。
• 必须通过显式强制转换(int) 'p'，把char转成int类型，才能符合%d的参数要求。

对应示例：

System.out.printf("%d%n", 'p'); // 报错：类型不匹配，char不符合%d的参数要求
System.out.printf("%d%n", (int) 'p'); // 显式转int后，输出112，正常执行

本质：API设计的取舍 #

这种差异不是技术上做不到，而是API设计时的取舍：

• %c的场景下，开发者更常用“用码值输出字符”的需求，所以允许自动窄化转换，哪怕有风险。
• %d的场景下，Formatter更严格遵循类型匹配，避免隐式转换可能带来的混淆（毕竟char本质是字符类型，不是数值类型，隐式转int可能不符合开发者的直观预期）。

内容的提问来源于stack exchange，提问作者Pedro Siqueira