java中char固定占2字节（utf-16代码单元），string内存中恒为utf-16编码的unicode序列；getbytes()和new string(byte[], enc)是unicode与外部字节流间的编/解码，而非改变string编码。
Java 中 char 和 String 的存储、编码与转换，核心在于理解“内存表示”和“外部编码”的分离。char 固定占 2 字节（UTF-16 代码单元），String 在内存中始终是 Unicode 序列（UTF-16 编码），而 getBytes() 或 new String(byte[], enc) 这类操作，本质是 Unicode 与外部字节流之间的双向转换——不是“改变 String 本身的编码”，而是做编/解码动作。
char 类型：固定 2 字节，但不等于“一个中文 = 2 字节”
Java 的 char 是无符号 16 位整数，取值范围 0–65535，对应 Unicode 基本多文种平面（BMP）内的字符。绝大多数常用汉字（如“中”U+4E2D）落在 BMP 内，因此单个 char 就能完整表示，内存占 2 字节。
- 像“中”“A”“€”这类 BMP 字符，一个 char 刚好存下，无需拆分
- 超出 BMP 的字符（如某些 emoji、古汉字），Unicode 码点 ≥ U+10000，Java 用两个连续 char（即 surrogate pair）表示，共占 4 字节内存
- 声明方式：可写为 '中' 或 '\u4e2d'，二者在编译期就被转为同一 UTF-16 代码单元
String 内存中的真实形态：UTF-16 编码的 char 序列
String 对象内部由 char 数组（或 Java 9+ 的 byte[] + coder 标志）实现，无论原始来源是文件、网络还是字面量，一旦加载进 JVM，它就已是 Unicode 序列，没有“UTF-8 String”或“GBK String”这种说法——只有“String 对象”和“它的字节序列表现形式”。
- String.length() 返回的是 char 个数，不是 Unicode 字符数（遇到 surrogate pair 时，length() = 2，但实际只表示 1 个字符）
- String 占用内存 ≈（char 数 × 2 字节）+ 对象头开销（通常 12–16 字节），不随创建时的编码方式变化
- 例如："中" 长度为 1，内部存为一个 char（0x4E2D），占 2 字节数据空间
getBytes() 和 new String(byte[], enc)：编/解码不是“转换 String 编码”
这两个方法是桥接内存（Unicode）与外部世界（字节流）的关键，但常被误解为“给 String 换编码”。实际上，它们只是按指定规则进行单向转换：
- str.getBytes("UTF-8")：把 String 的 Unicode 内容，用 UTF-8 规则编码成字节数组 → 输出是 UTF-8 字节流
- new String(bytes, "GBK")：把 bytes 按 GBK 规则解码，还原成 Unicode 字符串 → 输入必须是合法 GBK 字节，否则可能乱码或抛异常
- 若省略编码参数（如 getBytes()），默认使用 Charset.defaultCharset()，通常是系统 locale 决定（Windows 多为 GBK，Linux/macOS 多为 UTF-8）
避免乱码的关键：两端编码必须匹配
乱码几乎都源于“编码写入”和“解码读取”用的不是同一套规则。比如用 UTF-8 写入文件，却用 GBK 读取，或 HTTP 响应头声明 UTF-8，但页面 meta 标签写 GBK。
- 写文件时明确指定：Files.write(path, str.getBytes(StandardCharsets.UTF_8))
- 读文件时显式声明：new String(Files.readAllBytes(path), StandardCharsets.UTF_8)
- 网络传输中，HTTP、数据库连接、序列化协议等都要约定好字符集，不能依赖默认值
- 调试技巧：打印字节数组十六进制值（如 Arrays.toString(str.getBytes(StandardCharsets.UTF_8))），比看字符串更可靠
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
