字符与整数转换本质是unicode码点的数值映射：'a'→65、'中'→20013；java中char为16位覆盖bmp，c/c++需用wchar_t/char16_t，python用ord()/chr()；超出bmp的字符（如emoji）需代理对或专用api处理，不可直接强转。
字符和整数之间的转换，本质上是 Unicode 编码在底层的直接体现——char 是一个 16 位无符号整数（Java 中）或窄/宽字符类型（C/C++ 中），它对应着 Unicode 码点的一个具体数值表示；int 则是通用整型，可承载该码点值。这种转换不是语法糖，而是对“字符即数字”这一编码本质的实践。
Unicode 码点就是整数
每个字符在 Unicode 中被赋予一个唯一、不可变的码点（code point），如 'A' 是 U+0041，'中' 是 U+4E2D。这个 U+ 后的十六进制数，本身就是整数：0x0041 = 65，0x4E2D = 20013。编程语言中，char 类型常被设计为能直接映射到这个整数值，因此强制转换只是显式暴露了这一层关系。
- Java 中 char 占 2 字节（0–65535），正好覆盖 BMP（基本多文种平面），U+0000 至 U+FFFF
- C/C++ 中 char 通常为 1 字节，但 wchar_t 或 char16_t 才用于承载 Unicode 码点
- Python 3 的 str 是 Unicode 字符序列，单个字符用 ord() 得 int，chr() 反向转换
转换时需注意编码平面与代理对
Unicode 总共定义了 17 个平面（0x00000–0x10FFFF），而 BMP（Plane 0）只占前 65536 个码点。超出部分（如 emoji ? U+1F30D）在 UTF-16 中需用两个 16 位码元（代理对：surrogate pair）表示，此时单个 char 无法完整表达一个字符。
- 直接将 char 强转为 int 只能得到代理高位或低位的值，不是真实码点
- 正确获取扩展字符码点应使用 Character.codePointAt()（Java）或 std::wstring_convert（C++11 已弃用，推荐 std::mbstowcs + UTF-8 处理）
- 在 C++ 中，避免用 char 或 wchar_t 直接遍历含 emoji 的字符串，应按 UTF-8 字节序列或 Unicode 标量值解析
实际应用场景中的典型用法
这类转换常见于文本处理底层逻辑，而非业务层随意强转：
- 大小写转换：'a' + ('A' - 'a') → 'A'，依赖 ASCII 码点连续性（但不适用于中文等）
- 过滤控制字符：if (c >= 0x20 && c
- 构建字符映射表：Map
map = new HashMap(); map.put((int)'中', "zhong"); - 正则引擎内部：字符类 [\u4E00-\u9FFF] 实际匹配的是码点范围 19968–40959
别把字节、码元、码点混为一谈
这是最容易出错的地方：
- 码点（Code Point）：U+4E2D，抽象字符编号，是 int 可准确表示的对象
- 码元（Code Unit）：UTF-16 中一个 char 是 16 位码元，UTF-8 中一个 byte 是 8 位码元 —— 它们只是传输载体，不一定等于码点
- 字节（Byte）：文件存储或网络传输的最小单位；读取时若未按正确编码解析，int 强转得到的只是乱序字节值，不是码点
