Java中String内部统一用UTF-16表示，UTF-8与GBK的区分发生在I/O转换边界，需显式指定Charset；字节流需配合InputStreamReader/OutputStreamWriter指定编码，字符流应避免依赖平台默认值；实际编码由文件、HTTP头等外部数据决定；匹配与否以中文能否正确还原为准；IDE、Maven、Tomcat等环境配置须统一为UTF-8以防乱码。
Java 本身不直接“区分”UTF-8 和 GBK，因为 String 对象内部统一用 Unicode（UTF-16）表示，没有编码属性。真正区分 UTF-8 和 GBK 的环节，发生在字节与字符互相转换的边界处——也就是读写文件、网络传输、控制台输出等 I/O 操作时，你显式或隐式指定的 Charset。
看字节流 vs 字符流的使用方式
这是最直观的判断依据：
- 用
FileInputStream/FileOutputStream等字节流时，数据是原始字节，本身不含编码信息；要转成中文字符串，必须配合InputStreamReader或OutputStreamWriter并传入Charset.forName("UTF-8")或Charset.forName("GBK")——这里指定的就是你要“按哪种规则解读字节”。 - 用
FileReader/FileWriter等字符流时，它们底层已封装了默认 Charset；但不推荐依赖默认值，因为 Windows 默认是 GBK，Linux/macOS 默认是 UTF-8，极易跨平台出乱码。正确做法是用new InputStreamReader(new FileInputStream(...), StandardCharsets.UTF_8)显式声明。
看文件或数据源的实际编码格式
编码不是写在 Java 代码里的标签，而是外部数据本身的物理存储格式：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 记事本保存为“ANSI”，在简体中文 Windows 下大概率是 GBK；保存为“UTF-8 无 BOM”，就是 UTF-8。
- IntelliJ、VS Code 默认用 UTF-8 编码打开和保存文件；若项目里混入了 GBK 编码的配置文件（如 old.properties），又用 UTF-8 去读，就会出现“浣犲ソ”这类典型乱码。
- HTTP 响应头中
Content-Type: text/html; charset=gbk，就明确告诉你正文是 GBK 编码，Java 客户端需用 GBK 解码。
看运行时能否正确还原中文
这是验证是否匹配的最终标准：
立即学习“Java免费学习笔记（深入）”；
- 如果一段中文文本，用
"你好".getBytes(StandardCharsets.UTF_8)得到 3 个字节（如e4 b8 ad），再用new String(bytes, StandardCharsets.GBK)解码，结果变成乱码（如 “浣”），说明编码不匹配。 - 反过来，GBK 编码的字节数组（如汉字占 2 字节），用 UTF-8 解码会抛
MalformedInputException或产生 符号——这是 JVM 在告诉你：“这串字节不符合 UTF-8 的变长规则”。 - 可借助
Charset.isSupported("GBK")判断 JVM 是否支持该编码（所有主流 JDK 都支持 UTF-8 和 GBK）。
看 IDE 和构建工具的默认设置
很多乱码其实源于环境配置未对齐：
- IntelliJ：Settings → Editor → File Encodings → Global Encoding / Project Encoding / Default encoding for properties files，建议全设为 UTF-8。
- Maven 编译插件需显式配置源码编码：
<encoding>UTF-8</encoding>，否则javac可能按系统默认（GBK）编译含中文字符串的源文件，导致 class 文件里字面量错乱。 - Tomcat 服务器需在
server.xml中配置URIEncoding="UTF-8"，否则 GET 请求中的中文参数会被错误按 ISO-8859-1 解析。
