inputstreamreader 不支持动态切换字符编码，因其构造时绑定固定 charset，内部 charsetdecoder 状态与编码强绑定，中途更换会导致多字节序列截断、缓冲区字节无法重用且无编码变更通知机制。
Java 中 InputStreamReader 本身不支持在流读取过程中动态切换字符编码。它在构造时绑定一个固定的 Charset（或通过名称查表得到），后续所有字节都按该编码解码，无法感知或响应中途的编码变化。
为什么不能动态切换编码
InputStreamReader 是基于字节流到字符流的桥接器，其内部使用 CharsetDecoder 进行一次性解码。该解码器状态（如多字节序列的中间状态、BOM 处理逻辑）与编码强绑定。一旦开始解码，中途更换 CharsetDecoder 会导致：
- 当前未完成的多字节序列（如 UTF-8 的 2~4 字节字符）被截断或误判；
- 缓冲区中已读但未解码的字节无法安全重用；
- 无标准机制通知上层“此处编码已变”，更无回调或钩子支持。
实际场景中常见的“中途换编码”来源
所谓“流中途切换编码”，通常不是协议设计的正常行为，而是以下情况导致的误判：
- 混合编码文本文件：如部分行用 GBK、部分用 UTF-8（常见于手工拼接或日志合并）；
- BOM 混乱：文件开头有 UTF-8 BOM，但后续内容实为 GB2312，或多个 BOM 交错出现；
- HTTP 响应体编码不一致：Header 声明 UTF-8，但实际 HTML meta 标签指定 GBK，且服务端未严格遵守；
- 串口/设备原始数据流：不同命令返回的响应使用不同编码（需靠协议字段识别，非纯文本流）。
可行的替代方案
绕过 InputStreamReader 的静态限制，需在字节层面做控制：
-
分段读取 + 显式解码：先用
InputStream读取一段原始字节（如按行、按分隔符、按长度），再根据上下文判断编码，调用new String(bytes, charset)或StandardCharsets.UTF_8.decode(ByteBuffer)解码； -
带编码探测的封装类：对每块数据调用
CharsetDetector（如 ICU4J）或轻量库（如 juniversalchardet），再选择对应Charset解码； -
协议层预处理：若来自网络或设备，应在解析协议帧时提取编码标识字段（如 HTTP Content-Type、自定义 header、报文头 flag），再创建对应的
InputStreamReader实例处理该帧； -
统一转码为 UTF-8 再处理：对已知可能编码的输入，先用
InputStream全部读入 byte[]，依次尝试常见编码解码成字符串，再转存为 UTF-8 字节数组，最后用new InputStreamReader(new ByteArrayInputStream(utf8Bytes), StandardCharsets.UTF_8)安全读取。
不推荐的做法
试图通过反射修改 InputStreamReader 内部 CharsetDecoder，或继承重写其 read() 方法——这些方式破坏封装、依赖 JDK 内部实现、极易出错且不可移植。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
