Java中文乱码主因是UTF-8与GBK混用，核心在于字节与字符的编码匹配；GBK为Windows中文系统常用双字节编码，UTF-8为全球通用变长编码，Java内部统一用Unicode，实际编码由IO操作时指定Charset决定。
Java里处理中文，最常踩的坑就是UTF-8和GBK混用导致乱码。问题不在代码写错，而在字节和字符之间的“翻译”没对上——一边用UTF-8写，另一边用GBK读，就像拿英文说明书装中文家电，结果全拧了。
核心差异：不是“谁更好”，而是“谁在哪用”
GBK和UTF-8本质是两套不同的“翻译词典”：
- GBK是中文环境的老标准，双字节为主，Windows中文系统默认用它（比如CMD、记事本“ANSI”保存时）。一个汉字固定占2个字节，效率高，但只覆盖中日韩部分字符，不支持emoji或生僻少数民族文字。
- UTF-8是全球通用方案，变长编码（1–4字节）：英文仍为1字节，汉字通常3字节。完全兼容ASCII，Web、Linux、现代IDE（IntelliJ/VS Code）默认都用它，跨平台协作更稳。
- Java内部统一用Unicode（实际存为UTF-16），所以String本身没“UTF-8”或“GBK”属性——真正起作用的是你读文件、发HTTP、写日志时用的
Charset。
常见乱码场景与直接解法
乱码不是随机发生，基本就三类源头，每种都有对应fix：
-
编译.java源文件报错“不可映射字符”：说明你的.java文件是UTF-8保存的，但javac在GBK环境下读它。解决方法：加参数强制指定编码
javac -encoding UTF-8 YourClass.java -
控制台输出中文变成问号或方块：可能是终端（CMD/PowerShell）编码没切到UTF-8，或程序没指定输出编码。Windows CMD下先执行：
chcp 65001（切换为UTF-8），再运行Java程序；或者用IDE运行，避免命令行干扰。 -
读取文本文件内容乱码：用错解码器。比如文件是GBK写的，却用
Files.readString(path, StandardCharsets.UTF_8)读——必须匹配原始编码：Files.readString(path, Charset.forName("GBK"))
安全转换字符串的写法
Java做编码转换，关键不是“转两次”，而是“明确输入和输出编码”。别用new String(bytes)这种无参构造，它依赖系统默认编码，极不可靠。
立即学习“Java免费学习笔记（深入）”；
-
GBK字节数组 → 正确UTF-8字符串：
String utf8Str = new String(gbkBytes, "GBK"); // 先按GBK解码成Unicode字符串<br>byte[] utf8Bytes = utf8Str.getBytes(StandardCharsets.UTF_8); // 再按UTF-8编码
-
读GBK文件转UTF-8内容（推荐NIO）：
String content = Files.readString(Paths.get("a.txt"), Charset.forName("GBK")); // 直接读成String<br>Files.writeString(Paths.get("b.txt"), content, StandardCharsets.UTF_8); // 直接写UTF-8 -
避免手动拼接getBytes() + new String()：容易因中间String隐式使用默认编码出错。一步到位用
InputStreamReader或FilesAPI更稳妥。
新项目建议：拥抱UTF-8，少碰GBK
JDK 18起已将UTF-8设为默认编码，意味着FileReader、Files.readString()等API不再看系统环境，统一用UTF-8。这对新项目是利好：
- 所有源码、配置文件、接口响应默认存UTF-8，省去反复指定编码的麻烦；
- 跨团队、跨服务器部署不再因GBK/UTF-8不一致导致线上乱码；
- 遗留GBK数据只需在读取环节显式声明
Charset.forName("GBK")，其余流程保持UTF-8主线。
编码问题不复杂，但容易忽略细节。抓住“字节→字符→字节”这个链条，每次IO操作都明确编码，就能避开90%的乱码陷阱。
