简介GB2312标准字库.json 是一份可直接使用的标准汉字映射数据面向前端、软件开发者以及中文信息处理相关技术人员用于解决汉字编码查询、字符集转换、字体制作等需求。文件内部采用数组结构每条记录由序号和汉字组成完整收录 GB2312 标准中的常用汉字及符号结构规整无多余嵌套方便解析或转存为其他常用数据格式。资源打包为 rar 压缩包内含 1 个 json 文件包体仅 8KB几乎不占用存储空间适合嵌入轻量级项目或作为离线数据源使用。目前已有 123 人学习下载初学者可快速获取标准字库开发者也能直接应用。借助该文件可在汉字查询、乱码修复、文本清洗、样本构建等场景中快速建立索引配合脚本还能实现按编码范围筛选、批量生成字表、标注拼音等二次开发有效减少手动收集字库的繁琐工作。 上次给工业设备的显示面板做离线字库客户需求文档里就一行字“GB2312标准字库.json”。我一开始以为这事儿简单无非是把区位码表转成JSON结果真正动手才发现网上能找到的“GB2312字库JSON”大多有毛病有的只有一级汉字有的把区位码和Unicode混着存有的干脆是从某个客户端里粘出来的残缺数据。折腾一晚上之后我决定把整条链路完整走一遍——从GB2312的编码规则到JSON结构设计再到实际落地场景和踩坑记录一次性整理清楚。这篇文章就是那次整理的成果适合三类人看需要在项目里维护汉字码表JSON的开发者、做离线字库或嵌入式UI的资源工程师以及想弄明白GB2312和JSON怎么配合使用的初学者。如果你只需要一个能直接用的生成脚本可以直接跳到第二章如果你想知道为什么这份JSON要这么设计建议从头读。1. 94×94矩阵里的汉字区位码换算与数据范围1.1 为何整个GB2312能装进94×94的矩阵GB2312不是简单地“给每个汉字发一个编号”它把收录的7445个字符6763个汉字加682个其他符号放进了一个94行乘94列的矩阵。行叫做“区”列叫做“位”所以才有“区位码”这个说法。16区到55区存放一级汉字按拼音排序56区到87区存放二级汉字按部首和笔画排序01区到09区是各种符号、数字和希腊字母。为什么偏偏是94而不是100因为在GB2312设计时需要考虑和ASCII终端的兼容性可打印ASCII字符是0x21到0x7E正好94个区号和位号也都在1到94之间这样当时的终端设备可以按同样的逻辑逐字打印。这个矩阵结构决定了GB2312的边界非常清晰不是所有汉字都在里面甚至不是所有常用汉字都在里面。比如“镕”“喆”这类字就只能在GBK或GB18030里找到。所以在做字库JSON时第一个要确定的事就是你要的是标准GB2312的6763个汉字还是包含了扩展字符的GBK全集。这两者的JSON结构和生成逻辑完全不同后面我会专门讲这个坑。1.2 区位码、国标码、机内码的三级换算理解了矩阵之后接下来就是三个绕不开的概念区位码、国标码、机内码。它们之间的换算关系是固定的往JSON里存哪一层取决于你的消费端需要什么。区位码是人读的视角比如“啊”在16区01位通常写作“1601”。国标码是区位码的十进制数转十六进制后各加0x20得到的。0x10加0x20等于0x300x01加0x20等于0x21所以“啊”的国标码是0x3021。机内码是实际在计算机里存储、传输的两字节值等于国标码再各加0x80也就是区位码各加0xA0。“啊”的机内码就是0xB0A1。下面用一张表把“啊”“中”“国”三个字的换算过程列清楚字符区位码国标码机内码啊16-010x30210xB0A1中54-480x56500xD6D0国25-900x397A0xB9FA看到规律了吗两个字节的高位和低位各自独立参与运算所以区位码、国标码、机内码本质上是同一信息的三套视图。做JSON时没必要三套都塞进去但至少需要保留两套一套给人读区位码一套给程序用机内码或Unicode。Unicode值得单列因为它是跨平台、跨语言的桥梁JSON本身又是Unicode友好的格式这样可以省去使用者自己去换算的麻烦。2. 从空字符串到6763个汉字JSON生成全流程2.1 用Python遍历码位而不是手工整理码表一开始我试图在网上找一个“标准码表”然后导入Excel整理成JSON。事实证明这个路子极其低效因为不同来源的码表格式五花八门有的只给机内码有的给的是区位码文本有的甚至把两个字节写反了。最可靠的生成方式是用编程语言直接计算GB2312的编码规则是公开的那么遍历94×94个码位把每个码位的两字节序列用gb2312解码能解码成功的就加入字库解码不了的说明是空位跳过。下面这个Python脚本是整套流程的核心import json def classify(qu): if 1 qu 9: return symbol if 16 qu 55: return level1 if 56 qu 87: return level2 return reserved def generate_gb2312_json(): entries [] for qu in range(1, 95): for wei in range(1, 95): hi qu 0xA0 lo wei 0xA0 try: ch bytes([hi, lo]).decode(gb2312) except UnicodeDecodeError: continue entries.append({ qu: qu, wei: wei, gb2312_hex: 0x{:02X}{:02X}.format(hi, lo), unicode_hex: 0x{:04X}.format(ord(ch)), char: ch, category: classify(qu) }) return {chars: entries} if __name__ __main__: data generate_gb2312_json() with open(gb2312_standard.json, w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2) print(total:, len(data[chars]))这里的核心逻辑就是拿每个区号和位号分别加上0xA0组成机内码然后交给Python自带的gb2312解码器。解码器本身是经过校验的所以步骤很干净。注意循环范围range(1, 95)意味着区号和位号从1遍历到94一个不多一个不少——这一点看起来微不足道但恰恰是最容易出错的地方我在第四章展开。2.2 JSON字段设计既要好读也要好查字段怎么设计直接决定了这份JSON在项目里好不好用。我见过两种极端做法一种只存一个字符串数组比如[啊,阿,埃...]看着简洁但使用者一旦需要区位码或者Unicode就得再拿一份码表做二次关联另一种是把所有可能的编码元数据全塞进去一条记录二十多个字段文件体积大、可读性也差。我比较推荐的字段是上面脚本里的六个qu、wei、gb2312_hex、unicode_hex、char、category。其中category是对汉字分区的标记它的价值在拼音索引和字体子集裁剪场景里会体现出来。如果项目对大小敏感可以去掉unicode_hex因为JSON本身支持Unicode字符char字段已经把信息带出来了如果想追求最快的查找速度可以在文件里额外生成一个以gb2312_hex为键的对象索引代价是文件体积上涨取舍取决于你的消费端。给一个示例输出片段就是“啊”这条记录{ qu: 16, wei: 1, gb2312_hex: 0xB0A1, unicode_hex: 0x554A, char: 啊, category: level1 }2.3 五条自校验规则跑完才算生成完成生成脚本能跑出结果并不代表结果就是正确的。我建议每次生成后都跑一遍自校验把这五条规则写进同一个脚本汉字总数必须等于6763。level1一级汉字数量必须等于3755level2二级汉字数量必须等于3008。一级汉字所在区必须在16到55之间二级汉字必须在56到87之间。随机抽几个已知字符做双向验证比如“啊”的机内码应该是0xB0A1“中”是0xD6D0“国”是0xB9FA。全表不能出现重复的Unicode码点。第五条看着多余但真的会发生——GB2312的符号区里有不少码位在Unicode中没有独立对应字符解码器可能用替换符或统一字符兜底导致两个不同码位映射到同一个Unicode码点。如果不是刻意查重这种数据错误很难发现。把上面五个校验项写进一个校验函数每次重新生成码表或者调整字段结构以后直接跑一遍能省下大量的下游排查时间。3. 字库JSON在真实项目中的落地方式3.1 拼音分组索引表GB2312的一级汉字是按拼音排序的这个特性让“GB2312拼音索引表”变得非常实用。在只需要全拼首字母索引、不需要导入第三方拼音库的场景下直接按区位码顺序遍历一级汉字就能把字母A到Z的汉字分组切出来。因为同一拼音的汉字在区位码表里通常是连续排列的相邻两个字的拼音发生变化时就是切分点。拿生成好的JSON做分组的逻辑很简单加载chars数组过滤出category等于level1的条目按照qu和wei排序然后设定一个拼音变化的判断。判断拼音变化有几种做法最粗暴的是调用拼音库逐个字标注但那就绕回了“不想引入依赖”的初衷更好用的是查一个精简对照表把3755个一级汉字按拼音分组的边界位置记录下来。这个边界表的每个拼音最后一个字是固定的你只要从GB2312码表里提取一次就能存成一份独立的小JSON以后每次做索引都不用再跑拼音库。3.2 字体子集裁剪时的字符清单前端网页或者嵌入式GUI嵌入中文字体时最头疼的是字体文件太大。一套完整的中文字体动辄几兆到几十兆但实际业务里往往只需要几百个字。这时候GB2312字库JSON就派上了用场把需要的字符从JSON里过滤出来写入一个纯文本chars.txt再交给字体裁剪工具处理。以Python生态里的pyftsubset为例命令长这样pyftsubset NotoSansSC-Regular.otf --text-filechars.txt --output-fileNotoSansSC-subset.woff2在JSON里一行代码就能拼出chars.txtwith open(chars.txt, w, encodingutf-8) as f: for item in data[chars]: f.write(item[char])实际项目中我会在过滤时加上category判断。比如一个数据展示大屏只显示一级汉字和数字那就在循环里把category为symbol和level1的字符挑出来再额外加上业务方提供的生僻字列表。这样生成的subset字体体积能减少70%以上页面加载速度提升非常明显。3.3 嵌入式离线查表的数据源嵌入式设备上没有操作系统的字符集表处理中文显示时通常要自己做查表。把GB2312字库JSON转成C语言可用的查表数组是这类项目里最常见的诉求。思路是把JSON里的gb2312_hex作为索引把字符对应的点阵数据或渲染索引作为值生成一个静态const数组。在转C数组时有一个常见选择是按区位码顺序排一维数组还是做二维数组。我推荐后者原因很朴素——GB2312本身就是94×94的矩阵按区做外层、位做内层的二维数组代码可读性最高也方便做区间判断。伪代码示意typedef struct { uint16_t gb2312_code; uint16_t unicode; const uint8_t* bitmap; } gb_char_t; gb_char_t gb2312_table[94][94] { ... };结构体数组的好处是即使某个位置是空位也能通过gb2312_code是否为0来判断。而且由于JSON生成过程已经帮我们确认了码位合法性C端不用再做多余校验直接按索引访问就行。注意如果目标芯片Flash极小建议只保留你实际用到的连续区段不要一次性把94×94全量塞进去。4. 生成与使用中的三个高频坑4.1 自称GB2312的文件实际可能是GBK这个坑我踩得最实。第一次拿到客户给的参考JSON时我数了一遍汉字数量远超6763心里就有数了——这份表是GBK或者GB18030的子集只是文件名写着“GB2312”。GBK是GB2312的扩展汉字的编码范围更大凡是GB2312能编的GBK都能编反过来就不行。如果你拿着GBK的码表去做严格GB2312的校验数量对不上查表也必然错位。判断一份JSON到底是GB2312还是GBK方法很简单看它里面的gb2312_hex字段如果字节值大量出现在0x8140到0xA0FE以及0xAA40到0xFEFE这些扩展区段那基本就是GBK。如果你需要的是严格标准GB2312就直接用第二章的脚本重新生成别在来源不明的码表上浪费时间。日常办公软件里那些“声称支持GB2312但实际只支持GBK”的乱码问题根源也大多在这里。4.2 区号从1开始还是从0开始写遍历循环的时候如果你习惯性写了range(0, 94)生成出来的第一行会是“0区0位”这种不存在的码位后续所有码位整体偏移一个区。这种错误最阴险的地方在于字库依然能解码出汉字只是每个字的区位码全都错位而且因为GB2312每个区的字符分布并不均匀有些位置的错位不会立刻暴露直到下游做拼音分组时才发现字母索引全乱了。所以我会在生成脚本里加一个强制断言first data[chars][0] assert first[qu] 1 and first[wei] 1, 区位码起点错误另外一个非常容易忽略的细节是即使循环起点对了也要检查第一个汉字是不是“啊”。因为16区01位是“啊”如果你的生成结果第一条是其他字要么是区号范围写错要么是解码顺序被排序函数打乱了。4.3 编码成功不等于属于GB2312最后一个坑与编程语言的行为有关。在Python里对一个字符串调用encode(gb2312)如果编码器发现某个字符不在GB2312范围会因为strict模式抛异常但如果你用的是gb2312别名或者个别环境配置了errorsreplace它可能会悄悄用GBK甚至GB18030的方式处理导致你产出的“GB2312 JSON”里混入了不该存在的字符。更隐蔽的是有些解码器在解码符号区时会把多个不同码位映射到同一个Unicode字符。我的建议是不要只看encode能不能成功要回到区位码矩阵本身判断。严格的做法就是前面脚本里那样直接构造机内码字节流让解码器去按GB2312解开这样能成功解码的码位才是真正意义上的GB2312字库成员。在项目里我最后保留了一条兜底规则凡是category等于level1或level2的汉字记录unicode_hex必须落在0x4E00到0x9FA5这个CJK统一表意文字基本区范围内。这个范围覆盖了GB2312的全部6763个汉字只要出现范围外的记录不用看内容就能判断数据混入了符号或GBK扩展字符。做完这套流程我现在生成字库JSON的习惯已经完全固定下来脚本、码表版本、校验日志一起放进仓库每次重新生成都先跑assert。后面如果你也要做同样的字库我的建议是——先确认消费端要的是“严格GB2312”还是“GBK之上的兼容子集”然后再跑生成脚本数据只要过一遍那五条校验规则基本就稳了。这个流程我后来又用于生成GBK、GB18030的码表JSON思路完全一样只是解码器和预期数量改一改而已。本文还有配套的精品资源点击获取 GB2312字库JSON生成全攻略：编码规则、脚本实现与踩坑记录
简介GB2312标准字库.json 是一份可直接使用的标准汉字映射数据面向前端、软件开发者以及中文信息处理相关技术人员用于解决汉字编码查询、字符集转换、字体制作等需求。文件内部采用数组结构每条记录由序号和汉字组成完整收录 GB2312 标准中的常用汉字及符号结构规整无多余嵌套方便解析或转存为其他常用数据格式。资源打包为 rar 压缩包内含 1 个 json 文件包体仅 8KB几乎不占用存储空间适合嵌入轻量级项目或作为离线数据源使用。目前已有 123 人学习下载初学者可快速获取标准字库开发者也能直接应用。借助该文件可在汉字查询、乱码修复、文本清洗、样本构建等场景中快速建立索引配合脚本还能实现按编码范围筛选、批量生成字表、标注拼音等二次开发有效减少手动收集字库的繁琐工作。 上次给工业设备的显示面板做离线字库客户需求文档里就一行字“GB2312标准字库.json”。我一开始以为这事儿简单无非是把区位码表转成JSON结果真正动手才发现网上能找到的“GB2312字库JSON”大多有毛病有的只有一级汉字有的把区位码和Unicode混着存有的干脆是从某个客户端里粘出来的残缺数据。折腾一晚上之后我决定把整条链路完整走一遍——从GB2312的编码规则到JSON结构设计再到实际落地场景和踩坑记录一次性整理清楚。这篇文章就是那次整理的成果适合三类人看需要在项目里维护汉字码表JSON的开发者、做离线字库或嵌入式UI的资源工程师以及想弄明白GB2312和JSON怎么配合使用的初学者。如果你只需要一个能直接用的生成脚本可以直接跳到第二章如果你想知道为什么这份JSON要这么设计建议从头读。1. 94×94矩阵里的汉字区位码换算与数据范围1.1 为何整个GB2312能装进94×94的矩阵GB2312不是简单地“给每个汉字发一个编号”它把收录的7445个字符6763个汉字加682个其他符号放进了一个94行乘94列的矩阵。行叫做“区”列叫做“位”所以才有“区位码”这个说法。16区到55区存放一级汉字按拼音排序56区到87区存放二级汉字按部首和笔画排序01区到09区是各种符号、数字和希腊字母。为什么偏偏是94而不是100因为在GB2312设计时需要考虑和ASCII终端的兼容性可打印ASCII字符是0x21到0x7E正好94个区号和位号也都在1到94之间这样当时的终端设备可以按同样的逻辑逐字打印。这个矩阵结构决定了GB2312的边界非常清晰不是所有汉字都在里面甚至不是所有常用汉字都在里面。比如“镕”“喆”这类字就只能在GBK或GB18030里找到。所以在做字库JSON时第一个要确定的事就是你要的是标准GB2312的6763个汉字还是包含了扩展字符的GBK全集。这两者的JSON结构和生成逻辑完全不同后面我会专门讲这个坑。1.2 区位码、国标码、机内码的三级换算理解了矩阵之后接下来就是三个绕不开的概念区位码、国标码、机内码。它们之间的换算关系是固定的往JSON里存哪一层取决于你的消费端需要什么。区位码是人读的视角比如“啊”在16区01位通常写作“1601”。国标码是区位码的十进制数转十六进制后各加0x20得到的。0x10加0x20等于0x300x01加0x20等于0x21所以“啊”的国标码是0x3021。机内码是实际在计算机里存储、传输的两字节值等于国标码再各加0x80也就是区位码各加0xA0。“啊”的机内码就是0xB0A1。下面用一张表把“啊”“中”“国”三个字的换算过程列清楚字符区位码国标码机内码啊16-010x30210xB0A1中54-480x56500xD6D0国25-900x397A0xB9FA看到规律了吗两个字节的高位和低位各自独立参与运算所以区位码、国标码、机内码本质上是同一信息的三套视图。做JSON时没必要三套都塞进去但至少需要保留两套一套给人读区位码一套给程序用机内码或Unicode。Unicode值得单列因为它是跨平台、跨语言的桥梁JSON本身又是Unicode友好的格式这样可以省去使用者自己去换算的麻烦。2. 从空字符串到6763个汉字JSON生成全流程2.1 用Python遍历码位而不是手工整理码表一开始我试图在网上找一个“标准码表”然后导入Excel整理成JSON。事实证明这个路子极其低效因为不同来源的码表格式五花八门有的只给机内码有的给的是区位码文本有的甚至把两个字节写反了。最可靠的生成方式是用编程语言直接计算GB2312的编码规则是公开的那么遍历94×94个码位把每个码位的两字节序列用gb2312解码能解码成功的就加入字库解码不了的说明是空位跳过。下面这个Python脚本是整套流程的核心import json def classify(qu): if 1 qu 9: return symbol if 16 qu 55: return level1 if 56 qu 87: return level2 return reserved def generate_gb2312_json(): entries [] for qu in range(1, 95): for wei in range(1, 95): hi qu 0xA0 lo wei 0xA0 try: ch bytes([hi, lo]).decode(gb2312) except UnicodeDecodeError: continue entries.append({ qu: qu, wei: wei, gb2312_hex: 0x{:02X}{:02X}.format(hi, lo), unicode_hex: 0x{:04X}.format(ord(ch)), char: ch, category: classify(qu) }) return {chars: entries} if __name__ __main__: data generate_gb2312_json() with open(gb2312_standard.json, w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2) print(total:, len(data[chars]))这里的核心逻辑就是拿每个区号和位号分别加上0xA0组成机内码然后交给Python自带的gb2312解码器。解码器本身是经过校验的所以步骤很干净。注意循环范围range(1, 95)意味着区号和位号从1遍历到94一个不多一个不少——这一点看起来微不足道但恰恰是最容易出错的地方我在第四章展开。2.2 JSON字段设计既要好读也要好查字段怎么设计直接决定了这份JSON在项目里好不好用。我见过两种极端做法一种只存一个字符串数组比如[啊,阿,埃...]看着简洁但使用者一旦需要区位码或者Unicode就得再拿一份码表做二次关联另一种是把所有可能的编码元数据全塞进去一条记录二十多个字段文件体积大、可读性也差。我比较推荐的字段是上面脚本里的六个qu、wei、gb2312_hex、unicode_hex、char、category。其中category是对汉字分区的标记它的价值在拼音索引和字体子集裁剪场景里会体现出来。如果项目对大小敏感可以去掉unicode_hex因为JSON本身支持Unicode字符char字段已经把信息带出来了如果想追求最快的查找速度可以在文件里额外生成一个以gb2312_hex为键的对象索引代价是文件体积上涨取舍取决于你的消费端。给一个示例输出片段就是“啊”这条记录{ qu: 16, wei: 1, gb2312_hex: 0xB0A1, unicode_hex: 0x554A, char: 啊, category: level1 }2.3 五条自校验规则跑完才算生成完成生成脚本能跑出结果并不代表结果就是正确的。我建议每次生成后都跑一遍自校验把这五条规则写进同一个脚本汉字总数必须等于6763。level1一级汉字数量必须等于3755level2二级汉字数量必须等于3008。一级汉字所在区必须在16到55之间二级汉字必须在56到87之间。随机抽几个已知字符做双向验证比如“啊”的机内码应该是0xB0A1“中”是0xD6D0“国”是0xB9FA。全表不能出现重复的Unicode码点。第五条看着多余但真的会发生——GB2312的符号区里有不少码位在Unicode中没有独立对应字符解码器可能用替换符或统一字符兜底导致两个不同码位映射到同一个Unicode码点。如果不是刻意查重这种数据错误很难发现。把上面五个校验项写进一个校验函数每次重新生成码表或者调整字段结构以后直接跑一遍能省下大量的下游排查时间。3. 字库JSON在真实项目中的落地方式3.1 拼音分组索引表GB2312的一级汉字是按拼音排序的这个特性让“GB2312拼音索引表”变得非常实用。在只需要全拼首字母索引、不需要导入第三方拼音库的场景下直接按区位码顺序遍历一级汉字就能把字母A到Z的汉字分组切出来。因为同一拼音的汉字在区位码表里通常是连续排列的相邻两个字的拼音发生变化时就是切分点。拿生成好的JSON做分组的逻辑很简单加载chars数组过滤出category等于level1的条目按照qu和wei排序然后设定一个拼音变化的判断。判断拼音变化有几种做法最粗暴的是调用拼音库逐个字标注但那就绕回了“不想引入依赖”的初衷更好用的是查一个精简对照表把3755个一级汉字按拼音分组的边界位置记录下来。这个边界表的每个拼音最后一个字是固定的你只要从GB2312码表里提取一次就能存成一份独立的小JSON以后每次做索引都不用再跑拼音库。3.2 字体子集裁剪时的字符清单前端网页或者嵌入式GUI嵌入中文字体时最头疼的是字体文件太大。一套完整的中文字体动辄几兆到几十兆但实际业务里往往只需要几百个字。这时候GB2312字库JSON就派上了用场把需要的字符从JSON里过滤出来写入一个纯文本chars.txt再交给字体裁剪工具处理。以Python生态里的pyftsubset为例命令长这样pyftsubset NotoSansSC-Regular.otf --text-filechars.txt --output-fileNotoSansSC-subset.woff2在JSON里一行代码就能拼出chars.txtwith open(chars.txt, w, encodingutf-8) as f: for item in data[chars]: f.write(item[char])实际项目中我会在过滤时加上category判断。比如一个数据展示大屏只显示一级汉字和数字那就在循环里把category为symbol和level1的字符挑出来再额外加上业务方提供的生僻字列表。这样生成的subset字体体积能减少70%以上页面加载速度提升非常明显。3.3 嵌入式离线查表的数据源嵌入式设备上没有操作系统的字符集表处理中文显示时通常要自己做查表。把GB2312字库JSON转成C语言可用的查表数组是这类项目里最常见的诉求。思路是把JSON里的gb2312_hex作为索引把字符对应的点阵数据或渲染索引作为值生成一个静态const数组。在转C数组时有一个常见选择是按区位码顺序排一维数组还是做二维数组。我推荐后者原因很朴素——GB2312本身就是94×94的矩阵按区做外层、位做内层的二维数组代码可读性最高也方便做区间判断。伪代码示意typedef struct { uint16_t gb2312_code; uint16_t unicode; const uint8_t* bitmap; } gb_char_t; gb_char_t gb2312_table[94][94] { ... };结构体数组的好处是即使某个位置是空位也能通过gb2312_code是否为0来判断。而且由于JSON生成过程已经帮我们确认了码位合法性C端不用再做多余校验直接按索引访问就行。注意如果目标芯片Flash极小建议只保留你实际用到的连续区段不要一次性把94×94全量塞进去。4. 生成与使用中的三个高频坑4.1 自称GB2312的文件实际可能是GBK这个坑我踩得最实。第一次拿到客户给的参考JSON时我数了一遍汉字数量远超6763心里就有数了——这份表是GBK或者GB18030的子集只是文件名写着“GB2312”。GBK是GB2312的扩展汉字的编码范围更大凡是GB2312能编的GBK都能编反过来就不行。如果你拿着GBK的码表去做严格GB2312的校验数量对不上查表也必然错位。判断一份JSON到底是GB2312还是GBK方法很简单看它里面的gb2312_hex字段如果字节值大量出现在0x8140到0xA0FE以及0xAA40到0xFEFE这些扩展区段那基本就是GBK。如果你需要的是严格标准GB2312就直接用第二章的脚本重新生成别在来源不明的码表上浪费时间。日常办公软件里那些“声称支持GB2312但实际只支持GBK”的乱码问题根源也大多在这里。4.2 区号从1开始还是从0开始写遍历循环的时候如果你习惯性写了range(0, 94)生成出来的第一行会是“0区0位”这种不存在的码位后续所有码位整体偏移一个区。这种错误最阴险的地方在于字库依然能解码出汉字只是每个字的区位码全都错位而且因为GB2312每个区的字符分布并不均匀有些位置的错位不会立刻暴露直到下游做拼音分组时才发现字母索引全乱了。所以我会在生成脚本里加一个强制断言first data[chars][0] assert first[qu] 1 and first[wei] 1, 区位码起点错误另外一个非常容易忽略的细节是即使循环起点对了也要检查第一个汉字是不是“啊”。因为16区01位是“啊”如果你的生成结果第一条是其他字要么是区号范围写错要么是解码顺序被排序函数打乱了。4.3 编码成功不等于属于GB2312最后一个坑与编程语言的行为有关。在Python里对一个字符串调用encode(gb2312)如果编码器发现某个字符不在GB2312范围会因为strict模式抛异常但如果你用的是gb2312别名或者个别环境配置了errorsreplace它可能会悄悄用GBK甚至GB18030的方式处理导致你产出的“GB2312 JSON”里混入了不该存在的字符。更隐蔽的是有些解码器在解码符号区时会把多个不同码位映射到同一个Unicode字符。我的建议是不要只看encode能不能成功要回到区位码矩阵本身判断。严格的做法就是前面脚本里那样直接构造机内码字节流让解码器去按GB2312解开这样能成功解码的码位才是真正意义上的GB2312字库成员。在项目里我最后保留了一条兜底规则凡是category等于level1或level2的汉字记录unicode_hex必须落在0x4E00到0x9FA5这个CJK统一表意文字基本区范围内。这个范围覆盖了GB2312的全部6763个汉字只要出现范围外的记录不用看内容就能判断数据混入了符号或GBK扩展字符。做完这套流程我现在生成字库JSON的习惯已经完全固定下来脚本、码表版本、校验日志一起放进仓库每次重新生成都先跑assert。后面如果你也要做同样的字库我的建议是——先确认消费端要的是“严格GB2312”还是“GBK之上的兼容子集”然后再跑生成脚本数据只要过一遍那五条校验规则基本就稳了。这个流程我后来又用于生成GBK、GB18030的码表JSON思路完全一样只是解码器和预期数量改一改而已。本文还有配套的精品资源点击获取