ord()只接受单字符返回Unicode码点，chr()只接受整数返回对应字符；传错类型或越界抛TypeError/ValueError；支持全Unicode范围0–0x10FFFF，非仅ASCII。
chr() 和 ord() 的基本行为必须记牢
ord() 只接受长度为 1 的字符串，返回对应 Unicode 码点（ASCII 是其子集）；chr() 只接受一个整数，返回该码点对应的单字符。传错类型或越界会直接报错：TypeError 或 ValueError。
常见错误现象：对中文字符用 ord() 却误以为只能处理 ASCII；或把字符串如 "ab" 传给 ord() 导致 TypeError: ord() expected a character, but string of length 2 found。
- ASCII 范围是 0–127，但
ord()和chr()实际支持 0–0x10FFFF（Unicode 全范围） - 小写字母
a-z对应 97–122，大写A-Z是 65–90 —— 这个偏移量差（32）常被用来大小写转换，但别硬编码，用str.upper()更安全 - 不要假设输入一定是 ASCII：比如
ord("é")返回 233，不是 128 以内的值
批量转换字符串时别用 for + chr(ord()) 套娃
想把字符串每个字符转成 ASCII 码再转回来？直接用 list(map(ord, s)) 拿码点，用 ''.join(map(chr, code_list)) 拼回去。手动循环调用 ord() 和 chr() 不仅啰嗦，还容易在边界出错。
使用场景：日志里临时查看不可见字符的码点、简单编码调试、CTF 中的 baseXX 变种题。
立即学习“Python免费学习笔记（深入）”；
- 如果原字符串含控制字符（如
\x00、\t），ord()照样返回对应数值，但打印时可能看不到效果 -
chr(0)是空字符\x00，写入文件或传给某些 C 接口时会截断，务必检查 - 避免用
chr(ord(c) + 1)处理字母边界（比如z→{），除非你明确需要这种绕过逻辑
处理非 ASCII 字符时，ord() 返回的不是“扩展 ASCII”
所谓“扩展 ASCII”（128–255）只是历史编码（如 ISO-8859-1）的惯用说法，Python 中 ord() 返回的是 Unicode 码点。例如 ord("€") 是 8364，不是 128；ord("中") 是 20013 —— 完全不落在 0–255 区间。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
这意味着：不能靠 ord(c) 判断是否为“单字节字符”，也不能用 <code>chr() 把任意 0–255 的数转成你预期的符号（比如 chr(130) 在不同 locale 下显示可能不同，实际是 Unicode 字符 U+0082，一个控制符）。
- 需要字节级操作（如处理 UTF-8 编码流）？别碰
ord()/chr()，改用bytes和encode()/decode() - 想验证字符是否属于 ASCII 子集：用
c.isascii()（Python 3.7+），比0 更直观 -
chr()输入超出 Unicode 范围（> 0x10FFFF）会抛ValueError: chr() arg not in range(0x110000)
和 bytes/encode 配合时注意编码隐含转换
直接对字符串调 ord() 得到的是 Unicode 码点；但如果你先 s.encode('utf-8') 得到 bytes，再对每个字节调 ord()（或直接索引），拿到的是 UTF-8 编码后的字节值 —— 二者完全不是一回事。
例如 s = "€"：
s = "€"
print(ord(s)) # 8364（Unicode 码点）
print(s.encode('utf-8')) # b'\xe2\x82\xac'（3 字节）
print([b for b in s.encode('utf-8')]) # [226, 130, 172]这时候对 [226, 130, 172] 调 chr()，得到的是三个乱码字符（U+00E2、U+0082、U+00AC），不是原字符。
- 别混淆“字符”和“字节”：Python 3 中
str是 Unicode 字符序列，bytes是字节序列 - 需要字节值？用
s.encode('utf-8')[i]或遍历bytes对象，而不是对字符反复ord() - 从字节重建字符？用
bytes_obj.decode('utf-8')，而不是chr()拼接
真正容易被忽略的点是：ord() 和 chr() 之间没有“编码”概念，它们只在 Unicode 层工作。一旦涉及传输、存储、C 库交互，就必须显式考虑编码（UTF-8 / UTF-16 / GBK 等），这时候硬套 ord()/chr() 会悄悄引入 bug。
