Java字符串底层用byte[]+coder存储，Latin-1或UTF-16编码；乱码根源在于源文件、JVM默认编码、I/O显式编码三者未对齐，关键要确保字节流与字符流转换时编码严格一致。
从底层搞懂 Java 中的字符编码，关键不是背概念，而是顺着“数据怎么来、怎么存、怎么转”这条线，一层层拆开看。重点不在记住 UTF-8 几个字节，而在于理解 每个环节的编码选择如何影响实际行为 —— 比如读文件时乱码、控制台输出错位、网络传输变问号，根源全在线上这几步是否对齐。
先看清 Java 字符串的“真实长相”
Java 的 String 不是直接存字符，而是存编码后的字节序列，但具体怎么存，版本不同、内容不同，方式也不同：
- JDK 9+：底层是
byte[] + coder（coder=0表示 Latin-1 编码，1 字节/字符；coder=1表示 UTF-16 编码，通常 2 字节/字符） - 字符串里全是英文或数字时，JVM 自动选 Latin-1 节省内存；一旦出现中文、emoji，就切到 UTF-16
- 注意：
char类型始终是 2 字节（UTF-16 code unit），但它不等于一个“字符”——比如 ? 这个 emoji 在 UTF-16 中占 2 个char（代理对），但只是 1 个 Unicode 字符（U+1F30D）
真正决定“能不能显示对”的是三处编码一致性
Java 程序中只要涉及文本流动，就绕不开这三环。任意一环错位，就会出“？”“”“烫烫烫”：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
-
源文件编码：你写的
.java文件用什么编码保存（如 UTF-8），决定了编译器怎么把源码里的中文转成字节 -
运行时默认编码：JVM 启动时根据操作系统 locale 推断（Windows 中文系统常为 GBK，Linux/macOS 常为 UTF-8），影响
new String(byte[])、String.getBytes()等无参方法的行为 -
I/O 显式编码：读写文件、网络请求、数据库交互时，必须显式指定编码（如
new InputStreamReader(in, "UTF-8")），否则依赖上面那个“默认编码”，极易翻车
动手验证比看文档更管用
别光读理论，用几行代码立刻看到编码差异：
立即学习“Java免费学习笔记（深入）”；
- 写个含中文的字符串
"你好"，分别调用s.getBytes("UTF-8")和s.getBytes("GBK")，打印字节数组，对比长度和数值——你会发现 UTF-8 是 6 字节，GBK 是 4 字节 - 用
FileOutputStream写入字节，再用FileInputStream读出来，不经过任何字符串转换，直接打印十六进制字节流，就能确认文件里到底存了什么 - 在命令行用
file -i test.txt（Linux/macOS）或 PowerShell 的Get-Content test.txt -Encoding UTF8查看真实编码，别信编辑器右下角显示
乱码问题排查就盯住“字节流 → 字符流”这一桥
所有乱码本质都是：输入的字节序列，被按错误的编码规则解释成了字符。最典型场景就是用 InputStreamReader：
- 如果文件是 UTF-8 编码，但你写成
new InputStreamReader(fis, "GBK")，中文就会变成两个乱码字符（因为 GBK 把 UTF-8 的 3 字节当作了两个独立的双字节字符来解） - 反过来，UTF-8 解 GBK 文件，也会出现类似问题，但表现可能更隐蔽（比如部分汉字能显示，部分变问号）
- 解决办法只有一个：确保
InputStreamReader的编码参数和文件实际编码完全一致；不确定时，先用工具查清文件真实编码，再写死参数
