short是有符号16位整数（-32767~32767），char是无符号16位unicode字符（0~65535）；二者二进制相同但jvm解释不同：short用补码，char无符号；负short转char需用(s & 0xffff)避免符号误读。
Java中short和char都占2个字节（16位），但语义和取值范围完全不同：short是有符号整数（-32768 ~ 32767），char是无符号Unicode字符（0 ~ 65535）。直接强制转换会引发隐式截断或符号误读，必须明确意图并手动处理。
理解底层二进制表示的差异
虽然二者都是16位，但JVM对它们的解释方式不同：
-
short用补码表示，最高位是符号位； -
char始终视为无符号整数，没有符号位概念。
例如：二进制 1111111111111111（全1）
→ 作为short是 -1，
→ 作为char是 65535（即 '\uffff'）。
从short转char：需处理负值
若short值为负，不能直接强转，否则高位符号位会被当作数值的一部分，结果错误（如 (char)-1 得到 '\uffff'，而非预期字符）。
- 安全做法：先做无符号转换，即
(char)(s & 0xffff)，确保把short当16位无符号数看待； - 若业务逻辑只接受非负
short，建议加校验：if (s ； - 不推荐写法：
(char)s—— 对负值会产生意外的高码点字符。
从char转short：注意符号扩展
char值范围是0~65535，而short最大只到32767。超过32767的char（如'\u8000'及以上）转short会溢出。
- 若确定
char在0~32767范围内，可直接强转：(short)c； - 若可能超出，需判断并处理：
short s = (c （模拟无符号截断到有符号）； - 更清晰的方式是显式使用int过渡：
short s = (short)(c & 0xffff)，利用int的32位容纳无符号16位值再截断。
实际场景中的推荐写法
多数情况下，二者不应随意互换——它们代表不同抽象类型。仅在特定底层操作（如协议解析、字节缓冲区处理）中才需转换。
- 网络/文件IO中读取2字节数据时，根据协议定义决定解析为
short还是char； - 使用
ByteBuffer时，调用getShort()或getChar()方法，由API保证语义正确； - 自定义序列化中，统一用
int做中间类型可避免歧义：short → int → char或char → int → short，再显式掩码或检查范围。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
