三代标准的关系
三者的关系是一条包含链：GB2312 ⊂ GBK ⊂ GB18030。GB2312 是 1980 年的第一个中文信息交换标准，只收 6763 个常用汉字；GBK 在其基础上扩充到两万余字并把首字节范围放宽；GB18030 则改为单双四字节混合结构，做到与 Unicode 码位一一对应，能表示生僻字、少数民族文字与增补平面字符。工程上的判断很简单：只在简体常用字场景可以用 GBK，任何需要「不丢字」的场合都应上 GB18030 或 UTF-8。
基本信息
| GB2312 | 1980 年发布，6763 个汉字，双字节，区码 0xA1-0xF7 |
|---|---|
| GBK | 1995 年，CJK 汉字 20902 个，双字节，首字节 0x81-0xFE |
| GB18030 | 2000 年发布、后续有修订版本，单/双/四字节，覆盖 Unicode 码位 |
| 兼容方向 | GB18030 兼容 GBK，GBK 兼容 GB2312，反向不成立 |
| Windows 实现 | 代码页 936 对应 GBK 系，界面显示为 ANSI |
| 浏览器行为 | HTML 中标注 gb2312 时按 GBK 解码，属标准规定的标签映射 |
典型使用场景
- 选型决策：面向老设备或极小存储场景用 GBK，面向政务、金融强制合规场景用 GB18030
- 兼容性评估：迁移前统计现有数据里是否存在 GBK 无法表示的字符
- 对日、对欧业务：这些场景直接用 UTF-8，避免多套中文标准叠加带来的转码环节
- 交付验收：政府项目文档常要求「支持 GB18030」，需确认读写链路每一环都用了该编码
- 故障定位：乱码时先分清是哪一代标准，再决定按 GBK 还是 GB18030 解码重试
覆盖范围实测
覆盖范围实测
# 用 Python 快速验证某个字符在三种标准下能否表示
python -c "c='镕'; print(c.encode('gb2312'))" 2>&1 # 生僻字在 GB2312 下可能直接失败
python -c "c='镕'; print(c.encode('gbk'))" # GBK 通常可编码
python -c "c='\U00020000'; print(len(c.encode('gb18030')))" # 增补平面字符编码为 4 字节
python -c "c='\U00020000'; c.encode('gbk')" 2>&1 # GBK 无法表示，抛编码异常
iconv -f GB18030 -t UTF-8 -o out.txt in.txt && echo ok # 转换成功与否即覆盖验证三标准对比
| 维度 | GB2312 | GBK / GB18030 |
|---|---|---|
| 汉字规模 | 6763 个常用汉字 | GBK 约 2 万；GB18030 覆盖 Unicode 码位 |
| 字节长度 | 固定双字节 | GBK 一至二字节；GB18030 一至四字节 |
| 生僻字支持 | 不支持 | GBK 部分支持；GB18030 完整支持 |
| emoji 与增补平面 | 不支持 | GBK 不支持；GB18030 支持 |
| 典型载体 | 早期 DOS 与老系统 | Windows 中文环境、国标合规项目 |
名称混用是排查乱码时的常见误判：Java 里声明为 GB2312 的字符集在多数实现上实际按 GBK 处理；HTML 里的 gb2312 标签按标准映射到 GBK 解码。遇到「声明与实际不符」时，以实际能正确解码的方案为准，并把声明改成与之一致的编码名。
GB18030 有发布过多个版本（2000、2005、2022 等），较新版本对部分映射做了调整并成为强制实施的标准，具体条款与实施日期以国家标准公告为准。仅依赖某一份旧映射表的实现，可能在跨版本交互时出现个别字符不一致。
选择建议：新系统一律 UTF-8；必须用国标时选 GB18030 而非 GBK；只有在对接明确只吃 GBK/CP936 的老系统时，才在边界处临时转码，并保持内部存储统一。