Java中char类型固定为16位UTF-16编码单元，与字符集编码无关；编码仅影响char的生成、字节转换和字符串构造过程，需显式指定charset避免错误。
Java 中字符集编码不直接影响 char 类型本身的定义和内存结构，但会深刻影响 char 如何被生成、解释和转换——关键在于分清“存储”和“转换”两个层面。
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
char 类型本身与编码无关
-
char是 Java 语言规范强制规定的 16 位无符号整数（0–65535），固定占 2 字节，按 UTF-16 编码单元（code unit）方式存储。 - 它存的不是字节，而是 Unicode 码点在 BMP 平面内的数值（如
'中'→U+4E2D→ 内存中存0x4E2D）。 - 源文件用 UTF-8 编写、GBK 编写，甚至 ISO-8859-1，只要编译器能正确解码出 Unicode 码点，赋值给
char就是同一个值。 - 编译时已将源码中的
'中'或'\u4e2d'统一转为码点整数，后续运行时char只认这个数，不记得它来自哪种编码。
编码真正起作用的三个典型场景
✅ 从字符串字面量或文件读取生成 char
- 源文件保存为 UTF-8，写
char c = '中';→ 编译器读取字节E4 B8 AD，按 UTF-8 规则解码为U+4E2D，再存入char。 - 若源文件误存为 GBK，而编译器按 UTF-8 解析，就会解出错误码点（比如乱码
0xE4B8被当两个 ASCII 字符），导致char值错误。 - 所以：源文件编码 + 编译器解码方式必须匹配，否则
char初始值就错了。
✅ String 转 byte[]（即 getBytes()）
-
String s = "中";-
s.toCharArray()→ 得到['中']，1 个char，占 2 字节（内存中） -
s.getBytes(StandardCharsets.UTF_8)→ 得到[0xE4, 0xB8, 0xAD]，3 字节 -
s.getBytes(StandardCharsets.UTF_16)→ 得到[0xFE, 0xFF, 0x4E, 0x2D]（含 BOM），4 字节
-
- 这里
char没变，变的是「把同一个 Unicode 字符翻译成不同字节序列」的规则。 - 错选编码（如用
ISO-8859-1处理中文）会抛UnsupportedEncodingException或截断丢数据。
✅ byte[] 转 String（即 new String(byte[], charset)）
-
byte[] bs = {(byte)0xE4, (byte)0xB8, (byte)0xAD};-
new String(bs, StandardCharsets.UTF_8)→ 正确得到"中" -
new String(bs, StandardCharsets.ISO_8859_1)→ 得到ä¸AD（三个 Latin-1 字符）
-
- 这一步若编码指定错误，构造出的
String内部char序列就完全错误，后续所有charAt()、正则、比较都会错。
特别注意：UTF-16 是 char 的“原生语言”，不是可选项
-
char的设计就是为 UTF-16 服务的：BMP 字符 → 单char；增补字符（如 emoji）→ 必须用代理对（两个char）。 - 不是“Java 支持 UTF-16”，而是
char就是 UTF-16 的代码单元。你无法让一个char存 UTF-8 的三个字节，也不能让它“自动适配” GBK。 - 所有跨编码操作（读文件、网络接收、数据库存取）都必须显式指定 charset，否则依赖平台默认编码（如 Windows 上是 GBK），极易出错。
不复杂但容易忽略。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
