直接用(char)ins.read()读中文必乱码，因java的char是16位unicode码元，而中文在utf-8中占3字节、gbk中占2字节，单字节强转会截断编码导致错误字符。
直接用 (char)ins.read() 读中文，基本必乱码——这不是 bug，是设计使然。Java 的 char 是 16 位 Unicode 码元，而 byte 是 8 位有符号整数；中文在 UTF-8 中占 3 字节、在 GBK 中占 2 字节，单个 byte 强转成 char 只能拿到“半个字”，自然变成 '?' 或其他不可预料字符。
理解 char 和 byte 的本质差异
中文不是单字节字符，不能按 ASCII 方式逐字节强转处理：
-
byte表示一个 0–255（或 -128–127）范围内的原始字节，不携带编码语义 -
char在 Java 中是 UTF-16 编码的码元，用于表示 Unicode 字符（如'你'对应\u4f60） - 把一个 GBK 编码的中文字节（比如
0xC4）直接转成char，得到的是\u00C4（即拉丁字母 “Ä”），完全不是原意 - UTF-8 下中文是多字节序列（如
0xE4 0xBD 0xA0），拆开强转会彻底破坏语义
排查强转导致的乱码典型表现
遇到以下现象，大概率是 byte → char 强转惹的祸：
- 读取文件或网络流后，中文显示为
???、、方块或乱码字母（如ÄãºÃ） - 字符串长度正常，但内容错乱，且错乱位置与中文出现位置严格对应
- 使用
System.out.println((int)ch)打印出的数值远小于 0x4E00（汉字起始 Unicode 码点） - 用
String.valueOf((char)b)处理每个字节后拼接，结果无法还原原文
正确替代方案：绕过强转，走标准编码路径
不要手动拼 char，而是把字节完整收集后再按指定编码解码：
- 用
InputStreamReader包装输入流，并显式传入编码：new InputStreamReader(in, StandardCharsets.UTF_8) - 若必须操作原始字节数组，先完整读入
byte[]，再调用new String(bytes, StandardCharsets.UTF_8) - 避免
read() == -1循环中逐字节强转；改用read(byte[] b)批量读取 - 如需兼容旧代码中的字节队列逻辑，确保所有字节收齐后再整体解码，而不是边读边转
char
验证是否修复的小技巧
加两行日志快速确认问题是否根除：
- 打印原始字节数组（十六进制）：
Arrays.toString(Arrays.stream(bytes).mapToObj(b -> String.format("%02X", b)).toArray()) - 打印解码后字符串的 Unicode 码点：
s.chars().forEach(c -> System.out.printf("U+%04X ", c))，确认输出是U+4F60 U+597D而非U+00C4 U+00E3
