Unicode、UTF-8与code pages的区别是什么？三者有何关联？

三者分属计算机文本处理体系的不同层级，绝大多数人搞混三者关系，本质是没理清技术演进的先后逻辑，逐个拆解本质差异：

代码页（Code Page） #

• 本质是计算机发展早期的区域性自定义字符映射规则，是第一代实用化的文本编码方案
• 诞生背景是早期电脑没有统一标准，不同地区的厂商为了让设备能显示本地语言，各自制定了一套“字节值和字符的对应表”：比如中文区使用的GBK对应代码页936、日文区使用的Shift-JIS对应代码页932、西欧多语言使用的ISO-8859-1对应代码页28591，连最基础的纯英文ASCII都是编号437的代码页
• 天生缺陷是没有全局统一规则：每个代码页只收录对应区域的常用字符，用A代码页存的文本，拿到配置为B代码页的系统里打开时，字节和字符的映射关系对不上，就会出现乱码。比如把代码页936存的中文文件拷到默认配置代码页932的日文系统里，系统会按日文规则解码中文字节，出来的全是无法识别的乱码

Unicode #

• 本质是面向全球的统一字符索引标准，从根上解决代码页各自为政的痛点
• 核心逻辑非常简单：给全世界所有可书写的字符（不管是中文、英文、阿拉伯文、古文字还是emoji）分配一个全局唯一的数字编号，也就是码位，格式为U+XXXX，覆盖范围从U+0000到U+10FFFF
• 关键认知：Unicode本身完全不规定这个数字编号在磁盘、内存、网络里要怎么转成字节存储、传输。它本质就是一张全量的“字符-唯一ID”总对照表，和实际的存储规则没有任何绑定关系

UTF-8 #

• 本质是Unicode最普及的字节存储实现方案
• 设计初衷是解决固定长度存Unicode码位的空间浪费问题：如果直接给每个字符的码位分配3-4个固定字节存储，纯英文文本的体积会比原来的ASCII编码大3-4倍，资源损耗非常严重。UTF-8据此设计了一套变长的编码规则：
  • 英文范围内的常用字符，用1个字节存储，和原版ASCII编码完全兼容
  • 中文常用汉字，用3个字节存储
  • 生僻字、特殊符号、emoji，用4个字节存储
• 额外优势是自带自校验能力，就算传输过程中丢失了字节，也能快速定位下一个字符的起始位置，不会因为错位解码导致后续全段乱码

三者是顺着计算机文本处理的发展脉络一脉传承下来的，并非完全割裂的独立方案：

1. 发展顺位上，代码页是第一代区域编码方案，因为跨区域传文本乱码的痛点过于突出，业界才联合推出Unicode全局统一字符总表，把所有历史代码页里收录的字符全部纳入统一索引，给每个字符分配固定的唯一编号，彻底告别“每个地区一套映射表”的混乱状态
2. 实现依赖上，Unicode只是一张没有存储能力的索引表，没法直接用来存文件、传网络，所以才衍生出包括UTF-8、UTF-16、UTF-32在内的多种存储规则，把Unicode的码位转换成可以实际写入磁盘、在网络上传输的字节流
3. 兼容关系上，现在主流的UTF-8编码和最早的ASCII代码页是100%兼容的，老的英文系统、工业软件不需要修改，就能正常读取UTF-8格式的英文文本。而原本的代码页现在只是作为遗留兼容层存在于系统中，用来读取几十年前用区域编码存储的老文件，比如Windows里提到的“ANSI编码”，本质就是调用当前系统区域对应的历史代码页做解码

常见认知误区：很多人会把UTF-8等同于Unicode，实际上UTF-8只是Unicode标准下的一种实现方式而已，除此之外还有Windows桌面端常用的UTF-16、内存处理常用的UTF-32等不同实现；另外也不要把代码页当成完全过时的技术，现在很多嵌入式设备、工业控制系统里，还在沿用固定的代码页处理文本，适配硬件的有限存储能力。日常写代码碰到的解码乱码问题，大半都是没搞清楚字节流的实际编码规则——把代码页编码的内容直接套UTF-8规则解码，自然会出现满屏乱码。

内容的提问来源于stack exchange，提问作者user13229658