Java语言里的char类型经常让初学者困惑：它到底能不能表示所有的Unicode字符？答案并不简单。char在Java中是一种基本数据类型，宽度为16位，采用UTF-16编码单元的形式存储。这意味着它直接映射的是Unicode的码元而非完整码点。对于位于基本多文种平面（BMP）的字符，一个char确实等于一个字符；但对于增补平面里的字符，比如部分emoji或罕见汉字，则需要两个char构成的代理对。理解这一点是正确处理字符串的基础。
char类型的底层存储与UTF-16编码原理
在Java虚拟机规范中，char被定义为16位无符号整数，取值范围是0到65535（即U+0000至U+FFFF）。当我们在代码里写char c = 'A';时，实际保存的是十进制65，也就是UTF-16中字母A的码元。由于历史原因，Java诞生时Unicode规模尚小，设计者认为16位足够覆盖所有字符，因此char直接对应当时的Unicode字符。但随着Unicode扩充到超过百万个码点，16位显然不够用了。
Unicode目前将码点空间划分为17个平面，每个平面有65536个码点。基本平面之外的字符被称为增补字符，它们的码点大于U+FFFF。UTF-16使用一种叫代理对的技术：用两个16位码元表示一个增补码点，第一个称为高代理（范围D800-DBFF），第二个称为低代理（范围DC00-DFFF）。因此一个char只能装下代理对的一半，无法独立表达增补字符。下面代码展示了如何用char数组表示一个增补平面字符：
public class CharDemo {
public static void main(String[] args) {
// 增补平面字符 U+1F600 (😀) 的代理对
char high = 'uD83D';
char low = 'uDE00';
String s = new String(new char[]{high, low});
System.out.println(s); // 输出笑脸emoji
System.out.println(s.length()); // 输出2，因为length按char计数
System.out.println(s.codePointCount(0, s.length())); // 输出1，按码点计数
}
}
从上面例子可以看到，String的length()方法返回的是char数量而不是字符数量。这在处理用户输入、截取子串时非常危险，因为直接按索引截取可能把一个代理对拆开，产生乱码。开发者应当优先使用基于码点的方法，比如codePointAt或offsetByCodePoints来安全地遍历字符串。
码点与码元的区别及其在Java API中的体现
码点（code point）是指Unicode标准中为每个字符分配的唯一编号，范围是U+0000到U+10FFFF。码元（code unit）则是具体编码格式里的存储单元，在UTF-16中就是16位。Java的char本质是码元，而我们经常说的“字符”更接近码点概念。混淆二者就会导致逻辑错误。例如字符串"𠮷"（一个汉字增补字符）的码点是U+20BB7，但在Java里必须写成两个char的转义序列。
JDK提供了多个方法来桥接码元和码点。Character.toCodePoint(char high, char low)可以把代理对合成一个int类型的码点；Character.isSurrogate(char c)能判断某个char是否为代理项。在遍历字符串时，如果简单地用charAt(i)逐个取出，遇到增补字符就会拿到半个代理，这时应当改用codePointAt配合charCount判断占用几个char。下面的片段演示了安全遍历：
String text = "A𠮷B😀";
int i = 0;
while (i < text.length()) {
int cp = text.codePointAt(i);
System.out.println("码点:" + cp + " 字符:" + new String(Character.toChars(cp)));
i += Character.charCount(cp); // 增补字符返回2，普通字符返回1
}
这种写法保证了每次循环处理的是完整字符，不会因为代理对被拆分而输出问号或方块。很多第三方库如Apache Commons Lang的StringUtils也封装了类似逻辑，但在性能敏感场景下自己用码点API更轻量。理解这些API差异，是写出国际化稳定程序的关键。
常见开发误区与正确处理方案
第一个常见误区是认为String.length()就是字符数。在仅含BMP字符的老系统中这没错，但今天用户随时可能粘贴emoji或生僻字。若数据库字段按长度校验，用错方法会导致插入失败。正确做法是在业务层用codePointCount计算真实字符数，或对UTF-8字节长度做限制，因为网络传输大多用UTF-8而非UTF-16。
第二个误区是在截取字符串时用substring(0, n)按char截断。假设n落在某个增补字符的代理对中间，得到的子串末尾是孤立代理，反序列化或显示时可能崩溃。应当先转成码点数组再截取，或者使用Java 8之后的codePoints()流。示例代码如下：
String src = "用户昵称😀结尾"; int maxCodePoints = 5; StringBuilder sb = new StringBuilder(); src.codePoints().limit(maxCodePoints).forEach(cp -> sb.appendCodePoint(cp)); System.out.println(sb.toString()); // 安全截取前5个码点
此外，读写文件时若指定了错误编码，char和Unicode的映射也会出问题。比如用系统默认编码而非显式UTF-8读取，中文可能变乱码。始终在InputStreamReader和OutputStreamWriter中写明StandardCharsets.UTF_8，才能让char正确还原Unicode。掌握这些细节后，Java处理多语言文本将不再有隐性缺陷。