简介：GB2312标准字库.json 是一份面向中文信息处理、字体开发与字符编码学习者的结构化字库数据文件，适合需要按序号检索汉字、验证编码映射或搭建字符集演示程序的开发者与研究者使用。压缩包内共1个文件，为json格式，整体约8KB，采用「序号—汉字」的键值对结构组织，便于程序直接解析与遍历，无需额外转换即可接入前端或脚本项目。内容覆盖常用汉字及部分生僻字，如灞、爨、夔、肇、羹、盥、龆、曦、寰、囡、氚、圜等，可满足字符集抽样、字库索引与编码测试等场景。目前已有123人学习下载，说明其在中文编码与字库相关实践中具备一定参考价值。读者可借此快速获取一份轻量的GB2312字库样本，用于字符匹配、排序验证、字库展示或教学演示，减少自行整理字符数据的时间成本。
1. 从一份 GB2312标准字库.json 说起：点阵字模怎么变成前端能用的数据
做嵌入式 UI、点阵屏驱动或者复古风格网页的人，迟早会撞上同一个问题：手里有一堆字模数据，但不知道怎么把它变成程序里能直接查、直接画的东西。GB2312标准字库.json 这个标题，说的就是把国标一级、二级汉字区的点阵字模，从二进制或十六进制文本，整理成一份结构化 JSON 字库，让前端、Node 脚本或者单片机端都能按码位直接取到每个字的点阵数组。它解决的不是"汉字怎么显示"这种大问题，而是"我拿到一份字模表，怎么在半小时内跑通取字、渲染、校验"这种具体活。适合做小屏 UI、电子价签、工控面板、像素风游戏字体的人，也适合想理解汉字编码与点阵关系的前端。下面按我实际做过的路径拆开讲。
2. 先搞清楚 GB2312 区位码和点阵字模的对应关系
2.1 区位码、机内码、Unicode 三套坐标别混用
GB2312 把汉字分成 94 个区，每区 94 个位。一级汉字在 16 到 55 区，二级汉字在 56 到 87 区，1 到 9 区是符号。区位码写成两个字节，区号加 0xA0 就是机内码高字节，位号加 0xA0 就是低字节。比如"啊"在 16 区 01 位，机内码是 0xB0A1。而 Unicode 里"啊"是 U+554A，两者没有简单线性关系，必须查表或走编码转换。
很多人第一次做字库会翻车在这里：拿 Unicode 码点直接去减 0x4E00 当索引，结果一级汉字区对不上。正确做法是先把 Unicode 转成 GB2312 双字节，再拆区号和位号，算出在字库文件里的偏移。常见做法是用 Python 的codecs做转换，或者用一张映射表。
# 把 Unicode 汉字转成 GB2312 机内码，再算区位 def unicode_to_gb2312_offset(ch): b = ch.encode('gb2312') # 得到双字节机内码 area = b[0] - 0xA0 # 区号，1~94 pos = b[1] - 0xA0 # 位号，1~94 # 字库通常按区、位顺序排列，每字 32 字节（16x16 点阵） index = (area - 1) * 94 + (pos - 1) return area, pos, index * 32这段代码的关键参数是0xA0这个偏移基址，以及每字 32 字节的假设。16x16 点阵每行 2 字节，16 行就是 32 字节。如果你用的是 12x12 点阵，每行 2 字节但只用 12 位，仍然是 24 字节，索引公式里的乘数要改。encode('gb2312')遇到生僻字会抛异常，所以实际脚本里要 try 包一层，把不支持的字符跳过或标记。
2.2 点阵字节怎么变成 JSON 里的可读数组
原始字模文件一般是二进制，每个字 32 字节，按行从上到下、每行高字节在前。直接塞进 JSON 会变成一长串数字，可读性差，也不方便前端调试。我一般会转成每行一个整数的数组，或者转成 0/1 字符串数组，前者省空间，后者肉眼能看出字形。
def bytes_to_rows(raw): rows = [] for i in range(0, 32, 2): # 高字节在前，拼成 16 位整数 val = (raw[i] << 8) | raw[i + 1] rows.append(val) return rows def rows_to_binary_string(rows): out = [] for val in rows: # 每行 16 位，转成 16 个 0/1 字符 out.append(format(val, '016b')) return outformat(val, '016b')里的 16 是位宽，必须和点阵宽度一致。如果点阵是 12 宽，就要改成'012b'，否则高位会多出 0，渲染时字会偏移。JSON 结构我通常长这样：顶层是对象，键是 GB2312 机内码的十六进制字符串，值是行数组。这样前端拿到一个码位就能直接dict[code]取到，不用再算偏移。
注意：JSON 的键如果用数字会丢前导零，所以机内码一定要用字符串，比如
"b0a1"而不是0xb0a1。
3. 把二进制字模转成 GB2312标准字库.json 的完整脚本
3.1 读取原始字模并建立码位索引
假设你手里有一份标准的 16x16 点阵字库二进制文件，从 0 区开始按区位顺序排列。第一步是确定文件里到底包含哪些区。有些字库只含一级汉字，从 16 区开始；有些含全部符号和汉字。我一般先读文件大小，除以 32 得到总字数，再反推覆盖范围。
import json, os FONT_PATH = 'hzk16.bin' # 原始点阵字库 OUT_PATH = 'gb2312_font.json' BYTES_PER_CHAR = 32 # 16x16 点阵 size = os.path.getsize(FONT_PATH) total = size // BYTES_PER_CHAR print(f'总字数: {total}') # 常见 6763 或 81786763 是一级加二级汉字的总数，8178 则包含符号区。这个数字决定了后面循环的范围。如果 total 不是 6763 或 8178，说明字库被裁剪过，或者点阵尺寸不是 16x16，需要先确认再往下走。
3.2 生成 JSON 并处理生僻字与缺字
生成时不能简单按索引循环，因为 GB2312 的区号不是连续的，9 区到 16 区之间有空档。稳妥做法是遍历所有合法区位，用bytes([area+0xA0, pos+0xA0]).decode('gb2312')反查字符，成功才写入。
font = {} with open(FONT_PATH, 'rb') as f: data = f.read() for area in range(1, 95): for pos in range(1, 95): try: ch = bytes([area + 0xA0, pos + 0xA0]).decode('gb2312') except UnicodeDecodeError: continue # 跳过无效码位 idx = (area - 1) * 94 + (pos - 1) raw = data[idx * BYTES_PER_CHAR:(idx + 1) * BYTES_PER_CHAR] if len(raw) < BYTES_PER_CHAR: continue # 文件末尾不完整 rows = [(raw[i] << 8) | raw[i+1] for i in range(0, 32, 2)] code = f'{area+0xA0:02x}{pos+0xA0:02x}' font[code] = rows with open(OUT_PATH, 'w', encoding='utf-8') as f: json.dump(font, f, ensure_ascii=False, separators=(',', ':'))separators=(',', ':')去掉 JSON 里的空格，能把文件压掉将近三成。ensure_ascii=False让键保持原样，不过这里键本来就是十六进制字符串，影响不大。生成完先看文件大小，6763 个字、每字 16 个整数，大概在 1.5MB 到 2MB 之间。如果只有几百 KB，多半是循环范围写错了。
3.3 用 Node 或浏览器验证取字和渲染
JSON 生成后，最直接的验证是拿几个已知字，把点阵画出来看形状。下面这段在浏览器控制台就能跑，把"中"字打印成星号。
// 假设 font 是已经加载的 JSON 对象 const code = 'd6d0'; // "中"的 GB2312 机内码 const rows = font[code]; if (!rows) { console.error('缺字'); } else { rows.forEach(v => { // 每行取高 16 位，1 画星号，0 画点 const line = v.toString(2).padStart(16, '0') .replace(/1/g, '*').replace(/0/g, '.'); console.log(line); }); }padStart(16, '0')保证每行都是 16 字符，否则高位 0 会被toString(2)吃掉，字形左边会缺一块。如果打印出来是乱码或者全空，先检查code是不是小写十六进制，再检查 JSON 里的键有没有前导零丢失。这一步跑通，说明字库数据本身没问题，可以往渲染层走。
4. 避坑：字库转换里最容易翻车的五个地方
4.1 现象：渲染出来汉字左右镜像或上下颠倒
原因通常是字节序或行序搞反了。有些字库低字节在前，有些从下往上存。解决方法是拿一个对称性差的字，比如"上"，分别按两种顺序打印，看哪个能读出正确形状。确认后在bytes_to_rows里调整拼接顺序，或者把行数组反转。
4.2 现象：JSON 文件比预期大很多，加载卡顿
原因是把每个 0/1 都存成了独立字符串，或者用了缩进格式。解决方法是存整数行数组，并且用separators去掉空白。如果前端只需要部分字，可以按区拆成多个 JSON，按需加载，而不是一次拉全量。
4.3 现象：某些常用字取不到，返回 undefined
原因是这些字在 GB2312 里属于二级汉字区，而你的字库文件只包含一级汉字。解决方法是先确认字库覆盖范围，或者改用 GBK 编码扩展。如果必须用 GB2312，就要在业务层做缺字兜底，比如显示占位符。
4.4 现象：Node 里读 JSON 报编码错误
原因是生成时用了ensure_ascii=True，键变成了\uXXXX转义，而读取端按原样匹配。解决方法是生成时统一用ensure_ascii=False，并且读写都指定utf-8。如果跨系统传输，注意 BOM 头，Node 的JSON.parse遇到 BOM 会直接抛异常。
4.5 现象：点阵渲染出来笔画粗细不均
原因是原始字库本身是 16x16 点阵，放大到 32x32 时用了最近邻插值，导致某些笔画看起来断线。这不是数据问题，是渲染问题。解决方法是渲染时用整数倍缩放，或者换用 24x24、32x32 的点阵源。如果只能用小点阵，就在 CSS 里关掉平滑，保持像素风。
5. 进阶：按需裁剪字库和前端取字缓存
5.1 只保留项目用到的字，把 2MB 压到 50KB
实际项目里往往只用几百个汉字，没必要加载全量。做法是先扫描代码或文案，收集所有用到的字符，转成 GB2312 机内码集合，再过滤 JSON。
used = set() for ch in open('text.txt', encoding='utf-8').read(): try: b = ch.encode('gb2312') used.add(f'{b[0]:02x}{b[1]:02x}') except UnicodeEncodeError: pass with open('gb2312_font.json', encoding='utf-8') as f: full = json.load(f) small = {k: v for k, v in full.items() if k in used} with open('font_small.json', 'w', encoding='utf-8') as f: json.dump(small, f, separators=(',', ':'), ensure_ascii=False)used集合里存的是十六进制字符串，和 JSON 键格式一致才能匹配。如果文案是动态的，就在构建时跑一次，把结果打包进产物。这样前端加载的 JSON 通常只有几十 KB，首屏取字几乎无延迟。
5.2 前端取字缓存与 Canvas 渲染的配合
如果同一个字要反复画，每次都遍历 16 行去画点会很浪费。我一般会在首次取字时把点阵转成ImageData或离屏 Canvas，缓存起来，后续直接drawImage。
const cache = new Map(); function getGlyphCanvas(code, font) { if (cache.has(code)) return cache.get(code); const rows = font[code]; if (!rows) return null; const c = document.createElement('canvas'); c.width = 16; c.height = 16; const ctx = c.getContext('2d'); const img = ctx.createImageData(16, 16); rows.forEach((val, y) => { for (let x = 0; x < 16; x++) { // 判断第 x 位是否为 1，注意位序 const bit = (val >> (15 - x)) & 1; const i = (y * 16 + x) * 4; img.data[i] = img.data[i+1] = img.data[i+2] = bit ? 0 : 255; img.data[i+3] = 255; } }); ctx.putImageData(img, 0, 0); cache.set(code, c); return c; }(val >> (15 - x)) & 1里的 15 是位宽减一，如果点阵宽度变了，这个数也要跟着变。缓存用Map而不是普通对象，避免键名冲突。实际用的时候，把返回的 Canvas 按整数倍放大画到主画布上，就能得到清晰的像素字。
5.3 校验：用覆盖率检查有没有漏字
上线前我习惯跑一次覆盖率检查，把项目里所有字符过一遍，看有多少在字库里找不到。
missing = [] for ch in all_text: try: b = ch.encode('gb2312') code = f'{b[0]:02x}{b[1]:02x}' if code not in small: missing.append(ch) except UnicodeEncodeError: missing.append(ch) print(f'缺字 {len(missing)} 个: {"".join(missing[:20])}')这个脚本能提前暴露问题，比等到用户看到空白方块再回头查要省事得多。缺字多的话，要么补字库，要么在 UI 上做降级处理。
这套流程我前后在几个小屏项目里用过，最深的教训是：别一上来就写渲染，先把码位和偏移算对，拿三五个字打印出来看形状，确认数据层没问题再往上搭。字库这东西，数据错一位，后面全白干。希望帮到你。
本文还有配套的精品资源，点击获取
