char转ascii码直接赋值给int即可，因char本质是无符号16位unicode码点，ascii为其子集；还原时需确保int在0–127范围内，byte转换要先无符号扩展再强转。
char 转 ASCII 码就是直接赋值给 int
Java 中 char 本质是无符号16位整数，底层存的就是 Unicode 码点（ASCII 是其子集）。所以把 char 当成数字用，根本不用“转换”——直接赋给 int 就行。
常见错误现象：int ascii = (int) 'a'; 写了强制转型，其实多余；更糟的是有人调用 String.valueOf('a').getBytes()，绕一大圈还可能因默认编码出错。
-
char c = 'A'; int code = c;—— 最简洁安全，code值为 65 - 别用
Character.getNumericValue()，它返回的是字符的“数字含义”（如'5'返回 5），不是 ASCII 码 - 注意：
char范围是 0–65535，ASCII 只占前 128 个，超出部分（如中文）不是传统 ASCII，但仍是合法 Unicode 码点
判断一个 char 是否在 ASCII 范围内
不能只看是否可打印，得看码点值。ASCII 标准定义是 0–127，其中 0–31 是控制字符（如 \n、\t），32–126 是可打印字符，127 是 DEL。
容易踩的坑：用 Character.isLetterOrDigit(c) 或 Character.isISOControl(c) 判断，这些方法依赖 Unicode 属性，不等价于“是否 ASCII”。
立即学习“Java免费学习笔记（深入）”；
- 准确判断：
c >= 0 && c - 若只关心可打印 ASCII：
c >= 32 && c - 注意：
char是无符号类型，c >= 0永真，但显式写出更清晰，避免和byte混淆
从 ASCII 码 int 还原 char 要小心溢出和符号
把 int 赋回 char 时，Java 会自动截断高16位（即取低16位），但若原始 int 超出 char 范围（0–65535），结果就不是你想要的 ASCII 字符。
典型错误：读取网络字节流时，把 byte 直接转 int 再强转 char，忘了 byte 是有符号的，-1 变成 int 后是 -1，再转 char 得到 65535（即 '\uffff'）。
- 安全还原 ASCII：
int code = 65; char c = (char) code;（前提是确认code在 0–127） - 从
byte还原：先无符号扩展，byte b = (byte) 255; char c = (char) (b & 0xFF);—— 这样b & 0xFF得到 255，再转char是'\u00ff'，不是 ASCII，但至少可控 - 若目标明确是 ASCII，建议加校验：
if (code >= 0 && code
String.getBytes() 默认行为会破坏 ASCII 值映射
很多人以为 "A".getBytes()[0] 一定等于 65，这在 UTF-8 下碰巧成立，但不保证。因为 String.getBytes() 用的是平台默认编码，Windows 上可能是 GBK，Linux 上通常是 UTF-8 —— 而 ASCII 字符在 UTF-8 和 GBK 中单字节值确实都是 0–127，但这是巧合，不是规范保证。
真正危险的是：一旦字符串含非 ASCII 字符（如 "Aä"），不同编码下字节数组长度和内容就完全不同，getBytes()[0] 可能还是 65，但后续索引完全不可靠。
- 要确保字节级 ASCII 映射，必须显式指定编码：
"A".getBytes(StandardCharsets.US_ASCII) - 更推荐：如果只是处理纯 ASCII 字符串，用
String.charAt(i)配合直接转int，绕过字节编码层 - 注意：
StandardCharsets.US_ASCII对非 ASCII 字符会抛java.nio.charset.UnmappableCharacterException，不是静默替换
最常被忽略的一点：char 和 ASCII 的关系只在 0–127 成立；一旦涉及国际化字符、emoji 或代理对（surrogate pair），char 就不够用了，得用 codePointAt() 和 int 码点操作。但那是另一层问题了。
