InputStreamReader严格按指定字符集解码字节流，不自动识别编码；乱码主因是编解码不一致，须显式指定如StandardCharsets.UTF_8；常与BufferedReader配合实现高效按行读取。
Java 中 InputStreamReader 在读取 Socket 字节流时，本身不“解析”编码，而是**严格按你指定的字符集进行解码**——它不做猜测、不自动识别，只忠实地把收到的字节序列，按你给定的编码规则（如 UTF-8）翻译成 Unicode 字符。乱码的根本原因，几乎总是“传入的编码与实际字节编码不一致”。
必须显式指定编码，不能依赖默认值
Socket 传输的是原始字节，没有自带编码声明。系统默认编码（如 Windows 的 GBK 或 Linux/macOS 的 UTF-8）与服务端实际发送的编码极易不匹配。例如：
- 服务端用 UTF-8 发送中文，客户端用
new InputStreamReader(socket.getInputStream())（无参构造）→ 按系统默认编码解码 → 极大概率乱码； - 正确做法是明确传入
StandardCharsets.UTF_8：new InputStreamReader(socket.getInputStream(), StandardCharsets.UTF_8)。
编码一致性需由通信双方约定
InputStreamReader 不会检测或协商编码，它只执行你指令的转换。因此：
Audio Upload Aioz Stream Free
下载
基于 AIOZ Stream API 的免费音频上传技能，通过三步流程（Create → Upload Part → Complete）将本地音频文件上传至 AIOZ 流媒体平台。支持默认快速上传方式，使用默认编码配置，上传完成后返回 HLS 流媒体播放链接。使用 API Key (stream-publ...)进行认证。
- 服务端写入时用了什么编码（如
OutputStreamWriter指定 UTF-8），客户端就必须用相同编码读取； - HTTP 协议中可通过
Content-Type: text/plain; charset=utf-8声明，但纯 Socket 无此机制，必须在协议设计阶段约定死； - 若协议允许动态编码（如自定义头部含
charset=gbk），需先读取头部、提取编码名，再构建对应的InputStreamReader实例。
配合 BufferedReader 提升实用性
单独用 InputStreamReader 只能读字符或字符数组，实际开发中通常包装为 BufferedReader 以支持按行读取（readLine()）：
- 缓冲能减少底层系统调用次数，提升性能；
-
readLine()自动识别\n、\r\n等换行符，适合文本协议（如 HTTP、自定义命令行协议）； - 注意：缓冲区大小可调（如
new BufferedReader(reader, 16384)），大文本或高吞吐场景下值得优化。
避免常见陷阱
几个高频出错点：
-
混用字节流与字符流：直接对
socket.getInputStream()调用read()得到 int（0–255），再用new String(byteArray)转字符串 —— 此时若未指定编码，会走平台默认编码，极易错； -
忽略流关闭顺序：应先关闭外层
BufferedReader，它会自动关闭内部InputStreamReader和底层InputStream；手动关闭底层流可能引发异常； -
误信“自动识别”：Java 没有内置的 BOM 检测或编码启发式分析（如 ICU 库才支持），
InputStreamReader绝不会尝试猜编码。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
