Java中文乱码本质是编码链路断裂，需系统排查源码编码、javac编译、JVM启动、终端解码四环节；核心在于字节与字符转换时显式指定UTF-8，避免依赖系统默认编码。
Java 中中文乱码问题不是孤立的“bug”，而是一条贯穿文件读写、网络传输、控制台输出、Web请求响应的底层线索。学明白它，关键不在背解决方案，而在理清字符、字节、编码、缓冲区四者之间的转换链条。
为什么中文容易乱码？
因为中文是多字节字符，而 Java 内部用 Unicode（UTF-16）表示字符串，但磁盘文件、网络流、终端设备默认不一定是 UTF-8 或 UTF-16。一旦编码声明和实际字节序列不匹配，解码就出错。
常见场景包括：
- 用
FileReader读文本文件，没指定编码 → 默认用系统编码（Windows 是 GBK，Linux/macOS 是 UTF-8），读 UTF-8 文件就乱 - 用
FileOutputStream写中文，没包装成OutputStreamWriter→ 直接写 char 的低字节，丢数据 - Servlet 接收 POST 表单，没调
request.setCharacterEncoding("UTF-8")→ 容器按 ISO-8859-1 解码 - 控制台打印中文，IDE 或终端编码设为 GBK，但程序输出的是 UTF-8 字节 → 显示为方块或问号
怎么系统性地掌握？
从三个层次入手，层层递进：
立即学习“Java免费学习笔记（深入）”；
字节层（IO 流基础）
记住：InputStream/OutputStream处理的是原始字节，不认字符。
✅ 写中文必须用OutputStreamWriter包装输出流，并显式指定"UTF-8"编码
✅ 读中文必须用InputStreamReader包装输入流，同样指定"UTF-8"
❌ 避免直接用FileReader/FileWriter—— 它们不接受编码参数，依赖系统默认，极不可靠字符层（String 与编码转换）
String在内存中是 Unicode，转字节要用getBytes("UTF-8")，从字节构建字符串要用new String(bytes, "UTF-8")。
⚠️ 不带编码参数的getBytes()或new String(bytes)会用系统默认编码，跨平台必翻车-
应用层（Web 场景专项）
- POST 请求：在
doPost开头第一行加request.setCharacterEncoding("UTF-8") - GET 请求：Tomcat 8+ 默认 URI 编码是 UTF-8，但旧版本需在
server.xml的Connector中加URIEncoding="UTF-8" - 响应输出：
response.setContentType("text/html;charset=UTF-8")+response.setCharacterEncoding("UTF-8")（后者可省，但写上更清晰） - JSP 页面：顶部加
<%@ page contentType="text/html;charset=UTF-8" %>
- POST 请求：在
实操建议：三步验证法
每次遇到乱码，按顺序检查：
- 源文件本身保存为什么编码？（用编辑器看，推荐 VS Code 或 IDEA 右下角编码标识）
- 程序读/写时是否明确指定了编码？
- 终端、浏览器、数据库连接等“接收端”是否配置为匹配的编码？
不复杂但容易忽略
