java数据类型不理解字符编码，编码只在字节与字符串转换时由显式指定的charset起作用；string是unicode序列容器，内部存储不影响其unicode语义，char固定16位对应utf-16码元，代理对处理bmp外字符；解码与编码必须配对使用charset，避免依赖默认编码。
Java 数据类型本身不“理解”字符编码，真正起作用的是操作时显式指定的 Charset。String、char 这些类型在内存中是 Unicode 中立的，它们不携带编码信息；编码只在字节与字符串互相转换的边界上生效。
String 是 Unicode 容器，不是 UTF-8 或 GBK 容器
-
String在 JDK 9+ 内部可能用byte[]（Latin-1）或char[]（UTF-16）存储，但对外行为完全一致：它代表一个 Unicode 字符序列。 -
char类型固定是 16 位（2 字节），对应 UTF-16 的一个码元。遇到超出 BMP 的字符（如某些 emoji），需用两个char组成代理对。 - 无论你从 UTF-8 文件读、GBK 网络流收，还是 ISO-8859-1 数据库取，只要正确解码，最终得到的
String内容相同——因为都还原成了同一个 Unicode 序列。
编码转换发生在“进出内存”的两个动作里
解码（bytes → String）：用指定 Charset 把原始字节流解释为 Unicode 字符
✅ 正确：new String(gbkBytes, StandardCharsets.GBK)
❌ 错误：new String(gbkBytes, StandardCharsets.UTF_8)→ 乱码（拿 UTF-8 词典查 GBK 字节）编码（String → bytes）：用指定 Charset 把 Unicode 字符序列打包成目标字节流
✅ 正确：utf8Str.getBytes(StandardCharsets.UTF_8)
❌ 危险：utf8Str.getBytes()→ 依赖系统默认编码，Windows 可能是 GBK，Linux 可能是 UTF-8
这两个动作必须配对使用，中间的 String 不参与“编码选择”。
不同编码对同一字符的字节数差异很大
-
'中'的 Unicode 码点是 U+4E2D- GBK 编码 →
0xD6 0xD0→ 2 字节 - UTF-8 编码 →
0xE4 0xB8 0xAD→ 3 字节 - UTF-16 编码（Big Endian）→
0x4E 0x2D→ 2 字节（BMP 内） - ISO-8859-1 → 不支持 → 抛
UnsupportedEncodingException
- GBK 编码 →
"你好".getBytes("UTF-8").length是 6，.getBytes("GBK").length是 4，和char数量（2）无倍数关系别用
getBytes()无参重载，也别假设String.length()等于字节数
实际开发中该怎么做
读文件时明确原始编码：
Files.readString(path, StandardCharsets.GBK)new BufferedReader(new InputStreamReader(new FileInputStream(f), StandardCharsets.UTF_8))写文件时指定目标编码：
Files.writeString(path, content, StandardCharsets.UTF_8)new OutputStreamWriter(new FileOutputStream(f), StandardCharsets.GBK)HTTP 请求/响应头要匹配：
request.setCharacterEncoding("UTF-8")response.setContentType("text/html; charset=UTF-8")源码文件编译时加
-encoding UTF-8，IDE 设置统一为 UTF-8，避免.java文件保存编码与编译器读取编码不一致
不复杂但容易忽略
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
