一、汉字字形数据库的设计目标
1. 解决缺字问题
- 支持古今汉字（甲骨文、金文、小篆、楷书等）的统一表示与存储。
- 支持异体字、简化字、古写字等多种字形变体。
- 提供动态生成缺字的机制（如通过构字式）。
2. 支持字形结构分析与表达
- 记录每个字的直接部件与基础部件。
- 支持构字式（字形结构表达式），用符号表示部件之间的位置关系（⿰左右、⿱上下、⿴包含等）。
| 特征 | 直接部件 | 基础部件 |
|---|---|---|
| 拆分层级 | 第一层，直接构成 | 最底层，递归拆分得到 |
| 性质 | 可能是复合部件（可再拆） | 是最小单元，不可再拆 |
| 功能 | 反映字的直接结构关系 | 构成所有汉字的最小零件库 |
| 以“圓”为例 | 口、員 |
口、□、目、八 |
| 类比 | 预组装好的“屋顶”模块 | 制造屋顶的“木板”、“钉子” |
- 基础部件是构建整个数据库的基石。所有汉字都可以由一组数量有限的基础部件组合而成，这极大地简化了汉字信息的存储、检索和生成（尤其是缺字生成）。建立“基础部件集”的目的，是为了创建一个高效、系统的汉字“字母表”，从而为汉字数字化提供坚实的基础。
- 例如，数据库只需存储几百个基础部件的形状，就可以通过组合它们来理论上生成所有汉字，而不是为每个汉字单独存储一个图片，这对于处理数以万计的古汉字异体字至关重要。
3. 建立异体字关系网络
- 建立正字与异体字之间的映射关系。
- 支持按时代、地域、书体分类的异体字表。
4. 支持古今字形演变衔接
- 提供从古文字到今文字的演变路径。
- 支持按出处（如器号、简号、文献来源）检索字形。
5. 提供多维度检索与查询
- 支持按部件、部首、笔画、拼音、出处等多种方式检索。
- 支持复合条件查询（如“含‘贝’且含‘口’的字”）。
6. 支持多种输出与应用
- 提供字形图片下载（支持不同字体、大小、分辨率）。
- 支持缺字动态生成与显示。
- 提供API或数据接口供其他系统调用。
7. 兼容现有编码标准
- 支持Unicode、GB2312、GB18030等多种编码映射。
二、汉字字形数据库的设计方案
1. 数据库架构设计
（1）核心数据表结构
| 表名 | 字段说明 |
|---|---|
glyph |
字形ID、编码、出处、时代、书体、图片路径、构字式、风格码 |
component |
部件ID、名称、类型（基础/复合）、笔画数、图片 |
glyph_component |
字形ID、部件ID、位置关系、顺序 |
variant_group |
异体字组ID、主字ID、关系类型（简/繁/古/讹/异体/符箓/避讳/缺笔） |
source |
出处ID、类型（集成/合集/简号/拓片/玺印等）、名称、编号、年代 |
index_radical |
部首ID、部首名、字形ID列表 |
index_stroke |
笔画数、字形ID列表 |
index_pinyin |
拼音、字形ID列表 |
以 variant_group 表为例，这个表是汉字构形数据库中最核心的表之一，用于系统化地管理汉字异体字之间复杂的关系。为了解决“一个概念（字义）对应多个字形”的问题。它不直接存储字形数据，而是存储字形之间的关系。
| 字段名 | 说明 |
|---|---|
group_id | 异体字组ID。这是最重要的字段，每个一组异体字拥有一个唯一的组ID。组内所有字（无论主字异体）都共享同一个 group_id。 |
glyph_id | 字形ID。指向 glyph 表的主键，标识组内的一个具体字形。 |
is_primary | 是否为主字标志。这是一个布尔值（True/False），用于标识该字形是否是这组异体字中的“主字”或“正字”。通常选择最通用、最规范的字形作为主字，便于管理和检索。 |
relation_type | 关系类型。描述该字形与主字（或与本组）的具体关系。这是细化关系的关键字段。 |
其中，relation_type 的常见取值示例：
standard(标准体/正体): 被认定为规范的字形。simplified(简化字): 如「员」与「員」。traditional(繁体字): 如「員」与「员」。variant(通用异体字): 音义全同而形体不同的字，如「鵝」与「鵞」。ancient(古字): 古代通用，现代可能已不用，如「貟」（員的雕版）「鼎」（員的籀文）。oracle_bone_script(甲骨文异体): 甲骨文中的不同写法。bronze_script(金文异体): 金文中的不同写法。scribal_error(讹写字): 因传抄错误形成的字形。regional_variant(地域变体): 如战国楚系特有写法。calligraphic_variant(书体变体): 如草书写法。
举例：假设 glyph 表中已有以下记录：
| glyph_id | 汉字 | 出处/说明 |
|---|---|---|
| 10001 | 員 | 楷书，正体 |
| 10002 | 员 | 楷书，简化字 |
| 10003 | 鼎 | 楷书，說文籀文「員」的楷化形式 |
| 10004 | （甲骨文字形） | 《合集》10978 |
| 10005 | （金文字形） | 《集成》5861 |
那么，variant_group 表里就会建立这样的关系：
| group_id | glyph_id | is_primary | relation_type | 解释 |
|---|---|---|---|---|
| G001 | 10001 | True | standard | 將「員」設為這組異體字的主字（正字） |
| G001 | 10002 | False | simplified | 「员」是「員」的简化字 |
| G001 | 10003 | False | ancient | 「鼎」是「員」的古字（籀文） |
| G001 | 10004 | False | oracle_bone_script | 甲骨文字形是「員」的甲骨文异体 |
| G001 | 10005 | False | bronze_script | 金文字形是「員」的金文异体 |
- 灵活性：一个字形可以属于多个组。例如，某个字可能既是A字的异体，又是B字的异体，这可以通过将其放入两个不同的
group_id来实现。 - 高效查询：如果你想查找「员」的所有异体字，只需：
SELECT g.* FROM glyph g
JOIN variant_group v ON g.glyph_id = v.glyph_id
WHERE v.group_id = (SELECT group_id FROM variant_group WHERE glyph_id = 10002);
数据库会返回 glyph_id 为 10001, 10002, 10003, 10004, 10005 的所有记录，即「員、员、鼎、（甲骨文）、（金文）」。
（2）支持多时代、多书体的分层设计：
将数据库按时代和书体划分为相对独立但又互相关联的子库，便于分阶段建设、维护和扩展。每个子库有独立的部件集和异体字表，但可通过“主字-ID”进行跨库关联。这种关联机制可以确保任何一个字形都能追溯到其源流、异体、部件构成和出处。同时，支持持续集成新的字符集（如新出土文献）、新的研究成果和新的技术标准（如Unicode版本更新）。举例：
| 描述 | 关键属性（示例） | 参考字书/资料来源 | |
|---|---|---|---|
| 1. 甲骨文数据库 | 商周甲骨刻辞 | 分期（宾组/历组等）、钻凿形态、释文 | 《甲骨文合集》《殷墟甲骨刻辭類纂》 |
| 2. 金文数据库 | 青铜器铭文 | 器型、年代、国别、器名、器号 | 《殷周金文集成》《金文編》《商周青銅器銘文暨圖像集成》 |
| 3. 简帛数据库 | 战国秦汉简帛 | 出土墓号、简号、批次（如清华简、里耶秦简）、内容类型（遣策/律令/典籍） | 《楚系簡帛文字編》《睡虎地秦簡文字編》《長沙馬王堆漢墓簡帛集成》 |
| 4. 战国文字数据库 | 处理战国时期“言语异声、文字异形”的各系文字。 | 系别（齐/楚/燕/晋/秦）、载体（璽印/货币/陶文/玉石） | 《戰國文字編》《古璽文編》《古陶文彙編》 |
| 5. 小篆数据库 | 秦统一后的标准篆书 | 《说文》部首、正篆/重文标识 | 《說文解字》《說文解字詁林》 |
| 6. 隶书数据库 | 隶变过程的关键书体 | 时期（秦隶/汉隶）、碑刻名称（《礼器碑》《曹全碑》） | 《隸辨》《秦漢魏晉篆隸字形表》 |
| 7. 楷书数据库 | 现代通用汉字基础 | Unicode编码、拼音、部首、笔画数、异体关系 | 《漢語大字典》《異體字字典》《康熙字典》 |
| 8. 行书与草书数据库 | 书法、艺术研究需求 | 书家（王羲之/怀素）、法帖名称（《兰亭序》《自叙帖》） | 《中國草書大字典》《行書大字典》 |
| 9. 域外汉字数据库 | 日本、韩国、越南汉字及其变体。 | 国别、标准编码、本地读音（音讀/訓讀） | 《大漢和辭典》《韓漢大辭典》 |
2. 功能模块设计
（1）字形检索模块
- 支持按部首、笔画、拼音、部件、构字式、出处等多种方式检索。
- 支持异体字联动检索。
（2）构形分析模块
- 自动解析字形结构，生成构字式。
- 支持手动修正与标注。
（3）异体字管理模块
- 支持正字-异体字关系维护。
- 支持按时代、地域、文献来源分类。
（4）缺字处理模块
- 支持通过构字式动态生成缺字字形。
- 支持缺字图片导出（PNG/SVG）。
（5）数据导出与接口模块
- 提供RESTful API，支持JSON格式返回字形数据。
- 支持批量导出为CSV、XML、SQL等格式。
3. 技术难点
- 字形渲染：使用FreeType + HarfBuzz 支持矢量字型生成
4. 扩展功能
- 教学辅助功能：提供汉字演变动画、书写笔顺演示。
三、总结
该汉字构形数据库的设计目标是系统性、多维度、可扩展地管理汉字字形及其演变关系，尤其注重古文字与今文字的衔接、异体字处理和缺字动态生成。通过上述设计方案，可构建一个既能服务于学术研究，又能支持教育、出版、信息技术应用的综合性汉字资源平台。