字符编码全景：ASCII、GBK、UTF-8、规范化与 Windows 控制台乱码 未开始

题记与说明

• 课题：字符编码全景：ASCII、GBK、UTF-8、规范化与 Windows 控制台乱码
• 日期：2026-11-05（写作与复核日期）
• 性质：综合报告最终稿——由同课题纵轴章（历时线）与横轴章（2026-11 截面对比）综合而成，并已按独立审读意见逐条修订（修订记录见文末"编辑说明"）
• 方法说明：两份章节文件均基于多轮 WebSearch 检索（2026-11-05）并逐条附来源 URL；字节级断言均在写作机（Windows 11 简体中文版、活动代码页 936、Python 3.12.12）上实测。本次综合时，本稿对两章共用的全部关键字节断言做了独立复核（命令与输出见 1.9 节，为定稿时在本机重跑的如实摘录），除一处计数口径差异外全部吻合；两章之间三处事实口径不一致已按证据强弱消解，见文末"编辑说明"。

TL;DR

字符编码六十五年的主线，是三个目标的结构性冲突：省字节、扩字符集、保向后兼容。ASCII（1963/1967）确立了"前 128 码位是全球公共底层"，却把高位字节留给各国混战；东亚被迫双字节，中国走出 GB2312→GBK→GB18030 三代国标，Windows 中文版则把 CP936 固化为三十年不变的默认代码页。Unicode+UTF-8 凭"ASCII 透明、自同步、无端序"三个设计优势，自 RFC 3629（2003）起通吃传输与存储。2026 年截面：UTF-8 是唯一赢家；GB18030-2022 是法定陪跑（87,887 字、2023-08-01 强制实施）；UTF-16 退守 Windows/Java/JS 内部表示。乱码主战场已从终端配置转向存量数据与遗留程序——本机 2026 年控制台默认代码页仍是 936，但 JEP 400（JDK 18）与 PEP 686（Python 3.15）已把 UTF-8 下沉为语言默认值；规范化（NFC/NFD）与厂商映射表分裂是 UTF-8 之后仍存的第二重乱码源。行动建议：新系统一律 UTF-8 无 BOM 并端到端显式声明；存量 GBK 数据不动、边界转码（边界清单与本机 checklist 见 2.6 节）；文件名、缓存键等"识别同一对象"的比较在入口统一 NFC 并禁用 NFKC/NFKD；密码哈希、签名等逐字节安全比较不做任何规范化，改为在注册入口固定一种形式并全程一致。

一、纵轴：发展脉络（1961–2026）

1.1 时间线速查表

1.2 前史与 ASCII 时代（1874–1986）：前 128 码位成为全球公共底层

编码问题的本质是"约定"：双方事先约定比特模式与符号的对应表。电报时代的博多码（Baudot，1874 年前后）用 5 比特表示字母，靠"字母位/数字位"切换码页——"码页切换"这个此后纠缠业界一百年的概念，在电报机上就已出现。进入计算机时代，IBM 在 1964 年为 System/360 配套了 8 比特的 EBCDIC，业界另一侧走向 7 比特的 ASCII。（本段为背景概述，基于两章既有知识叙述，个别年份未逐条核实，引用时应以标准史文献为准。）

ASCII 时间线：1961 年 5 月，IBM 工程师 Bob Bemer 向美国标准协会（ASA）X3.2 分委员会提交字符集提案（Wikipedia – ASCII）；1963 年第一版 ASA X3.4-1963 发布，但没有小写字母，还留有 28 个未指派码位（ASCII-1963、Annotated history of character codes）；1967 年修订版 X3.4-1967 补入小写字母表，并引入 ESC（转义）等控制符——今天终端里 ANSI escape 序列的源头正在于此；1967–1986 年间标准又历经十次修订，期间主管机构更名为 ANSI。

ASCII 只有 7 位、128 个码位，高位第 8 位在各家硬件上被自由发挥（打标志位、扩展图形字符），为后来"高位字节战争"埋下伏笔；ISO 646 允许各国替换部分码位，产生"国际 ASCII 方言"。ASCII 最大的历史遗产是：前 128 个码位从此成为全球所有后续编码的"公共底层"——这正是它后来能被 Unicode 完整继承、也被 UTF-8 特意保持"透明"的原因。

1.3 双字节国标时代与"高位字节战争"（1980–1995）

当计算机进入东亚，128 个码位连常用汉字的零头都放不下，各国不约而同走向双字节方案，同时争夺 0x80–0xFF 这片"无主之地"。

• GB2312-1980《信息交换用汉字编码字符集·基本集》：1980-03-09 由国家标准总局发布、1981-05-01 实施，华北计算技术研究所起草；收录 6763 个汉字（一级 3755、二级 3008）及符号共 7445 个图形字符；2017 年转为推荐性标准 GB/T 2312-1980（国家标准全文公开系统、维基百科 – GB 2312）。区位码、机内码、"半个汉字"是一代中国程序员的集体记忆。
• Big5：台湾资策会主持，1984 年前后公布（一说 1983 年底完成制订、1984 年公布；年份为近似值）；其臭名昭著的缺陷是一部分汉字的第二字节恰为 0x5C（反斜杠 \），即所谓"許功蓋問題"（维基百科 – 大五碼、iT 邦幫忙：php 架設出亂碼）。
• GBK《汉字内码扩展规范》1.0：1995-12-01 由全国信息技术标准化技术委员会制订；双字节，码位范围 8140–FEFE（首字节 0x81–0xFE、次字节 0x40–0xFE，剔除次字节 0x7F；126×190 = 23940），共 23940 个码位，收录 21003 个汉字（含部首与构件；其中与 Unicode CJK 统一表意文字主体对应的为 20902 个，见"编辑说明"第 2 条），完全兼容 GB2312-80。注意它是指导性技术文件而非强制国标（维基百科 – 汉字内码扩展规范）。
• Windows 95 简体中文版以 GBK 为系统内码，微软实现为代码页 936（CP936）；CP936 最初与 GB2312-80 完全一致，随后扩展为 GBK 范围，且"至今未随 GB18030 修订"（Wikipedia – Code page 936)）。

驱动因素：中文信息处理的产业刚需（报刊排版、税务、户籍系统），以及"汉字点阵字库 + 双字节内码"在硬件成本约束下的最优解。这一时期埋下的两个长尾问题——CP936 与国标脱钩、0x5C 字节陷阱——在三十年后的今天仍是乱码工单的高频根因（本机复核：GBK 系中第二字节为 0x5C 的字符共 118 个，见 1.9 节）。

1.4 Unicode 的诞生与 UTF-8 的发明（1987–2003）

Unicode 线：1987 年，Xerox 的 Joe Becker 与 Apple 的 Lee Collins、Mark Davis 合作研究通用多字节编码；1991-01-03 Unicode 联盟在加州注册成立，创始成员包括 Apple、Microsoft 等；1991-10 出版 Unicode 1.0；此后与 ISO/IEC 10646（UCS）保持同步，两套标准同一码表，"唯一字典"就此确立（Wikipedia – Unicode、History of Information、Unicode 官方史页）。早期 Unicode 是 16 位定长设计；随着汉字扩展区加入，约在 1996 年 Unicode 2.0 时代引入 UTF-16 代理对机制（此细节两章均标注未单独核实）。

UTF-8 线：1992 年 8–9 月，X/Open 委员会请 Ken Thompson、Rob Pike 评审 IBM 的 FSS/UTF 方案；两人在新泽西一家餐馆晚餐时认为该设计不佳，Thompson 就在纸餐垫上画出了新的位分配方案；1992-09-08 凌晨 3:22，Thompson 发出第一版 UTF-8 实现（Rob Pike 的 UTF-8 历史原始文本、Rob Pike 博客）。UTF-8 首先用于 Plan 9 操作系统；IETF 侧由 François Yergeau 三次成文：RFC 2044（1996-10）→ RFC 2279（1998，允许最长 6 字节/31 位）→ RFC 3629（2003-11，收束到 Unicode 范围 U+10FFFF、最长 4 字节），成为今天互联网的标准（RFC 3629、Wikipedia – UTF-8）。

设计精髓三条：ASCII 完全透明（单字节文本即 UTF-8 文本）、自同步（从任意字节可判断字符边界，损坏或截断时最多丢一个字符而非整片文本）、无字节序问题。这三条让 UTF-8 在与 UTF-16 的路线之争中胜出，也决定了它后来在 Web 与 Unix 世界的全面接管。

1.5 乱码大战的黄金年代（1995–2010）：Windows 控制台主战场

Unicode 有了，但"文字写得对"与"屏幕显示对"之间隔着控制台、字体、区域设置三道墙。中文开发者在这十五年贡献了大量流传至今的乱码名词。

• Windows 中文版控制台默认活动代码页 936，三十年未变——本稿写作机（2026 年的 Windows 11）实测 cmd /c chcp 仍输出"活动代码页: 936"（见 1.9 节）。
• chcp 65001 在 Windows 7 及以前是危险操作：批处理解析器会误读多字节字符，甚至直接让 cmd 崩溃退出；到 Windows 8/10 才逐渐可用，仍残留怪癖（Super User 经典帖、mattn: Please stop hack "chcp 65001"（2018）、xiph/flac issue #894）。
• 两大"乱码图腾"的机制（本机复核，见 1.9 节）：
  • 锟斤拷：UTF-8 解码失败被替换为 U+FFFD，其 UTF-8 字节 EF BF BD 连续排列后再按 GBK 双字节切分（EF BF / BD EF / BF BD…），恰好拼出 锟/斤/拷。它诞生于浏览器、记事本等有损转换层而非严格编解码器（本机实测：Python 严格 GBK 编码器拒绝编码 U+FFFD 本身），且不可逆——被 GBK 双字节"消费"的字节已无法还原原文（evilpan: About Unicode、维基百科 – 锟斤拷、长亭百川云笔记）。
  • 烫烫烫 / 屯屯屯：MSVC Debug 模式下，未初始化栈内存被填充 0xCC（0xCC 恰是 x86 的 INT 3 断点指令，属刻意的安全设计），按 GBK 显示即"烫"；Debug 堆新分配内存填 0xCD，显示为"屯"（微软 CRT 调试堆官方文档、知乎：烫烫烫屯屯屯那些事）。字节映射本机实测吻合：烫=0xCCCC、屯=0xCDCD（横轴章此处"栈/堆"归属笔误，见编辑说明第 1 条）。
• 国标线的强制回归：2000-03-17 国家质量技术监督局发布 GB18030-2000《信息技术 信息交换用汉字编码字符集 基本集的扩充》，正式取代 GBK；单/双/四字节混合编码，保留全部 GBK 汉字并收录 CJK 扩展 A，定位为计算机系统必须遵循的强制性基础标准；2005 年修订为 GB18030-2005（维基百科 – 汉字内码扩展规范、支付宝生僻字方案：GB18030 字符集说明）。

结构性原因：Windows NT 内核内部是 UTF-16，但 ACP（ANSI 代码页）体系为老程序保留——"Unicode 理想"与"ANSI 现实"长期双轨并行，这就是控制台乱码问题在 Windows 上格外顽固的结构性根源。

1.6 UTF-8 的全面胜利（2003–2019），并附赠新的坑

• Web 侧：HTML/CSS/JSON 生态默认 UTF-8；RFC 3629（2003）收束规范后，UTF-8 成为"互联网的字符编码"事实标准（RFC 3629）。
• Python 3.0（2008-12）：PEP 3120 使源码默认 UTF-8、str 即 Unicode 文本；但 open() 的默认编码仍跟随 locale——中文 Windows 上就是 GBK，由此产生一代 Python 用户都见过的 UnicodeDecodeError: 'gbk' codec can't decode byte ...（PEP 3120、PEP 686）。
• MySQL 的 utf8 假 UTF-8：MySQL 的 utf8 实为最长 3 字节（utf8mb3），不符合完整 UTF-8；多年无人深究，直到 emoji 普及，Incorrect string value: '\xF0\x9F...' 报错爆发，社区才大规模迁移 utf8mb4，且必须服务端/库/表/连接四处同时 4 字节（HN: In MySQL, don't use 'utf8', use 'utf8mb4'、DBA SE 案例）。utf8mb3 在 MySQL 8.0 已被官方标记弃用（MySQL 官方文档原文："The utf8mb3 character set is deprecated… Expect utf8mb3 to be removed in a future major release of MySQL"；且 utf8 是其弃用别名，MySQL 8.0 官方文档），但存量库仍在。
• JDK 9（2017-09）：JEP 226 将 resource bundle 的 .properties 默认编码从 ISO-8859-1 改为 UTF-8（非法 UTF-8 字节时回退），终结了 native2ascii 与 \uXXXX 转义时代；注意 java.util.Properties 类本身仍按 ISO-8859-1 处理（JEP 226、Oracle 文档）。
• Windows 10 1903（2019-05）：记事本新建文件默认编码从 ANSI 改为 UTF-8（无 BOM），并支持另存为 UTF-16 LE/BE；老用户被迫用注册表 fEncoding 改回 ANSI（Tech Community 讨论、Super User）。

这一阶段的胜利本质是工程失败教训的复利：每一个 utf8mb3 事故、每一张锟斤拷截图，都是迁移的投票。

1.7 收尾战（2018–2026）：运行时默认值大迁徙 + Windows 双轨修正 + 国标强制升级

运行时侧"默认值大迁徙"

• JDK 18（2022-03）JEP 400 "UTF-8 by Default"：标准 API 在所有操作系统上默认字符集统一为 UTF-8；旧行为可通过系统属性 native.encoding 访问，-Dfile.encoding 从此真正影响默认字符集（JEP 400、inside.java 官方解读、JDK-8286998）。
• Python 3.15（2026-10-09 发布）PEP 686：UTF-8 模式默认开启，open()/stdio/管道/环境变量等默认编码不再依赖 locale，仅在显式 PYTHONUTF8=0 时回退 locale（PEP 686、pydevtools 解读、Pixelstech：什么会坏）。
• PowerShell 7+ 全平台默认 utf8NoBOM（写文件与重定向运算符均是）；而 Windows PowerShell 5.1 的默认值是系统 ANSI 代码页（中文系统即 936），Out-File 默认还带 BOM 的 UTF-16LE——同一台机器两代 Shell 行为迥异，是复合型乱码问题的经典来源（Microsoft Learn – about_Character_Encoding、Stack Overflow 讨论）。
• 语言原生 UTF-8：Go 语言规范强制源码为 UTF-8（go.dev/ref/spec）；Rust 的 String 类型本身就是 UTF-8（官方文档原文："A UTF-8–encoded, growable string"、"Strings are always valid UTF-8"，Rust std::string::String）；Node.js 文件系统 API 的字符串写入/追加默认编码为 utf8（fs.writeFile/fs.appendFile 的 encoding 默认 'utf8'；fs.readFile 不指定 encoding 时返回 Buffer 而非字符串，Node.js fs 官方文档）。

Windows 侧的"双轨修正"

• Windows 10 1803（2018-04）：conhost 显著改进 UTF-8 代码页下的读写行为；同时引入系统级选项 "Beta: 使用 Unicode UTF-8 提供全球语言支持"——把 ACP/OEMCP 全局改为 65001（Wikipedia – Unicode in Microsoft Windows、akr.am 博客、Microsoft 官方说明）。
• 该选项的代价是又一次兼容性地震：依赖 ANSI 代码页的旧软件出现乱码或故障，已记录的受害者包括 nShift（官方文档建议关闭该选项）、Total Commander（乱码）、OpenJDK 的 System.in 读取异常 JDK-8356781（nShift、Ghisler 论坛、JDK-8356781）。"Beta"帽子长期未摘，正因为遗留程序生态没跟上。
• Windows Terminal：2019-05 Build 大会宣布开源，2020 年发布 1.0，Windows 11 22H2（2022-10）起成为默认终端；conhost 因必须兼容几十年存量程序而难以现代化，这正是 Terminal 以独立新进程另起炉灶的原因（TechCrunch 报道、DevBlogs、Microsoft Support）。注意：Terminal 解决的是渲染层（字体、图形单元），不解决编码错配。
• GB18030-2022：2022-07-19 由市场监管总局、国标委发布，2023-08-01 强制实施；收录 87,887 字（较 2005 版增收 1.7 万余个生僻字，覆盖《通用规范汉字表》全部用字），对齐 Unicode 11.0；2023 年新国标把字形（点阵）要求改为推荐性、编码要求保持强制性，且相对旧版有破坏性变更（国家标准全文公开系统、GB 18030 - Wikipedia、Ken Lunde: The GB 18030-2022 Standard、Unicode 联盟 L2/22-274《Disruptive Changes in GB 18030-2022》（Peter Constable））。破坏性变更举例（据 L2/22-274：相对 GB18030-2005 涉及 33 个字符、55 个码位，分三类）：① 36 处 GB18030↔Unicode 映射互换——18 个字符在 2005 版因 Unicode 尚未收录而映射到 BMP 私用区（PUA），Unicode 4.1 起它们获得正式码位（竖排形式 U+FE10–FE19、CJK 统一表意区 U+9FB4–9FBB），2022 版把映射对调；例：字"龴"在 GB18030 码位 FE59 的映射由 U+E81E（PUA）改为 U+9FB4，同时码位 82359037 的映射由 U+9FB4 改回 U+E81E；② 6 个"一字双码位"字符删除私用区码位（如 FE51 置空，仅保留四字节正式码位）；③ 9 个 CJK 兼容表意字符的码位置空（如 FD9C 原为 U+F92C，其正字为 郎 U+90CE）。冲击在"两难"：转码表（ICU 等）若更新，按 2005 版写入的存量数据解码错位；若不更新，与按 2022 版交换的数据互操作破裂。此外，2023-08 起的产品认证测试要求字体不得再给上述 PUA 码位配字形——删除字形即打断 2005–2022 年间按 PUA 码位创作的内容（无论内容以 Unicode 还是 GB18030 编码存储）。ICU 73.2、Java 21（并回移植 Java 8/11/17）已补齐对 GB18030-2022 的支持。

方向反转：这一阶段不再是"世界迁就 UTF-8"，而是"默认值替用户迁就 UTF-8"——把正确性从程序员的显式责任变为平台默认。驱动因素（此段为作者对两章材料的综合判断，非逐条引用来源）：AI 时代的语料管道（乱码即数据污染）、生僻姓名的政务/金融合规需求（身份证生僻字）、以及各运行时"默认即安全"的工程文化。

1.8 支线：规范化（Normalization）——课题名里最容易被忽略、事故率却极高的一环

Unicode 的"等价"分两种：规范等价（如组合音标的不同分解形态）与兼容等价（如全角/半角、连字）。UAX #15 定义四种规范化形式 NFC/NFD/NFKC/NFKD，要求比较语义的程序把规范等价串视为相等（UAX #15、Wikipedia – Unicode equivalence）。四种形式的系统对比，以及经典案例（macOS 文件系统 HFS+ 的 NFD 传统、APFS"字节袋"、Git"双胞胎文件"）的详述均见 2.2 节，此处只记教训：

教训："识别同一对象"的比较——字符串、缓存键、文件名——必须在入口统一规范化形式（推荐 NFC），否则同一个文件名就是两个对象；密码哈希、签名等逐字节安全比较则不做任何规范化，改为在注册入口固定一种形式并全程一致（统一口径见 2.2 节横向结论与 3.2 节建议 4）。

1.9 本机实测复核（2026-11-05，Windows 11 + Python 3.12.12，命令与输出如实摘录）

本次综合时独立重跑了两章共用的全部关键字节断言，结果与两章记录吻合（一处计数口径差异见编辑说明第 3 条）。以下为定稿时在写作机（Git Bash 会话，输出经管道捕获）重跑的真实命令与输出：$ 为提示符；-I（isolated）模式忽略所有 PYTHON* 环境变量，stdout 按 ANSI 代码页 gbk 编码（sys.stdout.encoding → gbk，本节输出的中文恰为 GBK 可表示字符，异常信息为 Python 原样报错）。代码块内不含任何编辑注解，注解统一见代码块后的"注"条目：

$ cmd //c chcp
活动代码页: 936
$ python -I -c 'import sys; print(sys.version)'
3.12.12 (main, Oct 10 2025, 12:42:57)  [GCC UCRT 15.2.0 64 bit (AMD64)]
$ python -I -c 'import locale,sys; print(locale.getpreferredencoding(False), sys.stdout.encoding)'
cp936 gbk
$ python -I -c 'print((b"\xef\xbf\xbd"*6).decode("gbk").encode("unicode_escape"))'
b'\\u951f\\u65a4\\u62f7\\u951f\\u65a4\\u62f7\\u951f\\u65a4\\u62f7'
$ python -I -c 'print((b"\xef\xbf\xbd"*3).decode("gbk"))'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
UnicodeDecodeError: 'gbk' codec can't decode byte 0xbd in position 8: incomplete multibyte sequence
decoding with 'gbk' codec failed
$ python -I -c 'print("\ufffd".encode("gbk"))'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
UnicodeEncodeError: 'gbk' codec can't encode character '\ufffd' in position 0: illegal multibyte sequence
encoding with 'gbk' codec failed
$ python -I -c 'print((b"\xcc"*6).decode("gbk"), "|", (b"\xcd"*6).decode("gbk"))'
烫烫烫 | 屯屯屯
$ python -I -c 'print("\u70eb".encode("gbk").hex(), "\u5c6f".encode("gbk").hex())'
cccc cdcd
$ python -I -c 'print("\u8a31\u529f\u84cb".encode("big5").hex(" "))'
b3 5c a5 5c bb 5c
$ python -I -c 'hits=[b for b in (bytes([h,t]) for h in range(0x81,0xFF) for t in range(0x40,0xFF) if t!=0x7F) if (c:=b.decode("gbk",errors="ignore")) and c.encode("gbk")==b and b[1]==0x5C]; print(len(hits), "".join(b.decode("gbk") for b in hits))'
118 乗俓僜刓匼哱嘰圽塡奬媆孿峔嶾廫怽慭抃揬擻昞朶梊榎橽歕沑淺漒瀄焅燶╘‐猏玕琝璡甛痋癨盶瞈砛碶礬禱穃竆筡篭籠糪絓綷縗繺羂耚肻腬臷芢荺萛蒤蔦薥蘚蚛蝄蟎衆裓襖覾診誠謀譢豛賊赲踈躙輁轡運郳醆鈂鉢鋅錦鎈鏫鑌閈闬隲靄韁頫颸餦馶騖骪鬨鮘鯸鱘鳿鵟鶿鸤黒齖
$ python -I -c 'print(126*190, 126*191)'
23940 24066
$ python -I -c 'hits=[b for b in (bytes([h,t]) for h in range(0x81,0xFF) for t in range(0x40,0x100) if t!=0x7F) if (c:=b.decode("gbk",errors="ignore")) and c.encode("gbk")==b and b[1]==0x5C]; print(len(hits))'
118
$ python -I -c 'hits=[b for b in (bytes([h,t]) for h in range(0x81,0xFF) for t in range(0x40,0xFF) if t!=0x7F) if (c:=b.decode("cp936",errors="ignore")) and c.encode("cp936")==b and b[1]==0x5C]; print(len(hits))'
118
$ python -I -c 'print([b.hex() for b in (bytes([h,0xFF]) for h in range(0x81,0xFF)) if b.decode("gbk",errors="ignore")])'
[]
$ python -I -c 'import unicodedata; e1="\u00e9"; e2="e\u0301"; print(len(e1), e1.encode("utf-8").hex(), len(e2), e2.encode("utf-8").hex(), "eq:", e1==e2, "nfc-eq:", unicodedata.normalize("NFC", e1)==unicodedata.normalize("NFC", e2))'
1 c3a9 2 65cc81 eq: False nfc-eq: True
$ python -I -c 'c=chr(0x20000); print(c.encode("utf-8").hex(), c.encode("gb18030").hex())'
f0a08080 95328236
$ python -I -c 'print(chr(0x20000).encode("gbk"))'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
UnicodeEncodeError: 'gbk' codec can't encode character '\U00020000' in position 0: illegal multibyte sequence
encoding with 'gbk' codec failed

注：

1. 第一条断言即"锟斤拷"机制：EF BF BD 连续 6 组共 18 字节，按 GBK 双字节重切为 EF BF/BD EF/BF BD…，\u951f\u65a4\u62f7 即 锟/斤/拷 ×3；其后 9 字节（奇数）那条为严格解码失败，encoding with 'gbk' codec failed 两条为严格编解码器对 U+FFFD 的双向拒绝。
2. 烫=0xCCCC、屯=0xCDCD，与 1.5/2.4 节的 MSVC Debug 填充值对应。
3. 許/功/蓋 三字 Big5 编码第二字节均为 0x5C，即"許功蓋問題"的字节证据。
4. 0x5C 计数口径：主遍历次字节 0x40–0xFE（剔除 0x7F），与 GBK 码位空间定义（首字节 0x81–0xFE × 次字节 0x40–0xFE = 126×190 = 23940）对齐；若把次字节扩到 0xFF，多出的 126 个候选（如 0x81FF）全部不是合法 GBK 双字节序列（decode 全部失败，故输出 []），因此不影响 118 的计数；cp936 与 gbk 两种 codec 计数相同。纵轴章记录的 116 属另一口径，见编辑说明第 3 条。
5. U+20000（扩展 B 区生僻字）：UTF-8 为 4 字节 f0a08080，GB18030 为 4 字节 95328236，GBK 严格编码直接失败——这是 2.1 节"GBK 永远追不上 Unicode 扩容"的字节证据。

1.10 纵轴小结：七股推力与遗留问题

七股推力：①硬件成本（1950–80 年代，7 位 ASCII 与双字节汉字都是"省比特"的产物，也为今日埋雷）；②本地化成本（1980–90 年代，每语言一个 localized 版本的商业模式难以为继，催生 Unicode）；③互联网全球化（1995–2010，RFC 2044/2279/3629 把 UTF-8 推上 Web 标准位，自同步设计是决定性优势）；④事故复利（2000–2019，utf8mb3、锟斤拷、0x5C 等真实故障持续教育行业）；⑤平台默认值收敛（2018–2026，JEP 400、PEP 686、PowerShell 7、Windows Terminal——把正确性下沉到平台默认）；⑥合规与监管（2000–2023，GB18030 系列的强制属性是中国市场的另一条硬约束线）；⑦向后兼容的引力（Windows ACP 体系、chcp 936 默认值三十年未动，是所有乱码问题长尾不消的结构性原因）。

遗留问题（截至 2026-11）：Windows 的 ACP 长尾仍在（本机 2026 年 Windows 11 控制台默认代码页仍是 936；"Beta UTF-8"选项普及缓慢，因为它对旧软件是破坏性的——乱码问题在新旧系统混合环境中还将长期存在）；运行时差异窗口（JDK < 18、Python < 3.15、PowerShell 5.1 与各自新版本的默认值不同，同一仓库多语言混合时的编码约定必须显式声明）；生僻字与多平面字符（GB18030-2022 的 87,887 字、CJK 扩展区与 emoji 的 4 字节 UTF-8）继续考验字体、输入法、数据库链路；规范化仍未被普遍执行（NFC/NFD 事故依旧高发，值得在编码规范中与"统一 UTF-8"并列为一等公民）。

二、横轴：横向对比（2026-11-05 时间截面）

本课题不是单一产品，而是一个技术知识域。因此横轴对比在三个"竞技场"中展开：A. 字符集/编码方案本身（ASCII、GBK 系、Unicode 系的替代方案之争）；B. Unicode 规范化形式（NFC/NFD/NFKC/NFKD）；C. Windows 控制台乱码的治理路线（chcp、系统级 UTF-8、终端换代、运行时默认值迁移）。统一对比维度：能力、成本、生态、成熟度、适用场景。

2.1 竞技场 A：编码方案横向对比

关键来源：Unicode 17.0.0 官方版本页（2025-09-09 发布，+4,803 字符，总数 159,801）；GB 18030 - Wikipedia、Ken Lunde: The GB 18030-2022 Standard、Unicode 联盟 L2/22-274：GB 18030-2022 破坏性变更 PDF；GB 三代关系见知乎专栏与腾讯云开发者社区；WHATWG Encoding Standard（"UTF-8 是浏览器唯一必须支持的编码"，官方文档）；UTF-8 起源与 RFC 3629 四字节上限见 Wikipedia: UTF-8 与 RFC 3629 (datatracker)。

逐维度结论：

• 能力：UTF-8 是唯一同时满足"全 Unicode 覆盖 + ASCII 逐字节透明 + 自同步"三项的方案。自同步意味着某个字节损坏或截断时，解析器最多丢失一个字符而不是整片文本，这对日志、网络流、断点续传是硬能力。GBK 系双字节方案无自同步：随机截断会把半个汉字和下一个字符粘连成一个错误码位。GB18030 因四字节结构可以覆盖全部 Unicode 码位（本机实测：U+20000 这种扩展 B 区生僻字，GBK 直接抛 UnicodeEncodeError，GB18030 编码为 4 字节 95 32 82 36，UTF-8 为 f0a08080），而 GBK 永远追不上 Unicode 的扩容速度——Unicode 17.0 已到 159,801 字符。
• 成本：纯英文文本 UTF-8 最省（1 字节）；CJK 密集文本 GBK 系更省（2 字节 vs UTF-8 的 3 字节），这是它当年存在的理由，也是今天它最后的护城河。代价是认知与转换成本：任何跨系统边界都需要一张"对方是什么编码"的约定表，而这张表恰恰是乱码事故的第一策源地。UTF-16 对 CJK 密集文本同样是 2 字节且无需多字节判定，但它有端序问题与代理对复杂性，且与 ASCII 文本互不透明，在传输/存储层全面让位 UTF-8，只剩"运行时内部表示"的生态位（Windows WCHAR、Java char/String、JavaScript 字符串）。
• 生态：浏览器侧已被 WHATWG 锁死为"UTF-8 only mandatory"；Go 语言规范强制源码为 UTF-8（go.dev/ref/spec）；Rust 的 String 类型本身就是 UTF-8（std::string::String 官方文档）；Node.js 文件系统 API 写入/追加默认 utf8、读取不指定编码时返回 Buffer（fs 官方文档）。相反阵营里，GBK 的生态位全靠 Windows 简体中文的 ANSI 代码页（CP936）与存量数据支撑。GB18030 的生态由法规推动：ICU 73.2、Java 21（回移植 Java 8/11/17）都补齐了对 GB18030-2022 的支持。
• 成熟度：ASCII 六十余年零改动；UTF-8 经 RFC 3629（2003）定型后同样冻结；GB18030-2022 是唯一在 2020 年代仍在"动"的方案（破坏性变更的具体内容与举例统一见 1.7 节 GB18030-2022 段），对销往中国市场的产品构成合规事件。
• 选型结论：2026 年新系统选型上，"UTF-8 还是 GBK"已不是技术之争而是存量迁移问题；真正需要思考的只剩三件事——中国合规（GB18030 覆盖）、东亚密集文本的存储成本权衡、以及与内部表示为 UTF-16 的宿主（Windows/Java/JS）打交道的边界转换。

2.2 竞技场 B：Unicode 规范化 NFC / NFD / NFKC / NFKD

编码之外，同一"字"的多个等价表示是第二重乱码源。Unicode 定义了四种规范化形式（UAX #15，unicode.org/reports/tr15）：

本机实测（见 1.9 节）：é（U+00E9，NFC）= 1 个码位 / UTF-8 字节 C3 A9；e + U+0301（NFD）= 2 个码位 / 字节 65 CC 81；二者 == 比较为 False，规范化后为 True。

真实踩坑案例（macOS 文件名）：HFS+ 时代强制把文件名存为 NFD 变体；APFS 改为"字节袋"（bag of bytes）——原样保存、但用规范化形式的哈希做查找，且 macOS 系统层创建文件时仍会做规范化，所以单机上看起来和 HFS+ 一样。一旦离开 Mac：Git 仓库里出现"看起来一样、字节不同"的双胞胎文件名——überschrift.txt 在 Mac 与其他平台之间变成两个"不同"文件，跨平台仓库出现"幻影未跟踪文件"，解决方案是 Git core.precomposeunicode=true（Mac 版初始化仓库时默认开启）；rclone/ZFS NAS（normalization=formD）与 SMB 共享出现 NFC/NFD 错配，都是这一机制的下游事故（SO #5581857: Git and the Umlaut problem、Tower 帮助文档、SmartGit 排障文档、Apple APFS 官方 FAQ、eclecticlight、mjtsai、rclone NFC 规避实践、TrueNAS 论坛案例）。

"规范化解决不了"的盲区（波ダッシュ問題）：日文波浪号在 Shift-JIS 中是字节 0x8160，按 JIS 标准映射为 U+301C WAVE DASH，按微软 CP932 映射表却是 U+FF5E 全角波浪号。同一串字节、两张官方映射表，数据在"MySQL ↔ Windows 程序""mb_convert_encoding 转码"往返后就"变字"了。这提醒我们：UTF-8 解决了"字节↔码位"的唯一性，但"码位↔字符意图"这一层仍存在厂商映射表分裂（波ダッシュはチルダではない（asahi-net）、波ダッシュ・全角チルダ問題（scrapbox）、UTF-8→SJIS-win→UTF-8 往返陷阱示例）。

横向结论：四种形式里 NFC 是唯一安全的"默认值"（长度短、语义无损）；NFKC/NFKD 只能用在"明知会损失"的归一场景（搜索索引、去重、slug）。统一口径：文件名、缓存键等"识别同一对象"的场景在入口统一 NFC 并禁用 NFKC/NFKD；密码哈希、签名等逐字节安全比较场景任何规范化都不能做——凭据的可登录性靠"注册入口固定一种形式并全程一致"的产品级约定保证，而非比较时归一化。规范化战争没有 UTF-8 那样的唯一赢家，只有"约定 + 边界转换"工程。

2.3 竞技场 C：Windows 控制台乱码治理路线

关键来源：Microsoft: Use UTF-8 code pages in Windows apps、Stack Overflow: chcp 65001 的问题史、DevBlogs: Windows Terminal as your Default Command Line Experience、Microsoft Support（22H2 起默认）、PEP 686、What's New in Python 3.15、JEP 400: UTF-8 by Default、inside.java 解读、Microsoft: Windows PowerShell 5.1 与 PowerShell 7 差异、about_Character_Encoding。

逐项说明：这张表的本质是"在哪个层修，就只在哪个层生效"。chcp 65001 只改会话代码页，救不了读文件；系统级 UTF-8 选项改得最彻底，但"Beta"标签自 2018 年（Windows 10 1803）引入以来挂了八年多仍未摘，正是因为遗留程序生态没跟上；Windows Terminal 解决的是渲染（字体、图形单元），不解决编码错配——这是最常见的误解之一；真正在"一劳永逸"意义上终结问题的，是第三条曲线：语言运行时把 UTF-8 变成默认值（JEP 400 于 JDK 18、PEP 686 于 Python 3.15），把"每个程序员必须懂编码"降级为"只有写边界代码的人才需要懂"。

2.4 真实踩坑案例集（逐案：现象 → 根因 → 修复）

字节级断言均经本机复核（见 1.9 节）；来源标注 URL。

1. print("中文") 报 UnicodeEncodeError: 'gbk' codec can't encode character。现象：打印中文勉强能看，打印 ✓、emoji 直接抛异常或变问号。根因：一条链上四层编码不一致——终端代码页（本机实测 936）、Python stdout（gbk）、区域首选（cp936）、源文件编码；GBK 字符集里没有 ✓（U+2713），编不出来就抛错。修复（按力度递增）：sys.stdout.reconfigure(encoding="utf-8")（3.7+）→ set PYTHONIOENCODING=utf-8 → chcp 65001 → PYTHONUTF8=1 → 升级 Python 3.15 让 PEP 686 默认接管（discuss.python.org 同款报错帖、Stack Overflow）。
2. 「手持两把锟斤拷，口中疾呼烫烫烫」。现象与机制见 1.5 节、字节见 1.9 节。教训：看到"有意义的乱码词"要立刻意识到发生了两跳转换，此时单跳重编码已不可逆，必须回到原始字节层定位（CSDN 考据文、百度百科词条）。
3. Excel 打开 UTF-8 CSV 中文全乱。现象：Notepad++ 里好好的 CSV，Excel 双击打开中文全是乱码。根因：Excel 不默认用 UTF-8 解释无 BOM 文件。修复：导出时用 utf-8-sig（写 EF BB BF BOM），或走"数据→从文本/CSV 导入"手动选 65001，或导 UTF-16 LE。对照结论：这是 UTF-8 阵营内部"无 BOM 派"（Web/Unix 惯例）与"带 BOM 派"（Windows 应用检测）的路线冲突，属于"边界约定"问题（learningbox、Stack Overflow）。
4. 同一个 .ps1 脚本，PowerShell 5.1 乱码、PowerShell 7 正常。根因：5.1 对无 BOM 脚本按 ANSI 解析（中文系统即 GBK），Out-File 默认 UTF-16LE、Set-Content 默认 ANSI、且 -Encoding UTF8 强制带 BOM；PS7 全家桶统一 utf8NoBOM。修复：脚本存为 UTF-8 带 BOM 兼容两端，或全量迁 PS7（Microsoft 官方差异文档、about_Character_Encoding）。
5. Mac 上好好的 Git 仓库，到 NAS/Windows 出现"同名"双胞胎文件。现象：文件名里带 é、注音或韩文的项目，rclone 同步后出现两份肉眼相同的文件。根因：macOS 层创建时规范化为 NFD，而其他端写 NFC；APFS 本身按字节存储。修复：入口统一 NFC（创建前 normalize('NFC')）、NAS 上不做归一化、同步工具启用 NFC 转换开关（来源见 2.2 节）。
6. 升级 JDK 18 后，老系统读配置文件"悄悄变了"。根因：JEP 400 把标准 API 默认字符集从"平台相关"（Windows 中文环境曾是 GBK）改为固定 UTF-8，file.encoding 属性含义也随之调整；此前依赖平台默认值隐式编码的代码升级后行为漂移，且因不抛错而更危险。修复：迁移时用 -Dfile.encoding=COMPAT 过渡、显式声明关键读写编码（JEP 400、inside.java 官方解读）。
7. Python 3.15 落地 PEP 686 之后的迁移问题。UTF-8 模式默认开启后，Windows 上 open() 不带 encoding= 的隐式读写从本地编码（GBK/CP1252）变为 UTF-8；读取存量 GBK 文件的脚本会开始报解码错。修复：对历史数据显式 encoding='gbk'/'gb18030'，其余让默认值接管；不兼容场景用 PYTHONUTF8=0 退出（PEP 686、What's New in Python 3.15、Windows 侧迁移指南）。
8. GB18030-2022 强标合规踩坑。现象：面向中国大陆销售的产品（含字体渲染、存储、传输的软硬件）需要按 2023-08-01 起实施的强制国标覆盖 87,887 个字符，并对齐 Unicode 11.0；只装 GBK 字库的老系统显示"豆腐块"。要点（标准发布、字形改推荐、破坏性变更举例、运行库支持现状等细节统一见 1.7 节 GB18030-2022 段，此处不重复）。修复路径：字体与运行库升级 + 验收用生僻字样张（含扩展 B 区以上字符）；若存量内容用到了 2005 版的 PUA 映射码位（U+E7xx/U+E8xx），还需按 1.7 节破坏性变更举例逐项核对（来源见 1.7 节 GB18030-2022 引文）。
9. 本机活体案例：这台开发机自己就是"土壤"。本稿实测（1.9 节）：cmd /c chcp → 活动代码页: 936；sys.stdout.encoding → gbk；locale.getpreferredencoding(False) → cp936。也就是说在 2026 年 11 月的简体中文 Windows 上，控制台默认编码链仍是 GBK，Windows Terminal 的默认化只解决了"显示"不解决"编码"，直到语言运行时默认值（Python 3.15 / 早已就绪的 Go/Rust）替你兜底。

2.5 成本与选型：决策矩阵

2.6 三个执行落点：破坏性变更的存量影响、边界转码操作清单、本机改造 checklist

前三节回答"选什么"，这一节回答"落地时先做什么"。三项内容均以本稿其余章节的结论为依据；其中工具与命令为作者综合整理的操作建议，非标准条文。

(a) GB18030-2022 破坏性变更：影响谁的存量数据（举例详见 1.7 节，此处记落地影响与自查）

• 转码链路：任何仍按 2005 版映射表实现的 GB18030 转码器（未跟进 2022 口径的旧版 ICU/运行库），读写 2005–2022 年间写入的 GB18030 数据时，会在 1.7 节所列 18 对互换映射上产生"错字"。自查方法：对存量数据抽样检索 U+E7xx/U+E8xx 私用区字符与竖排形式 U+FE10–FE19；命中即核对该记录的写入年份与所用实现的支持版本（ICU 73.2、Java 21 起为 2022 口径）。
• 字体与内容：2005–2022 年间按 PUA 码位（U+E7xx/U+E8xx）排版或入库的内容，在 2023-08 后通过认证、不再给这些码位配字形的新字体上直接显示为"豆腐块"。
• 兼容字符：9 个 CJK 兼容表意字（如 U+F92C→其正字 郎 U+90CE）的 GB18030 码位被置空后，按旧码位写入的字节在 2022 口径下成为非法序列。

(b) "存量 GBK 数据不动、边界转码"的边界清单

round-trip 校验的通用写法：先证无损——b.decode(src).encode(src) == b；再落盘——b.decode(src).encode('utf-8')；最后三重对账——行数、哈希、抽样人工目检。

(c) 本机改造 checklist（按 3.2 节判断二的投入顺序排列：运行时默认值 → 应用显式声明 → 会话级 → 系统级；自上而下逐项执行并验证）

1. 装 Windows Terminal 并设为默认终端（Windows Terminal 设置 → 启动 → 默认终端应用）。验证：新开控制台渲染正常。记住：这只修渲染层，不修编码（2.3 节）。
2. 给 Python 固定 UTF-8 默认值：setx PYTHONUTF8 1（升级 Python 3.15 后由 PEP 686 默认接管，无需再设）。验证：新开终端跑 python -c "import sys; print(sys.flags.utf8_mode, sys.stdout.encoding)" → 应输出 1 utf-8。
3. 脚本统一 PowerShell 7（winget install Microsoft.PowerShell），存为 UTF-8；如需兼容 PS5.1 用带 BOM。验证：同一含中文脚本在 PS5.1 与 PS7 输出一致（2.4 案例 4）。
4. Git 显示配置：git config --global core.quotepath false（中文文件名直接显示；Mac 协作者另加 core.precomposeunicode=true，2.2 节）。验证：git status 不再输出八进制转义文件名。
5. 编辑器统一 UTF-8：VS Code 设 "files.encoding": "utf8"（不带 BOM），避免误存 GBK。验证：状态栏显示 UTF-8，中文注释跨工具不乱。
6. 会话级救火：临时跑老脚本前 chcp 65001（仅当前会话；涉及批处理先测，1.5 节）。验证：cmd /c chcp 输出 65001。
7. 不做的事：遗留程序密集的机器不要开"Beta: 使用 Unicode UTF-8"系统选项（nShift、Total Commander、JDK-8356781 类先例，见 1.7 节）；确要开启，先逐应用验证存量软件。
8. 总验证：cmd /c chcp（会话代码页）+ python -c "import locale,sys; print(locale.getpreferredencoding(False), sys.stdout.encoding)"，与 1.9 节基线（cp936 / gbk）对照，确认变更已生效或仍待处理。

三、交叉洞察：两轴合起来说明了什么

纵轴回答"坑是哪年挖的"，横轴回答"坑现在分布在哪、哪条路线还在修"。两轴交叉，能读出五条单章看不出来的规律，以及一套可以直接执行的行动建议。

3.1 五条交叉规律

规律一：每一代乱码都是上一代解决方案的副产品——编码史是一部"分层地质史"。 ASCII 为省字节只给 7 位，高位字节从此成为无主之地（1963 年的决定）；于是双字节国标为避让高位而造出 0x5C 陷阱与 GB2312 的覆盖局限（1980–1995）；Unicode 为统一字典引入"等价"概念，NFC/NFD 分歧随之出现（1991 起）；UTF-8 解码失败的替换符 U+FFFD 被 GBK 重读，又"制造"了锟斤拷（1995 年后）；而厂商映射表分裂（波ダッシュ問題）则在"码位↔字符意图"这一 UTF-8 没有覆盖的层上继续产坑。今天横轴上能观察到的每一条坑，都能在纵轴上找到出生日期——这意味着乱码不会"被根治后消失"，只会随新的抽象层出现而换形态；排查乱码时，"这个坑是哪一层、哪一年引入的"本身就是最好的线索。

规律二：标准在"传输与存储层"决胜，Windows 控制台是最后的堡垒。 UTF-8 的胜出发生在协议与文件层（WHATWG 强制、Go/Rust 源生、RFC 3629 定型），而 Windows 因为向后兼容的引力——NT 内核内部 UTF-16 + ACP 双轨体系——让 CP936 默认值三十年未动（本机 2026-11 实测 chcp 仍输出 936）。两轴共同证明：显示层不是编码问题的主因。Windows Terminal 成为默认终端（Win11 22H2 起）只解决渲染，不解决编码错配——这是横轴治理路线表里最容易被误读的一行，也是"换了新终端还乱码"这类工单的答案。

规律三：2018–2026 的主线不是"谁打败了谁"，而是"正确性从程序员责任下沉为平台默认"。 纵轴显示：JEP 400（2022）、PEP 686（2025）、PowerShell 7、Go/Rust 源生，全部在做同一件事——把"必须懂编码"的门槛从所有程序员降级为"只有写边界代码的人"。横轴的治理路线表则给出这张地图的读法：运行时默认值 > 应用显式声明 > 会话/终端代码页 > 系统级选项，越往下覆盖越广、成本越低；越往上副作用越大、越不推荐。据此可以给出一个反直觉但两章证据一致的结论：终结乱码的不是 Windows，而是语言运行时——Windows 自己（ACP、Beta 选项）至今仍是长尾本身。

规律四：法规是独立于技术胜负的第二条战线，GB18030 是两条线的合流点。 纵轴上，GB18030 系列 2000 年起步即为强制性基础标准、2022 版 2023-08-01 强制实施，与 Unicode 扩容并行推进；横轴上，它是唯一在 2020 年代仍在"动"且带破坏性变更的方案，ICU 73.2、Java 21 跟进支持。对技术判断而言，这意味着"全站 UTF-8"在中国市场并不能免除 GB18030 覆盖义务——技术选型说"选谁"，法规说"至少得支持谁"，两者同时成立。GB18030 作为 GBK 的法定超集，也为存量迁移提供了"合法终点"：数据可以不动，但面向中国市场交付的系统必须能覆盖 87,887 字（含生僻字样张验收）。

规律五：乱码形态学——两轴合璧构成一张"看现象定层"的诊断表。 纵轴解释每个签名的成因，横轴给出对应的修复层：

排乱码的正确顺序是：先认签名，再问层，最后才动手转码——成词乱码（两跳转换）是唯一不可逆的一类，遇到它时任何"转码修复"都是二次破坏。

3.2 对用户的判断与建议

三个判断：

1. "2026 年选 UTF-8 还是 GBK"已不是技术问题，而是存量迁移与边界约定问题——技术之争在 RFC 3629（2003）定型时就已结束。
2. 乱码治理的投入顺序是：固定运行时默认值（成本最低、覆盖最广）→ 应用显式声明编码 → 会话级 chcp → 系统级"Beta UTF-8"选项（成本最高、副作用最大，遗留程序密集时不可用）。
3. 编码规范里应把"统一 UTF-8"与"统一 NFC"并列为一等公民——后者事故率不低、可见度却远低于前者（锟斤拷至少"看得见"，NFC/NFD 错配是"看不见的字节分歧"）。

六条行动建议：

1. 新项目：UTF-8 无 BOM 端到端，全部读写显式 encoding=；CI 固定 PYTHONUTF8=1、-Dfile.encoding=UTF-8，脚本统一到 PowerShell 7。
2. 存量 GBK 数据：不动数据、边界转码（边界清单见 2.6 节）；确需合规则分批迁 GB18030-2022（GBK 的法定超集），转换窗口期配校验与生僻字样张。
3. Windows 开发机：Windows Terminal + PYTHONUTF8=1（或 sys.stdout.reconfigure）分层治理（按序操作清单见 2.6 节）；遗留程序密集的机器不要开"Beta: 使用 Unicode UTF-8"系统选项（nShift、Total Commander、JDK-8356781 类故障先例）。
4. 比较与哈希：文件名、缓存键等"识别同一对象"的场景入口统一 NFC（Mac 上 Git 确认 core.precomposeunicode=true）；密码哈希、签名等精确字节比较不做任何规范化——凭据如需应对输入法差异，只能在注册入口固定一种形式（无损则 NFC）并在登录、改密全链路一致，而不是在比较时归一化；只有搜索索引、去重、slug 允许 NFKC/NFKD。
5. 数据库：utf8mb4 全链路（服务端/库/表/连接四处），utf8mb3 已弃用；日文数据额外注意 CP932 映射表分裂（波ダッシュ）。
6. 排查乱码：先认"乱码签名"（3.1 规律五的诊断表），再定位层（源文件编码 → 运行时 I/O 默认 → 终端代码页 → 字体/字库）；成词乱码直接回原始字节层。

一句总评（沿用横轴结论并经纵轴验证）：2026 年的字符编码格局是"一个赢家（UTF-8）、一个法定陪跑（GB18030）、一个只剩内部表示的亚军（UTF-16）、以及一层永远需要工程约定的边界（规范化与控制台）"。

四、参考来源

（分组合并两章来源，URL 原样保留）

• ASCII 史：Wikipedia – ASCII ｜ ASCII-1963 ｜ landley.net 标准对照
• 中文国标线：GB/T 2312-1980 全文公开页 ｜ 维基百科 – 汉字内码扩展规范 ｜ GB18030-2022 全文公开页 ｜ GB 18030 - Wikipedia ｜ Ken Lunde: The GB 18030-2022 Standard ｜ Unicode 联盟 L2/22-274：GB 18030-2022 破坏性变更 PDF ｜ GB 三代关系（腾讯云） ｜ 知乎：GB 三代关系 ｜ 支付宝生僻字方案：GB18030 说明 ｜ Wikipedia – Code page 936) ｜ 维基百科 – 大五碼
• Unicode/UTF-8：Wikipedia – Unicode ｜ History of Information ｜ Unicode 官方史页 ｜ Rob Pike 的 UTF-8 历史原始文本 ｜ Rob Pike 博客 ｜ RFC 3629 ｜ RFC 3629 (datatracker) ｜ Wikipedia – UTF-8 ｜ UAX #15 ｜ Unicode 17.0.0 版本页 ｜ WHATWG Encoding Standard ｜ Go 语言规范 ｜ Rust std::string::String（UTF-8 编码） ｜ Node.js fs 官方文档 ｜ Wikipedia – Unicode equivalence
• Windows 控制台：Super User 269818 ｜ SO 57131654: chcp 65001 问题史 ｜ mattn: Please stop hack "chcp 65001" ｜ xiph/flac #894 ｜ Wikipedia – Unicode in Microsoft Windows ｜ Microsoft: Use UTF-8 code pages ｜ akr.am: UTF-8 in Windows Terminal ｜ nShift 公告 ｜ Ghisler 论坛（Total Commander） ｜ JDK-8356781 ｜ TechCrunch: Windows Terminal ｜ DevBlogs: Windows Terminal as Default ｜ Microsoft Support（22H2 起默认） ｜ Build 2019 FAQ ｜ Tech Community: 记事本 1903 ｜ Super User: Notepad 默认编码
• 运行时默认值：PEP 3120 ｜ PEP 686 ｜ What's New in Python 3.15 ｜ pydevtools 解读 ｜ Pixelstech：什么会坏 ｜ windowsforum: Python 3.15 Windows 迁移指南 ｜ JEP 226 ｜ JEP 400 ｜ inside.java JEP 400 解读 ｜ JDK-8286998 ｜ Oracle 文档：properties ｜ MySQL 8.0 官方文档：utf8mb3 字符集（弃用说明） ｜ Microsoft Learn – about_Character_Encoding ｜ PS 5.1 vs 7 差异 ｜ SO 40098771
• 乱码案例与规范化：微软 CRT 调试堆文档 ｜ 知乎：烫烫烫屯屯屯那些事 ｜ evilpan: About Unicode ｜ 维基百科 – 锟斤拷 ｜ 长亭百川云笔记 ｜ CSDN 考据文 ｜ 百度百科 – 锟斤拷 ｜ iT 邦幫忙：許功蓋 ｜ 黑暗執行緒：VS2015 Big5 兼容问题 ｜ HN: utf8mb4 ｜ DBA SE: emoji ｜ discuss.python.org: GBK 报错 ｜ SO 55774642 ｜ learningbox: CSV BOM ｜ SO 6002256: Excel UTF-8 ｜ SO 5581857: Git and the Umlaut problem ｜ Tower 文档 ｜ SmartGit 文档 ｜ Apple APFS FAQ ｜ eclecticlight: APFS ｜ mjtsai: bag-of-bytes ｜ rclone NFC 实践 ｜ TrueNAS 论坛案例 ｜ asahi-net: 波ダッシュ ｜ scrapbox: 波ダッシュ問題 ｜ nanasess: 往返陷阱示例 ｜ Git core.quotepath

五、编辑说明：两章矛盾的消解、去重与本次修订记录

矛盾消解（3 处）

1. "烫/屯"的栈/堆归属相反。纵轴章：0xCC 填未初始化栈内存（显示"烫"）、0xCD 填 Debug 堆新分配内存（显示"屯"）；横轴章案例 2 把两者对调（0xCC 写作"堆"、0xCD 写作"栈"）。本稿采用纵轴版本，依据：微软 CRT 调试堆文档将 0xCD 定义为堆新分配（"Clean"）填充值，而 0xCC 是编译器对栈帧的填充值且恰为 INT 3 断点指令；字节映射（烫=cccc、屯=cdcd）两章实测一致，本稿复核亦一致（1.9 节）。
2. GBK 汉字数 21003 vs 20902。两个数字口径不同、均成立：20902 是 GBK 收录的 Unicode CJK 统一表意文字主体数量（U+4E00–U+9FA5 恰为 20902 个码位）；21003 是 GBK 规范自称的汉字总数（含部首与构件）。本稿统一表述为"23940 码位、收录 21003 个汉字（含部首/构件，其中对应 Unicode CJK 统一表意文字主体 20902 个）"。
3. 第二字节为 0x5C 的 GBK 字符数：纵轴章记录 116，本稿复核（首字节 0x81–0xFE、次字节 0x40–0xFE 剔除 0x7F 遍历，cp936 与 gbk 两种 codec）均为 118，差异约 2 个字符，属统计口径差异，不影响"百余个字符踩 0x5C 雷"的结论。复核遍历口径已与 GBK 码位空间定义（次字节 0x40–0xFE，126×190=23940）对齐：次字节若扩至 0xFF，多出的 126 个候选全部不是合法 GBK 双字节序列（解码全部失败），不影响 118 的计数（实证见 1.9 节"注"第 4 条）。另将 Big5 公布年份统一为"1984 年前后（一说 1983 年底完成制订、1984 年公布）"，该表述已回填 1.1 时间线与 1.3 节正文，与两章各自的记录兼容。

去重（按组归并，单一详述位置如下）：锟斤拷/烫烫烫机制（→1.5 节详述，2.4 案例 2 只留签名与教训）；macOS NFC/NFD 案例（→2.2 节详述，1.8 节只留一句教训并指向 2.2）；chcp 65001 历史（→1.5 节叙述，2.3 节仅保留路线表行）；GB18030-2022 细节（发布信息、字数、字形改推荐、破坏性变更举例→1.7 节详述，2.1 节保留对比表行，2.4 案例 8 只留现象与修复并指向 1.7）；JEP 400/PEP 686（细节→1.7 节，2.3 节为路线表行，2.4 案例 6/7 保留案例视角的修复路径）；本机实测记录（→1.9 节，其余位置仅引用）。

本次修订（2026-11-05，按独立审读意见逐条落实）

1. 统一密码/凭据规范化口径：TL;DR、1.8 教训、2.5 决策矩阵三处改为与 2.2 横向结论、3.2 建议 4 一致——文件名/缓存键等"识别同一对象"场景入口统一 NFC 并禁用 NFKC/NFKD；密码哈希、签名等逐字节安全比较不做任何规范化，改为注册入口固定一种形式并全程一致。
2. 2.3 节"Beta 标签挂了近二十年"更正为"自 2018 年（Windows 10 1803）引入以来挂了八年多仍未摘"，与本稿 1.7 节时间线一致。
3. 方法说明与 1.9 节统一为"一处计数口径差异"；"nShift On"更正为"nShift"；Big5 年份表述回填正文。
4. GBK 码位空间与复核遍历口径统一为次字节 0x40–0xFE，并在 1.9 节以实测说明次字节 0xFF 的 126 个候选全部非法、不影响 118 的计数。
5. 去重落地：macOS NFC/NFD 案例合并至 2.2 节（1.8 节只留教训并指向 2.2）；GB18030-2022 细节固定在 1.7 节，2.1"成熟度"与 2.4 案例 8 改为交叉引用；去重清单与正文实际对应。
6. 1.7 节驱动因素段明确标注为作者综合判断；Node.js/Rust/MySQL utf8mb3 弃用三处补官方文档引用。
7. 1.9 节命令与输出重新在本机如实摘录（2026-11-05 实测）：注解全部移出代码块；补齐 0x5C 遍历、0xFF 候选合法性、U+20000 GBK 编码失败三条真实命令行；声明 -I 模式忽略 PYTHON* 环境变量。
8. 新增 2.6 节：GB18030-2022 破坏性变更的存量影响与自查、边界转码操作清单、本机改造 checklist；1.7 节补入 Unicode 联盟 L2/22-274 的破坏性变更具体举例（33 个字符/55 个码位，三类变更）。

章节来源：

• 纵轴章：D:/CodexData/nightshift/output/reports/parts/2026-11-05-字符编码全景-ASCII-GBK-UTF8-规范化-Windows控制台乱码-vertical.md
• 横轴章：D:/CodexData/nightshift/output/reports/parts/2026-11-05-字符编码全景-ASCII-GBK-UTF8-控制台乱码-horizontal.md