GBK、GB2312、GB18030区别

🛠工具与编程 💻编程
, , ,
1

前言

最近用户使用rimetool时报错

2025-10-15 11:09:09,607 - ERROR - [new_app.py:273] - 调用 rimetool_main 失败: 'gb2312' codec can't decode byte 0x90 in position 698: illegal multibyte sequence

很奇怪，我们已经用chardet做了编码识别，如果识别是gbk，就用gbk打开，如果是utf8，就用utf8打开

但是为什么识别成gb2312却打不开呢？

和ai交流一下才知道，自动检测经常把 GBK/GB18030 误报为 GB2312，这时候用GB2312打开，自然会报错了。

解决方案

GBK、GB2312、GB18030都用GB18030打开

GBK、GB2312、GB18030区别

简要回答：

  • 标准与年代
    • GB2312：1980 年发布，收录约 6763 个简体汉字 + 682 个符号。
    • GBK：1995 年发布，在 GB2312 基础上大幅扩展，收录约 21003 个汉字（含大量繁体与生僻字），完全向下兼容 GB2312。Windows 中文代码页 CP936 实际上就是 GBK。
  • 字符覆盖范围
    • GB2312 覆盖面小，很多 GBK/GB18030 中常见的字符（如部分繁体、日常生僻字、部首等）不在其内。
    • GBK 覆盖更广，能编码更多汉字与符号；GB18030 则在 GBK 之上进一步扩展，几乎完整覆盖 Unicode。
  • 字节取值与有效性
    • GB2312 的双字节范围较窄：前导字节 A1–F7，后续字节 A1–FE。
    • GBK 的取值范围更广：前导字节 81–FE，后续字节 40–FE（不含 7F）。
    • 因此，像 0x90 这类字节在 GB2312 中非法，但在 GBK/GB18030 中可能是合法组合。这正是“gb2312 解码报错”的常见根因。
  • 与 Unicode 的关系
    • GBK 基本对应 Unicode 1.1 的中文子集。
    • GB18030（2000/2005/2022 版）通过 1/2/4 字节序列映射，几乎完整覆盖 Unicode，现代场景更推荐。
  • 实战建议
    • 自动检测经常把 GBK/GB18030 误报为 GB2312。为避免解码错误，统一用 gb18030 去打开“简体中文”编码文件最稳妥（gb18030 向下兼容 GBK/GB2312）。
    • 带 BOM 的 UTF-8 用 utf-8-sig 打开更省心。

一句话总结：GB2312 是较早且较小的子集；GBK 在 GB2312 基础上大幅扩展并向下兼容；现代场景建议优先用 gb18030 解码中文文本以避免“GB2312 解不动”的问题。

拓展

之前遇到的类似问题