Java中int转char两种场景报错差异：为何FileInputStream.read()赋值报错？

这事儿得从Java的类型转换规则和read()方法的返回值设计两方面拆解：

先看char b=87;的情况 #

Java里的char是无符号16位整数类型，合法取值范围是0到65535。当你直接写87这种整数字面量时，编译器会立刻校验这个值是否落在char的范围内——87显然在0-65535区间里，所以它允许隐式转换，不仅不会报错，还会自动把数值映射成对应的Unicode字符（87对应的就是大写字母'W'）。

再看in.read()的情况 #

FileInputStream.read()的返回值是int类型，这个设计藏着特殊逻辑：

• 正常读取到一个字节时，返回0到255之间的整数（因为一个字节是8位无符号数）；
• 当读到文件末尾、没有更多数据时，返回-1用来标记结束状态。

问题的核心就在这个-1上：char是无符号类型，根本无法表示负数。编译器没办法提前预判in.read()返回的int值到底是0-255的有效字节，还是-1的结束标记。如果允许隐式转换，当返回-1时，就会发生损失性转换（-1转成char会变成\uffff，这显然不是我们想要的文件结束信号）。

所以Java编译器会严格要求你做显式强制转换，比如写成：

char c = (char) in.read();

不过这么写的时候，你得自己额外判断返回值是不是-1，不然会把文件结束符当成普通字符处理，导致逻辑错误。

补充个细节 #

哪怕read()正常返回的0-255都在char的范围内，编译器也不会去分析方法的业务逻辑——它只会看int类型的理论取值范围（-2^31到2^31-1），这个范围远大于char的0-65535，所以只要是从不确定范围的int变量（或方法返回值）转char，编译器就会提示可能的损失转换。

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