简介:古文字考释长期依赖人工比对与个人学养,线索分散、难以复现。本文面向开发者梳理古汉字数字化研究的技术路径:从拓片与文献的数据建模、生僻字与异体字的编码表达,到古文字OCR、知识图谱构建与古籍语义检索,并附代码示例与参考架构,帮助读者用工程方法支撑考释、验证与知识沉淀。
在古文字研究领域,常见这样的研究路径:研究者围绕一件青铜器铭文展开考释,将某个字的构件拆解为若干象形来源并推断造字意图;再从《诗经》《尚书》等传世文献中寻找字义互证;继而以《说文解字》的训释为旁证,甚至将字形演变与地望、遗址关联起来。例如,有研究者在讨论《何尊》——这件铸有“宅兹中国”铭文的西周早期青铜器——时,将“善”字的图形分析为与“鬲”“羊”相关的构件组合,并由此推测其与获鼎、铸器等事件的联系;讨论“贲”“黄”等字时,又把字形与河流、高原等地望线索放在一起交叉验证;从《诗经·邶风》的“有鷕雉鸣”到马王堆帛书类出土材料,线索横跨文学、金文、简帛多个领域。
这类“新解”的价值在于提出了假说,但其方法高度依赖研究者的记忆与阅历:同一结论需要翻检大量文献、比对大量拓片,旁人很难复现其推理链条。从工程视角看,这本质上是一个多源异构数据的检索、关联与推理问题——而这恰好是软件开发者擅长解决的。本文以“象形文字新解”为题,介绍如何用现代数据技术为古文字研究搭建一套可复现的支撑系统。
古文字研究的素材大致分三类,建模方式各不相同。
第一类是图像素材:拓片、摹本、器物照片。它们体量大、格式多样,适合以对象存储统一管理,元数据(器名、出土地、年代、著录编号)落在结构化数据库中,通过外键关联图像地址。
第二类是文献素材:传世典籍如《诗经》《尚书》《说文解字》《周礼》,以及出土文献如帛书、简牍释文。这类素材应按“篇章—句—字”三级切分,并为每个字位建立倒排索引,才能支持“某字在哪些文献、哪些句子中出现过”这类查询。
第三类是研究素材:释文、考释笔记、假说。这是最容易被忽视的一层。建议把“假说”作为一等公民建模,记录提出者、依据、置信度与被反驳情况。
示意性的字级数据模型如下:
{"char_id": "Z-0001","form": "善","variants": ["譱"],"occurrences": [{"source": "何尊", "part": "铭文", "era": "西周早期"}],"decompositions": [{"ids": "⿱鬲羊", "proposer": "研究者甲", "note": "象形造字假说", "confidence": 0.4},{"ids": "⿱羊誩", "proposer": "《说文》系统", "note": "从誩从羊", "confidence": 0.8}]}
注意 decompositions 是一个数组:同一个字允许多种拆解并存,各有来源与置信度。这既尊重了学术争议,也为后续的对比验证留下空间。
古文字数字化的第一道坎是“字打不出来”。基本汉字区覆盖不了大量古文字与异体字,需要借助两个机制。
其一是Unicode的CJK扩展区。从基本区(U+4E00–U+9FFF)到扩展A、B直至最新的扩展区,散布着数万个古字。判断一个字符落在哪个区块,是清洗语料的基础操作:
def locate_block(ch: str) -> str:cp = ord(ch)blocks = [(0x4E00, 0x9FFF, "CJK基本区"),(0x3400, 0x4DBF, "CJK扩展A区"),(0x20000, 0x2A6DF, "CJK扩展B区"),(0x2A700, 0x2EBEF, "CJK扩展C~F区"),(0x30000, 0x323AF, "CJK扩展G~H区"),]for lo, hi, name in blocks:if lo <= cp <= hi:return namereturn "其他区块"
其二是IDS(表意文字描述序列)。当某字形尚未收入Unicode时,可用描述符表达构件关系:⿰表左右、⿱表上下、⿴表包围、⿳表三层竖排。例如按前述假说,“善”可暂记为 ⿱鬲羊;而《说文》系统的写法“譱”则可示意记为 ⿱羊誩。IDS的价值在于:即使字体缺字,结构信息也不会丢失,检索与比对仍可进行。
工程上要注意三件事:入库前统一做Unicode规范化(NFC),避免“视觉相同、码位不同”的重复记录;为IDS建立解析器,把描述串解析成构件树;对暂无码位的字形,用“占位符+图像引用”兜底,保证图像证据永远可达。
拓片识别与常规文档OCR差别很大,难点集中在三点。
第一,样本极少。许多字形只见于寥寥数器,无法指望通用模型直接覆盖。可行路线是:以检测模型先定位字框,再用少样本学习或度量学习方法做字形分类;同时用图像增强人为扩充样本——旋转、缩放、模拟锈蚀噪声、按笔画库合成“伪拓片”。
第二,噪声结构特殊。拓片的黑白分布反映的是雕凿与锈蚀,而非书写墨迹。预处理阶段需要针对椒盐状噪声做形态学滤波,并在训练数据中保留真实噪声分布,避免模型“学会”了干净数据、到了真拓片上失效。
第三,字形是连续变化的。古文字同一字存在大量异体,类别边界模糊。更务实的做法是把OCR定位为“召回工具”而非“判定工具”:系统给出Top-K候选与相似度,由研究者确认。识别结果永远带有人工复核状态字段,进入数据库前必须经过确认或修正。
“新解”式研究的核心动作是跨线索关联,这正是知识图谱的长项。可以把概念抽象为五类节点:字形、构件、文献、地望、假说。三元组示例:
(字形:善, 有异体, 字形:譱)(字形:譱, 说文释义, "吉也")(字形:善, 出现于, 铭文:何尊)(铭文:何尊, 年代, 西周早期)(假说:H-001, 主张, "善从鬲从羊,与获鼎铸器相关")(假说:H-001, 证据, 字形:善)(假说:H-001, 状态, 待验证)
有了图谱,许多过去靠翻书完成的工作变成一次查询:列出某器铭文中所有在《说文》中训释存疑的字;找出所有同时出现在《诗经》与西周金文中的字;追踪某假说的全部证据链是否自洽。
特别值得强调的是“假说”节点的价值。像“善从鬲从羊”这类与传统训释不同的观点,系统不应裁决其对错,而应保证:任何人在任何时间都能查到该假说、它的证据、它的反对证据,以及它是否被后续发现支持或削弱。这把学术争鸣从“散落在各处文章里的只言片语”变成了结构化、可追溯的数据。
在图谱之上,还需要语义检索层,解决“我记不清原句,但记得大意”的问题。
古汉语的分词与命名实体识别是基础:把“濟有深涉”切分为词,识别出“濟”是水名;把文本中的地望线索(河流、高原、州郡名)标注出来并与地理坐标关联。之后构建向量索引:对每个字位,拼接其字形描述、文献上下文、前人训释生成文本,经嵌入模型编码后入库。检索时,研究者用自然语言提问,例如“上从羊形、见于西周铜器、与鼎有关的字”,系统返回候选字及其证据片段。
示意性的检索流程:
def search(query: str, top_k: int = 10):q_vec = embed(query)candidates = vector_index.search(q_vec, top_k)results = []for char_id, score in candidates:record = db.get_char(char_id)results.append({"form": record["form"],"score": score,"evidence": summarize(record["occurrences"]),"hypotheses": [h["note"] for h in record["decompositions"]],})return results
关键设计是把 hypotheses 一并返回:检索不止给出“字是什么”,还给出“关于它有哪些说法”,让研究者直接站在前人思考之上。
工具不能代替判断,但可以固化流程。推荐一套四步工作流:
这套流程把“灵感迸发”式的考释,变成“登记—检索—质证—更新”的闭环,研究成果也随之从一篇文章变成可持续演进的数据资产。
整体上可采用分层架构:接入层负责拓片扫描与文献录入;存储层由对象存储(图像)、结构化数据库(元数据与释文)、图数据库(关联关系)、向量索引(语义检索)组成;计算层承担OCR推理与嵌入计算,可使用GPU实例加速;服务层对上提供检索与图谱查询接口;配套日志服务与监控告警保障长期运行。
工程落地时,选择通用类目的云产品能力即可覆盖上述需求,例如对象存储、GPU云服务器、容器平台、日志服务与监控告警等,按需组合、避免绑定专有接口。以百度智能云为例,其提供的同类通用能力可以直接映射到上述各层,开发者可基于容器平台部署识别与检索服务,用对象存储承载拓片图像,其余组件按团队技术栈自由选型。
从《何尊》铭文里的一个“善”字,到《诗经》中的一句“有鷕雉鸣”,古文字“新解”的魅力在于把零散线索连成图景。数字化技术不能替研究者提出假说,却能让每一条线索被看见、被追溯、被验证:字形有码位、构件有结构、假说有证据链、地望有坐标。当考释从个人记忆走向结构化数据,“新解”才可能从一家之言,成长为整个研究共同体可以共同检验、共同推进的知识——这正是技术对人文研究最实在的贡献。