UTF-8 发展历史以及与 UTF-16/GBK 之间的差异

UTF-8 出现的时间及目的

UTF-8（8-bit Unicode Transformation Format）于1992年由Ken Thompson和Rob Pike在Plan 9操作系统开发过程中首次提出，并于1993年正式标准化。它是为了解决以下问题而设计的：

1. 兼容ASCII：早期计算机系统广泛使用ASCII（7位编码，仅支持128个字符，主要是英文字符）。UTF-8设计为前128个字符与ASCII完全兼容，确保现有ASCII文本无需转换即可使用。

2. 支持多语言：随着全球化的发展，计算机需要处理多种语言的字符（如中文、日文、阿拉伯文等）。Unicode旨在为所有字符分配统一编码，但需要一种高效的编码方式来存储和传输。UTF-8通过变长编码（1到4字节）支持Unicode字符集，既节省空间又能表示全球字符。

3. 效率与灵活性：相比固定长度的编码（如UCS-2使用2字节），UTF-8在存储英文字符时更节省空间，同时能扩展到支持超过100万个字符。

UTF-8的修订历史

UTF-8自诞生以来经过了几次修订，主要是为了与Unicode标准同步并解决边缘问题：

1. 1993年（初始标准）：UTF-8首次定义，支持Unicode 1.0，最大编码范围为31位（5或6字节编码），理论上可表示2^31个字符。

2. 1996年（Unicode 2.0）：修订以支持 surrogate pairs（代理对），引入4字节编码，限制最大编码到U+10FFFF（21位），与UTF-16保持一致。废弃了5字节和6字节编码，因为Unicode字符集被限制在17个平面（0到16）。

3. 2003年（RFC 3629）：进一步规范化，明确禁止非最短编码形式（non-shortest form），以防止恶意编码（如用多字节表示单字节字符）导致的安全漏洞。最大编码范围固定为4字节（U+0000到U+10FFFF）。

4. 后续微调：随Unicode版本更新（如Unicode 15.0，2022年），UTF-8的编码规则未变，但支持的字符集随Unicode扩展而增加。修订主要集中在字符分配和规范化，而非编码方式本身。

UTF-8与UTF-16的差别

UTF-8和UTF-16是Unicode的两种编码方式，主要区别如下：

1. 编码方式：

   • UTF-8：变长编码，字符用1到4字节表示。ASCII字符（U+0000到U+007F）用1字节，中文等常用字符用3字节，罕见字符用4字节。

   • UTF-16：变长编码，主要用2字节表示基本多文种平面（BMP，U+0000到U+FFFF）的字符，超出BMP的字符（如部分emoji或罕见汉字）用4字节（surrogate pairs）。

2. 空间效率：

   • UTF-8：对英文文本效率高（1字节/字符），但中文等字符占用3字节，空间效率低于UTF-16。

   • UTF-16：对东亚语言（如中文、日文）效率较高（通常2字节/字符），但对英文文本效率低于UTF-8，且需要处理代理对，增加复杂性。

3. 兼容性：

   • UTF-8：完全兼容ASCII，广泛用于互联网（网页、邮件、JSON等）和文件系统。现代软件默认使用UTF-8。

   • UTF-16：不兼容ASCII，需字节序标记（BOM）区分大端/小端编码。常用于Windows系统和某些遗留应用（如Java、.NET早期版本）。

4. 错误处理：

   • UTF-8：字节序列严格，错误检测容易（如无效字节或非最短编码）。解析中断后易恢复。

   • UTF-16：代理对错误（如孤立代理码点）可能导致解析困难，错误恢复较复杂。

5. 应用场景：

   • UTF-8：主导互联网和跨平台应用，适合文本传输和存储，占全球网页编码的95%以上（2023年数据）。

   • UTF-16：在某些内部处理（如Windows API、Java字符串）中使用，但逐渐被UTF-8取代。

UTF-8MB4 是什么？

UTF-8MB4（MB4表示“4-byte UTF-8”）是 MySQL 数据库中对标准 UTF-8 编码的一种实现，用于支持完整的 Unicode 字符集，包括需要 4 字节编码的字符（如部分 emoji 和罕见汉字）。它本质上是标准 UTF-8 的子集，但专为 MySQL 设计，以解决早期 MySQL 中 UTF-8 编码的局限性。

背景与问题

MySQL 早期（5.5 版本之前）的所谓“UTF-8”编码实际上只支持最多 3 字节的 Unicode 字符（范围为 U+0000 到 U+FFFF，即基本多文种平面，BMP）。这意味着：

• 无法存储 4 字节的字符，如许多 emoji（如 U+1F60A）或某些罕见汉字（如 𰻝 U+30EDD）。

• 导致插入此类字符时出错（如“Incorrect string value”）或数据被截断。

为了解决这一问题，MySQL 引入了 UTF-8MB4，它完全支持 Unicode 的整个字符集（U+0000 到 U+10FFFF），包括需要 4 字节编码的补充平面字符。

UTF-8MB4 的特点

1. 编码范围：

   • 支持标准 UTF-8 的所有字符，包括 1 到 4 字节编码。

   • 特别针对补充平面（Supplementary Planes，如 emoji、罕见字符）优化。

2. 与标准 UTF-8 的关系：

   • UTF-8MB4 与标准 UTF-8 在编码规则上相同，只是 MySQL 内部的命名区分。

   • MySQL 的“UTF-8”实现（旧版）是阉割版，仅限 3 字节；UTF-8MB4 则是完整版。

3. 存储需求：

   • 与标准 UTF-8 一样，ASCII 字符占 1 字节，中文占 3 字节，emoji 等占 4 字节。

   • 相比 UTF-8MB3（MySQL 内部对 3 字节 UTF-8 的称呼），UTF-8MB4 对 4 字节字符的支持增加了一些存储开销。

4. 兼容性：

   • UTF-8MB4 完全兼容标准 UTF-8，任何有效的 UTF-8 数据都可以无缝迁移到 UTF-8MB4。

   • 需要注意客户端、连接和服务器字符集配置一致（如 utf8mb4_unicode_ci），否则可能出现乱码。

修订与发展

• 引入时间：MySQL 5.5.3（2010 年）正式引入 UTF-8MB4。

• 改进：

  • 校对规则（Collation）：MySQL 提供了多种 UTF-8MB4 校对规则，如 utf8mb4_unicode_ci（基于 Unicode 标准，通用）、utf8mb4_bin（二进制排序）等，优化排序和比较。

  • 性能优化：MySQL 8.0（2018 年）后，UTF-8MB4 性能进一步提升，成为默认字符集（取代 Latin1）。

• 现状：从 MySQL 8.0 开始，UTF-8MB4 是推荐和默认的字符集，广泛用于支持现代应用的国际化需求。

UTF-8MB4 与 UTF-16 的对比

与 UTF-16 的对比类似于标准 UTF-8（见前述回答），但在 MySQL 上下文中：

• UTF-8MB4：MySQL 的首选，适合互联网应用，支持所有 Unicode 字符，存储效率对英文高，传输兼容性好。

• UTF-16：MySQL 支持 UTF-16（通过 ucs2 或 utf16 字符集），但不常用，因其存储效率较低（固定 2 或 4 字节），且不兼容 ASCII。

应用场景

• Web 应用：支持 emoji 和多语言的社交媒体、聊天应用（如微信、Twitter）广泛使用 UTF-8MB4。

• 数据库迁移：从旧版 MySQL 的“UTF-8”（3 字节）迁移到 UTF-8MB4，以支持现代字符需求。

• 配置建议：在 MySQL 中，建议设置数据库、表、列、客户端连接均为 utf8mb4，校对规则选 utf8mb4_unicode_520_ci（基于 Unicode 5.2）或更高版本。

为什么在 UTF-8 之后创造 UTF-16？

UTF-8 和 UTF-16 都是 Unicode 的编码方式，UTF-16 的出现并不是因为 UTF-8 不足以支持上百万字符，而是由于历史、技术和应用场景的特定需求。以下是 UTF-16 诞生的背景、原因及其特别意义：

1. 历史背景与时间线

• Unicode 的早期发展：

  • Unicode 项目始于 1980 年代末，旨在为全球所有字符提供统一编码。最初，Unicode 计划使用固定 2 字节（16 位）编码，称为 UCS-2（Universal Character Set, 2-byte），可表示 65,536 个字符（U+0000 到 U+FFFF），足以覆盖当时已知的大多数常用字符（基本多文种平面，BMP）。

  • UTF-16 作为 UCS-2 的扩展，诞生于 1996 年（Unicode 2.0），引入了代理对（surrogate pairs）机制，将编码范围扩展到 U+10FFFF（约 110 万字符），与 UTF-8 的覆盖范围一致。

  • UTF-8 则在 1992-1993 年由 Ken Thompson 和 Rob Pike 提出，强调 ASCII 兼容性和变长编码（1-4 字节）。

• 时间线对比：

  • UTF-8 和 UTF-16 几乎同时发展，UTF-16 的前身 UCS-2 甚至早于 UTF-8 的广泛应用。两者是为不同需求设计的平行方案，而非 UTF-16 是 UTF-8 的“替代品”。

2. 创造 UTF-16 的原因

UTF-16 的创造主要基于以下需求和技术考量：

1. 固定长度编码的吸引力（早期）：

   • 在 Unicode 早期（1991 年，Unicode 1.0），认为 65,536 个字符足以覆盖所有语言的字符需求。UCS-2（UTF-16 的前身）使用固定 2 字节编码，简单且易于实现，适合当时的内存和处理能力有限的系统。

   • 相比之下，UTF-8 是变长编码（1-4 字节），需要更复杂的解析逻辑，在 1990 年代的硬件上处理效率稍低。

   • 意义：UCS-2/UTF-16 提供了简单、统一的编码方式，适合早期软件（如 Windows NT、Java）处理多语言文本。

2. 东亚语言的优化：

   • 东亚语言（如中文、日文、韩文）的字符主要集中在 Unicode 的 BMP（U+4E00 到 U+9FFF 等），每个字符在 UCS-2/UTF-16 中正好占用 2 字节，存储效率高且对齐整齐。

   • UTF-8 对这些字符需要 3 字节，空间效率稍逊（例如，中文文本在 UTF-8 中比 UTF-16 多占约 50% 空间）。

   • 意义：对于日本、韩国、中国等东亚地区，UTF-16（或其前身 UCS-2）在早期更适合处理本地化文本，尤其在内存敏感的环境中。

3. 与现有系统的兼容性：

   • 1990 年代，许多系统（如 IBM、Microsoft）已使用 2 字节编码（如 Shift-JIS、Big5）处理本地字符集。UCS-2/UTF-16 作为 2 字节编码的 Unicode 实现，易于与这些系统迁移和集成。

   • 例如，Windows NT（1993 年发布）采用 UCS-2 作为内部编码，后来升级支持 UTF-16。

   • 意义：UTF-16 降低了从传统编码（如 Shift-JIS）到 Unicode 的迁移成本，适合企业级系统（如 Windows、SQL Server）。

4. 代理对扩展的需求：

   • 当 Unicode 扩展到超过 65,536 个字符（1996 年，Unicode 2.0 引入补充平面）时，UCS-2 已不足以表示所有字符。UTF-16 通过代理对机制（使用 4 字节表示 U+10000 以上字符）扩展了编码范围，保持了与 UCS-2 的部分兼容性。

   • 意义：UTF-16 作为 UCS-2 的自然演进，允许现有系统平滑过渡到支持完整的 Unicode 字符集。

3. UTF-16 的特别意义

尽管 UTF-8 现已成为主流，UTF-16 在当时和某些场景中有其独特意义：

1. 历史过渡作用：

   • UTF-16（及其前身 UCS-2）是 Unicode 早期推广的关键。1990 年代，固定 2 字节编码被认为是一种简单直观的解决方案，得到 Microsoft、IBM、Apple 等公司的支持，推动了 Unicode 的普及。

   • 例如，Windows NT 和 Java 的早期采用奠定了 UTF-16 在企业级软件中的基础。

2. 特定领域的效率：

   • 对于东亚语言（如中文、日文、韩文），UTF-16 在 BMP 字符上的固定 2 字节编码比 UTF-8（3 字节）更节省空间，尤其在内存和存储成本较高的时代。

   • 在某些内存敏感的嵌入式系统或早期数据库（如 SQL Server）中，UTF-16 更易于处理。

3. 生态系统锁定：

   • Microsoft 的 Windows 生态（API、文件格式）、Java（字符串处理）、JavaScript（ECMAScript 标准）等选择 UTF-16 作为默认编码，形成了技术锁定效应。这些系统的影响力使 UTF-16 在特定领域持续使用。

   • 意义：UTF-16 的存在反映了技术生态的路径依赖，特别是在 Windows 和 Java 主导的 1990-2000 年代。

4. 为何 UTF-16 使用减少？

尽管 UTF-16 有其历史意义，但其局限性导致使用场景减少：

• 不兼容 ASCII：UTF-16 无法直接兼容 ASCII（需要 2 字节表示英文字符），而 UTF-8 完全兼容，适合互联网和文件系统。

• 复杂性：代理对（4 字节字符）增加了解析难度，错误处理（如孤立代理码点）更复杂。

• 存储效率：对英文文本，UTF-16（2 字节/字符）比 UTF-8（1 字节/字符）浪费空间；对补充平面字符，UTF-16 和 UTF-8 均需 4 字节，无明显优势。

• 互联网主导：UTF-8 因其在 Web（HTML、JSON）、Linux、macOS 和数据库（MySQL UTF-8MB4）中的广泛采用，成为事实标准（占网页编码 95% 以上，2023 数据）。

为什么 UTF-8 比 UTF-16 多一个字节？

你的问题可能指的是 UTF-8 在某些情况下（如存储东亚字符或补充平面字符）比 UTF-16 使用更多字节的情况，因为 UTF-8 是变长编码（1-4 字节），而 UTF-16 主要是 2 字节（或 4 字节用于代理对）。下面详细解释 UTF-8 和 UTF-16 的字节使用差异，以及 UTF-8 “多出的字节”存了什么。

1. UTF-8 和 UTF-16 的编码方式

• UTF-8：

  • 变长编码，使用 1 到 4 字节表示 Unicode 字符（U+0000 到 U+10FFFF）。

  • 字节分配：

    • 1 字节：U+0000 到 U+007F（ASCII 字符，如英文）。

    • 2 字节：U+0080 到 U+07FF（拉丁文、希腊文等）。

    • 3 字节：U+0800 到 U+FFFF（包括东亚字符，如中文、日文、韩文，位于基本多文种平面，BMP）。

    • 4 字节：U+10000 到 U+10FFFF（补充平面，如 emoji、罕见汉字）。

  • 每个字节的最高位用于标记：

    • 单字节：0xxxxxxx（ASCII）。

    • 多字节：首字节以 110xxxxx（2 字节）、1110xxxx（3 字节）、11110xxx（4 字节）开头，后续字节以 10xxxxxx（延续字节）开头。

    • 这些标记位确保解码器能识别字节序列的开始和长度。

• UTF-16：

  • 变长编码，主要使用 2 字节，部分字符用 4 字节（代理对）。

  • 字节分配：

    • 2 字节：U+0000 到 U+FFFF（BMP，覆盖大多数常用字符，包括东亚字符）。

    • 4 字节：U+10000 到 U+10FFFF（补充平面，使用代理对：高代理 U+D800 到 U+DBFF + 低代理 U+DC00 到 U+DFFF）。

  • UTF-16 不需要像 UTF-8 那样的复杂标记位，因为 BMP 字符固定 2 字节，补充平面字符通过代理对的固定范围识别。

2. 为何 UTF-8 比 UTF-16 多一个字节？

你提到的“多一个字节”可能主要针对 东亚字符（如中文、日文、韩文，U+0800 到 U+FFFF）。以下是具体分析：

• 东亚字符的存储：

  • UTF-8：中文等东亚字符（例如“汉” U+6C49）需要 3 字节。

    • 编码示例：“汉” (U+6C49) 的 UTF-8 编码为 E6 B1 89：

      • 首字节：1110xxxx（表示 3 字节序列）。

      • 后续字节：10xxxxxx 10xxxxxx（存储字符的位）。

  • UTF-16：同一字符只需要 2 字节。

    • 编码示例：“汉” (U+6C49) 的 UTF-16 编码为 6C 49（小端）。

      • 直接存储 Unicode 码点，无需额外标记。

• 多出的 1 字节存了什么？

  • UTF-8 的第 3 字节主要用于：

1. 标记位：每个字节的最高位（1110 或 10）用于标识字节序列的结构，帮助解码器区分首字节和延续字节。

   1. 数据位：UTF-8 将 Unicode 码点（例如 U+6C49 的二进制：01101100 01001001）拆分到多个字节中。3 字节编码提供 16 位数据空间（3 × 6 位有效数据，首字节 4 位 + 两个延续字节各 6 位），足以覆盖 U+0800 到 U+FFFF。

2. 具体来说，“汉” 的 UTF-8 编码 E6 B1 89：

   • E6：11100110（前 4 位 1110 表示 3 字节序列，后 4 位存储码点高位）。

   • B1：10110001（前 2 位 10 表示延续字节，后 6 位存储码点中位）。

   • 89：10001001（前 2 位 10 表示延续字节，后 6 位存储码点低位）。

   • 标记位（1110 和 10）占用额外空间，确保解码器能正确解析变长序列。

3. 相比之下，UTF-16 的 2 字节直接存储码点（6C 49），无需标记位，因此更紧凑。

4. 为什么 UTF-8 需要 3 字节而非 2 字节？

5. UTF-8 设计时优先考虑 ASCII 兼容性：

   • 1 字节编码（0xxxxxxx）留给 ASCII（U+0000 到 U+007F），确保英文字符与 ASCII 一致。

   • 这导致非 ASCII 字符（U+0080 以上）必须从 2 字节起步，而 2 字节（110xxxxx 10xxxxxx）只能表示 U+0080 到 U+07FF（11 位数据）。

   • 东亚字符（U+0800 到 U+FFFF）需要 16 位数据，因此必须用 3 字节（1110xxxx 10xxxxxx 10xxxxxx）。

6. UTF-16 没有 ASCII 兼容性要求，直接用 2 字节表示 BMP 字符，因此对东亚字符更节省空间。

3. 补充平面字符的对比

对于补充平面字符（U+10000 到 U+10FFFF，如 emoji U+1F60A），两者都用 4 字节：

• UTF-8：4 字节编码，例如 的编码为 F0 9F 98 8A。

  • 首字节 11110xxx 表示 4 字节序列，后续字节 10xxxxxx 存储码点数据。

• UTF-16：4 字节（代理对），例如 的编码为 D83D DE0A。

  • 高代理（D83D）和低代理（DE0A）各占 2 字节。

• 差异：两者字节数相同，但 UTF-8 的 4 字节包含标记位（11110 和 10），而 UTF-16 的代理对范围（U+D800 到 U+DFFF）本身起到类似标记作用。

4. UTF-8 多字节的权衡

UTF-8 的变长设计（包括多出的字节）是为了以下目标：

1. ASCII 兼容性：

   • UTF-8 确保 ASCII 字符只用 1 字节，这对英文文本和互联网协议（如 HTTP、JSON）至关重要。

   • UTF-16 用 2 字节表示 ASCII 字符，效率低且不兼容 ASCII。

2. 自同步性：

   • UTF-8 的标记位（0、110、1110、11110、10）使字节序列自同步，解码器可轻松定位序列起点，即使数据损坏也能快速恢复。

   • UTF-16 依赖代理对范围，错误（如孤立代理码点）更难检测。

3. 扩展性：

   • UTF-8 的 4 字节设计支持 U+10FFFF，足以覆盖 Unicode 所有字符，未来扩展空间充足。

5. 为何 UTF-16 对东亚字符更节省字节？

• UTF-16 的前身 UCS-2（固定 2 字节）设计时假设 65,536 个字符（BMP）足够覆盖所有语言，尤其优化了东亚字符（中文、日文、韩文多在 BMP）。

• UTF-16 继承了这一优势，对 BMP 字符直接用 2 字节，无需标记位。

• UTF-8 为了 ASCII 兼容性和变长编码的通用性，牺牲了东亚字符的存储效率（3 字节）。

GB2312、GBK 与 UTF 的出现时间及比较

出现时间

• GB2312：

  • 发布时间：1980年。

  • 正式实施：1981年5月1日。

  • 全称“信息交换用汉字编码字符集 基本集”，是中国大陆制定的第一个汉字编码国家标准。

• GBK：

  • 发布时间：1995年12月。

  • 全称“汉字内码扩展规范”，是对 GB2312 的扩展，由中国电子工业部和微软合作开发。

• UTF-8 和 UTF-16：

  • UTF-8：

    • 提出时间：1992年（由 Ken Thompson 和 Rob Pike 在 Plan 9 系统中设计）。

    • 标准化：1993年（纳入 Unicode 标准和 RFC 2279）。

  • UTF-16（及其前身 UCS-2）：

    • UCS-2（固定 2 字节编码）：1991年（Unicode 1.0 发布时）。

    • UTF-16（扩展到代理对）：1996年（Unicode 2.0 引入补充平面）。

  • Unicode 项目本身始于1988年，1991年发布 Unicode 1.0。

• 时间线对比：

  • GB2312（1980） > Unicode/UCS-2（1991） > UTF-8（1992-1993） > GBK（1995） > UTF-16（1996）。

  • GB2312 比 UTF-8 和 UTF-16 早约 10-15 年，GBK 晚于 UTF-8 但早于 UTF-16 的最终形式。

2. GB2312 和 GBK 出现的原因

GB2312 和 GBK 是为满足中国大陆的汉字处理需求而开发的编码标准，其出现与当时的技术环境、语言需求和国际化背景密切相关。

GB2312 的出现原因

1. 汉字处理需求：

   • 1970年代，中国计算机技术开始发展，但受限于硬件能力和软件生态，英文字符的 ASCII（7 位，128 个字符）无法表示汉字。

   • 汉字数量庞大（常用字约 3000-7000，全部字超过数万），需要专门的编码方案来支持中文输入、存储和显示。

2. 国家标准化需求：

   • 为规范信息交换（如政府、出版、电信），中国需要统一的汉字编码标准。

   • 1970年代末，中国启动了汉字编码研究，目标是制定一个覆盖常用汉字的字符集。

3. 技术背景：

   • GB2312 基于双字节编码（2 字节），每个字符用 94x94 的编码空间（区位码），共收录 6763 个汉字（一级 3755，二级 3008）及 682 个非汉字符号（如拉丁字母、标点）。

   • 编码范围：A1A1 到 FEFE（高字节和低字节均避开 ASCII 的 0x00-0x7F），兼容 ASCII（单字节表示英文）。

   • 设计简单，适合当时的计算机（如 8 位或 16 位系统）和终端设备。

4. 意义：

   • GB2312 是中国大陆第一个汉字编码国家标准，广泛用于早期计算机、打字机和信息系统（如 DOS 时代的中文软件）。

   • 推动了中文信息化（如电子出版、数据库），奠定了后续编码的基础。

GBK 的出现原因

1. GB2312 的局限性：

   • GB2312 只收录 6763 个汉字，覆盖常用汉字，但无法满足专业领域（如古籍、地名、人名）的需求。例如，许多罕见汉字（如“镕”）不在 GB2312 中。

   • 随着计算机普及，用户需要更全面的字符集来支持复杂文本处理。

2. 微软与 Windows 的推动：

   • 1990年代初，微软进入中国市场，Windows 95 的中文版需要支持更丰富的汉字集。

   • GB2312 字符集不足以支持 Windows 的字体库（如宋体、黑体）和应用程序需求，微软推动扩展编码以支持更多汉字。

3. 兼容性和扩展需求：

   • GBK（K 代表“扩展”）在 GB2312 基础上扩展，收录约 21,003 个汉字（包括 CJK 统一汉字）及更多符号，总字符数约 21,886。

   • 编码方式：

     • 仍用双字节编码，扩展到 81-FE（高字节）x 40-FE（低字节）。

     • 兼容 GB2312（GB2312 的字符编码在 GBK 中不变）。

     • 新增字符填充 GB2312 未用的编码空间。

   • GBK 还部分兼容 Unicode 的 CJK 统一汉字，试图与国际标准接轨。

4. 市场驱动：

   • GBK 成为 Windows 95/98 中文版的默认编码（CP936 代码页），广泛应用于软件、游戏和早期互联网（如 BBS）。

   • 它填补了 GB2312 和 Unicode 之间的过渡需求，尤其在 Unicode 尚未普及的 1990年代中期。

5. 意义：

   • GBK 解决了 GB2312 的字符覆盖不足问题，成为 1990-2000 年代中国大陆的主流编码。

   • 作为 GB2312 和 Unicode 的桥梁，GBK 在中文信息化中起到关键作用。

3. 为何出现 GB2312 和 GBK，而非直接用 UTF-8/UTF-16？

GB2312 和 GBK 的出现早于或与 UTF-8/UTF-16 同时期，主要是因为以下原因：

1. 时间和技术限制：

   • GB2312（1980）：

     • 1980年，Unicode 项目尚未启动（1988年才开始），国际统一的字符编码不存在。

     • 计算机硬件（8 位 CPU、有限内存）难以支持复杂的多语言编码，GB2312 的双字节设计更适合当时的系统。

     • 中国急需本地化编码来支持中文信息化，GB2312 是为特定语言（汉语）定制的解决方案。

   • GBK（1995）：

     • 1995年，Unicode 和 UTF-8 刚起步（UTF-8 1993年标准化），但尚未成熟或普及。

     • 软件生态（如 DOS、Windows）仍以本地编码为主，UTF-8 的变长编码（1-4 字节）在解析效率和兼容性上不占优势。

     • GBK 提供了快速、兼容的解决方案，适应 Windows 和本地软件需求。

2. 本地化需求：

   • GB2312 和 GBK 专为中文设计，针对汉字的编码空间和使用习惯优化：

     • GB2312 覆盖常用汉字，适合政府、公文、出版等场景。

     • GBK 扩展到罕见汉字，满足专业和个人需求。

   • UTF-8/UTF-16 旨在支持全球所有语言，编码范围庞大（U+10FFFF），对中文场景显得“过于通用”，早期实现成本高。

3. 生态和市场驱动：

   • GB2312：由中国政府主导，强制实施于信息交换系统（如电信、银行），形成国家标准。

   • GBK：微软的商业推动使 GBK 成为 Windows 中文版的默认编码，迅速普及于个人电脑和软件开发。

   • UTF-8/UTF-16 由国际组织（Unicode 联盟）推动，初期缺乏本地生态支持，推广较慢。

4. Unicode 的早期局限：

   • 1991年的 Unicode 1.0 只收录约 7000 个汉字，远少于 GBK 的 21,000+，无法满足中文需求。

   • UTF-8 的变长编码（需要 3 字节表示汉字）在早期硬件上解析效率低于 GB2312/GBK 的固定 2 字节。

   • UTF-16（UCS-2）虽与 GB2312/GBK 同为 2 字节，但不兼容 ASCII，且代理对机制（1996年）尚未成熟。

4. GB2312、GBK 与 UTF 的对比

• 字符覆盖：

  • GB2312：6763 个汉字 + 682 个符号，覆盖常用中文。

  • GBK：约 21,886 个字符，覆盖常用和部分罕见汉字。

  • UTF-8/UTF-16：支持 U+10FFFF（约 110 万字符），覆盖全球语言。

• 编码方式：

  • GB2312/GBK：固定 2 字节（汉字），单字节（ASCII），简单高效。

  • UTF-8：变长 1-4 字节，ASCII 兼容，汉字用 3 字节。

  • UTF-16：变长 2-4 字节，汉字用 2 字节（BMP），不兼容 ASCII。

• 应用场景：

  • GB2312：1980-1990 年代的中文系统（如 DOS、出版）。

  • GBK：1995-2000 年代的 Windows 软件、早期互联网。

  • UTF-8：2000 年代后主导互联网（网页、JSON）、数据库。

  • UTF-16：Windows API、Java、JavaScript 内部。

• 现状：

  • GB2312 和 GBK 逐渐被 UTF-8 取代，但仍用于遗留系统和部分本地软件。

  • UTF-8 占全球网页编码 95% 以上（2023 数据），是现代标准。