Java中文乱码本质是字节与编码不匹配，发生在String与字节流转换时；内存中String始终为UTF-16，乱码源于输入/输出侧未显式指定编码，导致JVM按默认（如GBK或ISO-8859-1）错误解码。
搞懂Java中文乱码，关键不是背概念，而是看清“字节”在哪儿被谁、用哪本“密码本”翻译错了。乱码几乎从不发生在存储环节，而总出现在读取或转换的那一刻——比如你用UTF-8存的字节，却被GBK去解；或者JVM默认按ISO-8859-1解HTTP请求，而浏览器实际发的是UTF-8。
Java字符串内部永远是Unicode，但进出时全靠编码转换
Java的String对象在内存里始终以UTF-16（逻辑上接近Unicode码点）表示，这是它和底层字节流之间的“分水岭”。所有乱码都发生在这条分水岭的两侧：
- 输入侧：文件读取、网络接收、数据库查询 → 字节 → String（需指定编码）
- 输出侧：文件写入、网络发送、数据库插入 → String → 字节（需指定编码）
一旦任一侧没明确指定编码，JVM就用file.encoding系统属性（常为平台默认值，如Windows是GBK，Linux/macOS多是UTF-8），这就埋下第一颗雷。
三大高频乱码场景及定位要点
不用猜，按顺序检查这三处，80%的乱码能立刻定位：
立即学习“Java免费学习笔记（深入）”；
- 源文件编码 vs 编译器编码不一致：记事本保存为ANSI（即GBK），但IDEA/Maven默认用UTF-8编译 → 字符串字面量注释直接变乱码。解决：统一设为UTF-8（IDEA中File → Settings → Editor → File Encodings）
- HTTP请求未声明charset：表单提交时没加accept-charset="UTF-8"或request.setCharacterEncoding("UTF-8")调用太晚（必须在getParameter()前）→ request.getParameter()拿到的就是ISO-8859-1解出来的错码
- JDBC连接未启用Unicode：MySQL URL漏掉useUnicode=true&characterEncoding=UTF-8 → 即使数据库字段是utf8mb4，驱动仍可能用latin1传数据
排查时盯住“字节”本身，别信肉眼看到的字符
当看到“锟斤拷”“???”或“æ–‡”时，别急着改编码。先用工具看原始字节：
- Linux/macOS：xxd file.txt 或 file -i file.txt
- Java里打印字节数组：System.out.println(Arrays.toString(str.getBytes(StandardCharsets.UTF_8)))
比如“中文”在UTF-8中是[-28, -67, -96, -27, -91, -67]，若你看到[-60, -29, -60, -29]，基本可断定是GBK字节被当UTF-8解了两次——这就是“锟斤拷”的典型字节特征。
一招治本：全程显式指定编码，拒绝默认
Java API大多提供带Charset参数的重载，优先使用它们：
- 文件读写：Files.readAllLines(path, StandardCharsets.UTF_8)
- 流转换：new InputStreamReader(in, StandardCharsets.UTF_8)
- 网络响应：response.setContentType("text/html; charset=UTF-8")
- 启动参数：java -Dfile.encoding=UTF-8 ...（仅作兜底，不能替代显式指定）
记住：不写Charset参数，等于把翻译权交给JVM猜——而它猜错的概率，远高于你手动写一次。
