在Java中InputStream和Reader如何选择_Java字节流与字符流解析_技术教程

必须用InputStream处理原始二进制数据，如图片、音频、ZIP、HTTP响应体等；用Reader仅限已知编码的文本，须通过InputStreamReader显式指定编码（如UTF-8），避免默认编码导致乱码。

什么时候必须用 `InputStream`？

当你处理的不是文本，而是原始二进制数据时，InputStream 是唯一选择。比如读取图片、音频、ZIP 文件、网络协议包（HTTP 响应体未解码前）、加密后的字节流等。

关键判断点：如果数据里可能包含 0x00～0xFF 任意字节，且你不能丢失或误解释其中任何一个字节，就必须用 InputStream。

InputStream.read() 返回 int（-1 表示 EOF，0～255 是实际字节值），不会做任何编码转换
直接包装成 BufferedInputStream 或 DataInputStream 可高效读取结构化二进制数据
不要尝试用 InputStream 读中文文本——它不理解字符边界，会把 UTF-8 多字节序列拆开，导致乱码

什么时候该用 `Reader`？

只在明确知道数据是文本，并且你知道它的字符编码时，才用 Reader 及其子类（如 InputStreamReader、BufferedReader）。

典型场景：读取配置文件（application.properties）、日志文本、JSON/XML 原文、用户提交的表单内容等。

Reader.read() 返回的是 Unicode 码点（int，范围 0～65535），已经按指定编码完成字节→字符转换
必须通过 InputStreamReader 将 InputStream 转为 Reader，且显式传入编码（如 new InputStreamReader(in, "UTF-8")），否则依赖平台默认编码（Windows 是 GBK，Linux/macOS 通常是 UTF-8），极易出错
用 BufferedReader 的 readLine() 比 InputStream 自己按 \n/\r\n 切分更可靠，它能正确处理不同换行符和编码边界

`InputStreamReader` 是桥，不是透明管道

InputStreamReader 不是“把字节流转成字符流就完事了”，它内部有解码缓冲区，行为受编码方式和输入节奏影响。

遇到不合法字节序列（如 UTF-8 中孤立的 0xC0），默认抛 MalformedInputException；可设 CodingErrorAction.REPLACE 替换为
如果底层 InputStream 分多次返回字节（如网络流中一个汉字的 UTF-8 三字节被拆成两次 read()），InputStreamReader 会缓存未完成的字节，等齐了再输出字符——你不需要自己处理“半截 UTF-8”
但这也意味着：调用 reader.read() 后，底层 InputStream 可能已多读了几字节（被缓存在解码器里），所以别在同一个 InputStream 上混用 InputStream 和 Reader 操作

常见错误与绕过陷阱的写法

最常踩的坑是忽略编码声明，或误以为 String.getBytes() 和构造 String(byte[]) 是对称操作。

// ❌ 错误：没指定编码，依赖系统默认
Reader reader = new InputStreamReader(inputStream);

// ✅ 正确：显式声明 UTF-8（除非你确定要其他编码）
Reader reader = new InputStreamReader(inputStream, StandardCharsets.UTF_8);

// ❌ 错误：认为 getBytes() 默认编码 = 构造 String 的默认编码
byte[] bytes = str.getBytes(); // 实际用平台默认编码
String s = new String(bytes); // 也用平台默认编码 —— 看似能 round-trip，但跨环境就崩

// ✅ 安全写法：始终绑定编码
byte[] bytes = str.getBytes(StandardCharsets.UTF_8);
String s = new String(bytes, StandardCharsets.UTF_8);

另一个隐形