Java统一用Unicode（UTF-16）管理ASCII与中文字符，String天然支持混排；乱码主因是输入/输出时未显式指定UTF-8等编码，而非字符转换问题。
Java 中 ASCII 码和中文字符混合处理，核心不是“把 ASCII 转成中文”，而是**统一用 Unicode（UTF-16）管理所有字符，并在输入/输出、网络传输或文件读写时正确指定编码**。ASCII 字符（0–127）本身就是 Unicode 的子集，而中文字符在 Unicode 中有对应码点（如“中”是 U+4E2D，十进制 20013），Java 的 char 和 String 天然支持——关键在于避免编码误用导致乱码。
明确字符本质：ASCII 和中文共存于 String 中无需转换
Java 的 String 内部使用 UTF-16 编码，可同时容纳 ASCII 字符（如 'A'、'1'）和中文字符（如 '中'、'文'）。你不需要“把 65 变成 '中'”，因为：
-
"abc你好"是合法字符串，长度为 5，charAt(0)返回'a'（ASCII 97），charAt(3)返回'好'（Unicode 码点 22909） -
(int)'中'直接得到 20013，(char)20013可还原为'中' - 混排时打印、拼接、正则匹配等操作均正常，无需额外干预
输入/输出环节必须显式指定编码（最容易出错的地方）
乱码几乎都发生在字节 ↔ 字符转换时，比如读文件、发 HTTP 请求、写日志。Java 默认平台编码（Windows 常为 GBK，Linux/macOS 常为 UTF-8），不一致就会出问题。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 读文本文件：用
Files.readString(path, StandardCharsets.UTF_8)，不要用new Scanner(file).nextLine()（它依赖系统默认编码） - 写文件：用
Files.writeString(path, str, StandardCharsets.UTF_8) - HTTP 请求体（如 POST）：设置 header
"Content-Type: application/json; charset=utf-8"，并确保 body 字符串以 UTF-8 编码为字节数组 - 控制台输出：确保终端/IDE 控制台编码设为 UTF-8（IntelliJ → Settings → Editor → File Encodings；Windows CMD 需执行
chcp 65001）
需要解析字节流时，严格按实际编码解码
如果你拿到的是原始字节数组（例如从 socket、旧系统接口或二进制协议中读取），不能假设它是 ASCII 或 UTF-8——必须依据协议约定解码：
立即学习“Java免费学习笔记（深入）”；
- 若对方明确发送的是 UTF-8 字节：
new String(bytes, StandardCharsets.UTF_8) - 若对方用 GBK 编码中文：
new String(bytes, Charset.forName("GBK")) - 绝对避免：
new String(bytes)（使用平台默认编码，极不可靠） - 验证是否乱码：检查字符串中是否有
（U+FFFD 替换字符），说明解码失败
特殊场景：ASCII 数字字符串想映射为中文（非编码转换，而是业务映射）
有时需求其实是“把字符串 "20013" 解析成字符 '中'”，这属于数值到 Unicode 字符的转换，不是编码转换：
- 安全做法：
int code = Integer.parseInt("20013"); char c = (char) code;（仅适用于基本多文种平面 BMP 字符，即 code ≤ 65535） - 支持补充字符（如 emoji）：
String.valueOf(Character.toChars(128512))（U+1F600） - 注意：
"65"解析后转(char)65得到的是'A'，不是中文——ASCII 码 0–127 没有中文
