简介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 里啊是 U554A两者没有简单线性关系必须查表或走编码转换。很多人第一次做字库会翻车在这里拿 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([area0xA0, pos0xA0]).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[i1] for i in range(0, 32, 2)] code f{area0xA0:02x}{pos0xA0:02x} font[code] rows with open(OUT_PATH, w, encodingutf-8) as f: json.dump(font, f, ensure_asciiFalse, separators(,, :))separators(,, :)去掉 JSON 里的空格能把文件压掉将近三成。ensure_asciiFalse让键保持原样不过这里键本来就是十六进制字符串影响不大。生成完先看文件大小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_asciiTrue键变成了\uXXXX转义而读取端按原样匹配。解决方法是生成时统一用ensure_asciiFalse并且读写都指定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, encodingutf-8).read(): try: b ch.encode(gb2312) used.add(f{b[0]:02x}{b[1]:02x}) except UnicodeEncodeError: pass with open(gb2312_font.json, encodingutf-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, encodingutf-8) as f: json.dump(small, f, separators(,, :), ensure_asciiFalse)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[i1] img.data[i2] bit ? 0 : 255; img.data[i3] 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 上做降级处理。这套流程我前后在几个小屏项目里用过最深的教训是别一上来就写渲染先把码位和偏移算对拿三五个字打印出来看形状确认数据层没问题再往上搭。字库这东西数据错一位后面全白干。希望帮到你。本文还有配套的精品资源点击获取
