根本原因是short与char语义不同：short是有符号16位整数（-32768~3277），char是无符号16位unicode码点（0~65535），强制转换仅重解释位模式而不做值域映射。
short 强制转 char 时出负数或乱码，根本原因不是“转换错了”，而是两者语义不同：short 是有符号 16 位整数（-32768 ~ 32767），char 是无符号 16 位 Unicode 码点（0 ~ 65535）。Java 不做值域映射，只做位模式重解释——当 short 为负数时，其二进制高位全是 1，直接当作 char 解释，就得到一个很大的正整数（比如 -1 → 65535 → '\uffff'）。
理解符号位扩展的本质
short 负值在内存中以补码形式存储。强制转 char 时，JVM 不改变这 16 位比特，只是换一种方式读取：
- short -1 的二进制是 1111111111111111（16 个 1）
- 作为 short，它被解释为 -1
- 作为 char，它被解释为 65535，即 Unicode 中的最后一个基本多文种平面字符
这不是“bug”，而是类型定义决定的行为。关键在于：你是否真正需要把一个有符号数值当作字符码点来用。
明确转换意图再选择方式
先问自己：这个 short 值代表什么？
- 如果它本就是某个字符的 Unicode 码（且确定 ≥ 0），那直接
(char)s安全 - 如果它是计算结果（如
s = (short)(c1 - c2)），可能为负，此时强转 char 无意义，应避免 - 如果目标是“取低 16 位无符号值”，需手动清除符号位影响
安全获取无符号 short 值对应的 char
若你确实需要把 short 当作无符号 16 位整数看待（即把 -1 映射为 65535，-2 → 65534…），推荐以下写法：
-
char c = (char)(s & 0xffff);—— 用位与屏蔽高 16 位，确保只保留低 16 位并以无符号方式解释 - 等价于：
char c = (char)(s + (s ，但位运算法更简洁、无分支 - 注意：
(char)s和(char)(s & 0xffff)对非负 short 结果相同；对负值，后者才是你通常想要的“无符号 reinterpret”
日常开发中的规避建议
- 避免对运算中间结果做 short → char 强转。例如
short s = (short)(a + b); char c = (char)s;很危险，因 a+b 可能溢出成负值 - 字符操作优先用 char 或 int（Unicode 码点），少用 short 存字符码——short 本就不是为字符设计的
- 调试时打印
(int)c而不是直接输出 char，能立刻发现是否得到意外的大数值 - 方法参数设计上，若接口要接收字符码点，用 int 或 char；不要用 short，否则调用方易误传负值
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
