javaascii码转换

昨天调试一个老接口，转换返回的转换字符串里全是乱码，控制台打印出来像外星文。转换排查半天，转换发现是转换对方把ASCII码当字符串直接拼进JSON了。这事让我想起一个基本功——Java里的转换ASCII码转换，看似简单，转换坑却不少。转换

最直接的转换转换方式，就是转换char和int互转。char c = 'A'; int ascii = (int) c; 这样ascii变量就存了65。转换反过来，转换int code = 97; char letter = (char) code; 得到'a'。转换这操作本质上是转换类型转换，JVM底层把字符的转换Unicode码点（前128位就是ASCII）直接映射成整数，没有额外开销，性能极好。

但实际开发中，没人会手动转单个字符。字符串批量转换才是常态。比如把"Hello123"变成ASCII码序列，你得写循环，逐字符处理。核心代码大概长这样：

String input = "Hello"; StringBuilder sb = new StringBuilder(); for (char c : input.toCharArray()) {  sb.append((int) c).append(" "); } System.out.println(sb.toString()); // 72 101 108 108 111

这段代码跑起来没问题，但有个隐蔽的坑：char在Java里是16位无符号整数，能表示0到65535。中文、emoji这些字符的码点远超127，直接强转得到的是Unicode码，不是ASCII。真遇到非ASCII字符，程序不会报错，但结果就不对了。我见过有人把中文"中"转成20013，然后拿着这个数去对接只认ASCII的老系统，结果对端直接解析失败。

更高效的做法是用Java 8的Stream，或者干脆用Apache Commons Lang的StringUtils。但说实话，小数据量用循环就行，别过度设计。真正要警惕的是反向操作——把ASCII码字符串还原成文本时，分隔符不一致会出大问题。有人用逗号分隔，有人用空格，还有人用换行。最稳妥的方式是固定用单个空格，解析时split(" ")，简单粗暴。

还有个冷门知识点：字符数组和字节数组的转换。ASCII码本质上是字节，但Java的char是Unicode。当你用String.getBytes()时，默认使用平台字符集，在中文Windows上就是GBK，这会导致ASCII码值超过127的字符变成两个字节。要想严格按ASCII处理，必须指定字符集：byte[] bytes = str.getBytes(StandardCharsets.US_ASCII);。这样超过127的字符会变成问号(63)，不会抛异常，但数据已经丢了。我踩过这个坑，当时处理用户输入的邮编，有人用了全角数字，结果全变成问号存进数据库，查了半天才发现。

如果只是想显示字符对应的ASCII码值，还有个冷门API：Character.codePointAt(str, index)。这个能正确返回码点，包括增补字符。但日常用不到，除非你处理特殊符号。比如字符''（U+1F600），用char强转得到的是55357，这是个代理对的高位，不是真正码点。用codePointAt才返回128512。

说这么多，其实就想表达一个观点：ASCII转换本身不难，难的是知道什么时候用哪个工具。类型转换适合单字符，循环适合小批量，getBytes适合网络传输，codePointAt适合特殊场景。没有万能方案，全看上下文。

最后提个建议：写转换代码时，务必加注释说明字符集。我见过太多同事写完代码就不管了，三个月后别人接手，看到一堆魔法数字65、97完全懵。加一行注释，"// ASCII 'A'=65"，成本极低，收益极高。代码是写给人看的，顺便让机器执行而已。