Java中char固定占2字节，因其被规范定义为16位无符号整数，直接对应Unicode基本多语言平面（BMP）的一个UTF-16代码单元，无论存储英文、中文或符号均统一占用2字节。
Java中char为什么固定占2字节
因为Java规范强制规定char是16位无符号整数，直接对应Unicode基本平面（BMP）中的一个码点。它不关心你存的是'A'、'中'还是'€'，统统按UTF-16单个代码单元处理——也就是2字节（16位）。这和C语言里char只占1字节、仅代表ASCII完全不同。
注意：虽然UTF-16对BMP字符用2字节，但遇到增补字符（如某些emoji：? U+1F600），Java内部会用两个char（即代理对，surrogate pair）表示，共4字节。此时单个char变量仍只占2字节，但一个完整字符可能跨越两个char。
String在内存中怎么存，占多少空间
Java 9起，String底层改用byte[] + coder结构：若字符串只含Latin-1字符（如纯英文、数字、ASCII符号），则用1字节/字符的紧凑格式（coder = 0）；否则统一用UTF-16编码，2字节/字符（coder = 1）。所以内存占用不是固定值，取决于内容。
例如：
– String s1 = "abc" → 底层byte[]长度为3，coder=0
– String s2 = "abc中" → 含中文，触发UTF-16模式，byte[]长度为8（4字符 × 2字节）
别被s.length()误导：它返回的是char个数（即代码单元数），不是真实Unicode字符数（code point数）。对含代理对的字符串，需用s.codePointCount(0, s.length())获取真正字符个数。
立即学习“Java免费学习笔记（深入）”；
String转byte[]时字节数由什么决定
完全取决于你调用getBytes(Charset)时传入的编码，和char数量无关。同一段String，不同编码结果差异巨大：
-
"中".getBytes(StandardCharsets.UTF_8)→ 3字节（0xE4 0xB8 0xAD） -
"中".getBytes(StandardCharsets.UTF_16BE)→ 2字节（0x4E 0x2D） -
"中".getBytes(Charset.forName("GBK"))→ 2字节（0xD6 0xD0） -
"?".getBytes(StandardCharsets.UTF_8)→ 4字节（U+1F600需4字节UTF-8编码）
漏写编码参数（如只用getBytes()）会走系统默认编码（Windows常为GBK，Linux/macOS常为UTF-8），极易引发跨环境乱码。务必显式指定，例如str.getBytes(StandardCharsets.UTF_8)。
常见编码转换场景与避坑要点
典型流程是：字节流 → 解码为String（Unicode）→ 编码为新字节流。关键在于两步都明确指定编码，不能依赖默认值。
常见错误操作：
– 读文件时用FileInputStream配String(byte[])却不指明编码 → 按平台默认解码，Windows读UTF-8文件必乱码
– 网络响应未设Content-Type: text/html; charset=UTF-8，浏览器按ISO-8859-1解析中文 → 显示“æ”这类乱码
正确做法：
– 文件读取：用Files.readString(path, StandardCharsets.UTF_8)或new InputStreamReader(new FileInputStream(f), StandardCharsets.UTF_8)
– 字节转字符串：new String(bytes, StandardCharsets.UTF_8)
– 字符串转字节：str.getBytes(StandardCharsets.GBK)
– HTTP传输：服务端设置response.setCharacterEncoding("UTF-8")，前端HTML加<meta charset="UTF-8">
记住：String对象本身没有“编码格式”，它只是内存里的Unicode序列。编码只发生在进出JVM边界的那一刻——读文件、收网络包、写日志、打印控制台……这些IO环节才是编码问题的高发区。
