中科院张老师1. 这个工程到底是什么：给甲骨文字元“立碑”
1.1 项目来历：一个意外闯入者的自白
先说清楚，我进入这个圈子的过程本身就是个意外。我原本不是做古文字或者数字人文出身的人，既不认识那些约定俗成的数据交换格式，也没在相关社区混过，只是手里攒了一批甲骨拓片扫描件和零散的字形笔记，又刚好对结构化数据有强迫症，就开始用自己的方式处理它们。
于是就有了这个名叫“CNSH”的项目，全称我自己定义为“Chinese Script in Self Heritage”，翻译过来就是“以独立方式整理的汉字遗产”，但说白了，CNSH 只是我给自己这套东西起的内部代号。而“数字甲骨文字元立碑工程”是它的完整说法：把甲骨文按最小字元单位拆开，用我可控的、可扩展的规范去记录、编码、建索引，最终形成一种可供后人检索和使用的数字档案库。
为什么叫“立碑”而不叫“建库”或“平台”？因为“库里”的数据可以被随意覆盖、整理、清洗，而“碑”一旦立起来就意味着不可轻易涂改，每条记录都带出处、带状态、带时间印记。我做的是更像刻碑的事：一笔一笔刻进去，哪怕暂时张冠李戴，也保留证据，等以后修正。这里没有平台思维，也不是为了给谁做工具跑分，就是想用自己理解的方式，给这些几千年前的字形留下一个可靠的数据坐标。
1.2 “立碑”和“字元”在我这里的含义
在甲骨文研究里，“字元”本身没有特别成熟的统一定义。常见的是把“字”当最小单位，一个字对应一个含义，但甲骨文里有很多异体、合文、反写、倒写，同一个词在不同龟甲上刻法差异极大，所以单纯以“字”为粒度建档，会遇到大量冗余和冲突。
我采用的办法是把“字元”定义为：在一个具体字形切片里能够独立参与组合的最小构形单元。举个例子，“王”这个字形，它在多数拓片里就是一根立笔加一或两横；当它作为构件出现在“皇”或“玉”类字形里时，它既是字也是构件。那么建档时我不把它们硬拆成笔画，而是把“王”整体作为一个字元，同时记录它在结构位置中承担的角色。
“碑”对应的是这种不可逆、可追溯的归档策略。我会给每一条字元档案打上唯一的“碑码”，也就是 CNSH 编号，再配合原始图像路径、释读状态、字形坐标、轮廓数据、来源拓本、录入时间。这六类信息合在一起，才构成一条可以称为“碑”的完整字元档。我自己的要求是：可靠性优先，宁可暂时“未知”，也不能乱标成“已知”。数据做得不漂亮没关系，但每一条记录都得经得起追问。
1.3 做给谁看、能用到哪里
这个工程尽管不受“主流格式”约束，但它不是封闭自娱的东西。它的产出对象大概是三类人。
第一类是研究甲骨文但不太熟悉计算机处理的古文字学者，他们可以拿字元档案当检索目录，快速找到某个构形在哪些拓片上出现过，而不必一页页翻图录。第二类是字体设计师，尤其是做汉字节气类字体或文物复刻字体的人，他们最需要的是把字形轮廓矢量化的数据，我这份数据可以直接对接 SVG 路径或自定义坐标序列。第三类是数字人文方向的学生和开发者，他们需要一批带有较多附加信息（异体关系、出处、释读状态）的样例数据来测试分词、构件识别、字形聚类等算法。
我自己属于“外行”那一侧，所以我写文档时尽量不用缩略语轰炸。所有字段名称都带中文注释，所有步骤都可回退，连命令都放到脚本里做成可重复执行的版本。这就是我把“搅屎棍”当作荣誉勋章的原因：别人不按我的方式做，我不强求；但我用这套方式，至少没有出现“自己看不懂自己的数据”这种灾难性结果。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 为什么不走别人已经铺好的路
2.1 主流方案我为什么没接住
在动手之前，我也试图看了一些公共标准和社区做法。比较常见的方向包括：把甲骨文映射进 Unicode 私有区或扩展区，用 IDS 描述字形结构，在 GlyphWiki 上协作维护字形，用 TEI 给文字做元数据标注。这套体系本身很成熟，也凝聚了很多人的心血，但对我来说有几个现实问题。
第一，门槛高。Unicode 码位申请不是一个独立研究者能推动的，GlyphWiki 的协作规范也要花很长时间去对齐，更不用说 TEI 的复杂 schema 设计。我一开始只是想把手头那批材料整理出来，如果先花三个月学规范，可能项目早就黄了。第二，语义表达不完全匹配。很多标准是为“规范化汉字”设计的，遇到甲骨文里常见的无定释、异体、反刻字，标准方案里没有特别顺手的字段。第三，也是我最看重的：标准要求统一答案，而我的材料里大量存在“学者甲读作A、学者乙读作B”的情况，我不想在项目初期就强行消歧。
我最后的选择是，只借鉴这些方案的精神，不沿用它们的格式。精神是什么？是“字形优先、结构可解析、元数据可追溯”。所以我把 IDS 的树形结构思想简化成“构件角色标签”，把 TEI 的 title/desc/resp 精神压缩成“来源、状态、备注”三个字段。谁要拿我的数据去接入正式标准，完全可以通过脚本做映射，但我在源头上不再被某个框架锁住。
2.2 五维字元模型：我自己定义的最小结构
一条字元档案，最终被我收敛为五个维度：形态、结构、释读、出处、状态。
形态就是字形本身，包含位图像素裁剪框、SVG 轮廓路径、笔画数估算；结构描述的是这个字元在该切片里如何与其他字元组合，例如“独体”“左右结构”“上下结构”“嵌入结构”；释读是所有可考释读的集合，可以放多个观点，也可以空着；出处记录拓片编号、出版图录、馆藏编号、原图文件路径和坐标；状态标记这条档案处在“待识别”“待复核”“已复核”“存在争议”四档里的哪一档。
其他字段都是在这五个维度上的展开和补充。好处是我可以在数据量很大时，用“状态”字段自动过滤未验证内容，先做已复核结论，再做争议图谱。而“释读”允许投票和并列，因此不会因为我不知道正确答案就损失一个条目。这个模型不是论文里的理论创新，更像是我从泥浆里爬出来后给自己定的最低处事准则。
2.3 编码规则：用编号解决“没码位”的尴尬
甲骨文到底算不算字符，能不能进入Unicode，什么时候进入，不是我能够左右的。但我的数据里的每个字元必须有一个稳定编号，否则后续的关联、去重、版本比较都无从谈起。
我把编号设计成四段式结构：上半段 是固定标识，CNSH-；第一段 是批次号，表示这批数据来源于哪本图录或哪次整理；第二段 是字元序号，从 1 开始递增；最后加一位校验字母，用来在手工录入时快速发现抄写错误。比如一条完整编号可能是 CNSH-JY-0273-K，表示来自代号 JY 这批材料、第 273 条字元记录、校验位是 K。
校验位我自己用了一个很土但好算的办法：把前面所有字母数字转成 ASCII 码求和，再用和值除以 26 取英文大写字母。这种编号没法证明学术合法性，但对我来说已经足够稳定了。更重要的是，我明确规定“编号一旦分配就不回收、不改写”，即使后来发现这条记录内容错了，也保留编号，用新版本去覆盖内容，靠 Git 历史追踪差异。听起来笨，但面对海量异体字形，这种“笨规则”反而让数据特别扛折腾。
3. 从图像到字元档案：实操过程全记录
3.1 材料准备：先把拓片变成干净的二值图
我的工作流第一步永远是处理图像，不处理好图像，后面所有轮廓和切割都是空谈。原始扫描件通常是彩色或灰度图，甲骨表面有纹理、裂纹和污渍，直接用全局阈值切分会把裂纹也当成笔画。我一般先用 OpenCV 做三步：高斯模糊去掉扫描噪点，自适应阈值做局部二值化，再做一个中值滤波把孤立的小噪点清理掉。
具体的参数没有“万能值”，我是以拓本分辨率为基准反复看的。扫描分辨率在 300 dpi 左右，我常用 cv2.adaptiveThreshold 的 blockSize 取 51、C 值取 15；如果图特别脏，就把 blockSize 调大到 71，C 值调到 20。这个阶段最重要的是多试几组，否则白底上会残留大片黑斑。个人经验：不要迷信自动算法，最稳妥的流程是先自动二值化，再人工用矩形框把明显非字形的区域裁掉。
处理完的图像我会统一存成 PNG，文件名按 批次号-页码-序号 命名。注意 PNG 是无损格式，不要转 JPG，否则笔画边缘会出现压缩伪影，后来做轮廓提取时容易多出一堆毛刺点。
3.2 单字分割与轮廓提取
得到的二值图后，最难的是把每个字从整版拓片里切成独立单元。很多拓片上的字排列并不规整，有的倾斜，有的被边框或卜辞界格线交叉穿过。我先用连通域标记找前景连通区域，但甲骨文的笔画经常断裂，一个完整的字会碎成好几块，所以我还要在垂直和水平方向做投影，观察哪些区域之间距离足够近，把它们重新合并。
实际操作里我采用一个比较保守的策略：先用连通域跑一遍，面积小于 50 像素的噪声直接丢掉；再把结果按列聚类，列间距小于字体平均高度的 0.3 倍时合并，作为同一个字元候选区域。这个阈值也会根据具体拓片微调，不能一把抓到底。
单字候选框出来之后，我会把区域内像素转为轮廓坐标。最省事的方法是调用 OpenCV 的 cv2.findContours，拿到轮廓后再用 cv2.approxPolyDP 做折线简化，epsilon 设在 2.0 到 3.0 之间，这样既能减少顶点数，也不会丢失明显拐角。最终我把每个轮廓的归一化坐标点串存成一个数组，写入后文会讲的 JSON。这套流程跑完，每张拓片里我能得到的不是“已识别的字”，而是“结构完整的字形切片”，这已经够用了。
3.3 字元标注：释读、构件、出处、状态
切割完成后，真正的体力活是标注。我让每一份字元档案必须回答这几个问题：这个字形切片是独立成字，还是某个字的一部分？如果是某个字的构件，它在结构里处于什么位置？有没有学者给出过释读？如果有，至少引用一篇出处；如果没有，就老实写“未释读”。
举个例子，一张拓片里的某个圆圈形字元，单独看很像“日”，但它在上下文中和另一个构件组合，学者们有不同说法。我的做法是：形态上记录它是“外框+内部一短横”，构形标签写“外框结构”，释读字段写成“日？/丁？/争议待考”，并在备注里记录我看到哪几条研究线索。这样既保留了原状，也降低了错误率。
我不追求每条记录都被“最终释读”，因为我更看中的是未来能不能在数据层面去验证各家学说。哪怕现在写了一堆问号，也比硬套一个热门释读要踏实。
3.4 首轮成果：建立“待释读”档案库
第一批数据整理完成后，我手上大概是八百多条字元档案，其中只有不到三分之一有明确释读，其余全是“待复核”或“未释读”状态。看起来比例很难看，但我认为这就是真实状态。很多公开字形库美观、整齐，可我怀疑它们在处理有争议字形时做了太多“主动猜测”。
我把这八百多条数据按批次做成了本地 HTML 缩略图网格，每张卡片显示字形的位图切片、CNSH 编号、释读状态和笔画数估算。这个页面不对外开放，只是为了自己巡检。巡检时我会用最快速度扫一遍，凡是看到“明显不是同一个字却连在一起”或者“切碎了本应完整字形”的情况，就立刻回去修图像和轮廓。数据可以慢，但不能再往回退。
4. 数据格式、工具链与一条档案的生产流水线
4.1 一条档案长什么样：JSON 结构拆解
我最终把每条字元档案存成独立 JSON 文件，文件名就是 CNSH 编号。JSON 比 XML 写起来省事，也比 CSV 能表达嵌套结构，对我和潜在使用者都比较友好。下面是一个精简版结构，我加了注释说明：
json复制{
"id": "CNSH-JY-0273-K",
"batch": "JY",
"created": "2024-03-12T21:40:00+08:00",
"updated": "2024-03-12T21:40:00+08:00",
"state": "unread",
"glyph": {
"type": "single",
"components": ["外框", "内横"],
"structure": "外框内含横线",
"contour_paths": [[{"x": 0.12, "y": 0.08}, {"x": 0.14, "y": 0.21}]],
"bitmap_source": "images/JY/page_003_region_027.png",
"bbox": [120, 80, 156, 112]
},
"reading": {
"opinions": [
{"text": "日", "ref": "某释文卷三", "author": "未详"},
{"text": "丁", "ref": "某字形汇编", "author": "未详"}
],
"preliminary": null
},
"source": {
"catalog": "某拓片集",
"archive_no": "JY-0031",
"notes": "该字形边缘有残损，内横与边框粘连"
}
}
这里 contour_paths 是归一化坐标序列，我没有用标准 SVG Path 字符串，而是直接用数组，因为写脚本处理起来更直观。如果你要接前端，只要再加一层转换脚本就能把数组渲染成 SVG 路径。bbox 是原始位图上的像素坐标，用于快速定位。preliminary 字段我刻意保留成 null，除非我有足够把握，否则不让模型随便吐一个“可能释读”污染数据。
4.2 用 Python 做批量校验和查重
数据文件一多，纯手工维护必出问题。我用 Python 写了个项目同级目录下的脚本 audit.py，专门做四件小事：扫描所有 JSON 文件、检查必填字段是否缺失、校验 CNSH 编号格式、检查 contour_paths 里的坐标是否在 0 到 1 之间。这个脚本我从第一批数据开始就跑得很勤，几乎每个小时都要跑一次。
这里贴一个最简版脚本思路：
python复制import json
from pathlib import Path
def audit(path: Path):
errors = []
data = json.loads(path.read_text(encoding="utf-8"))
if "id" not in data:
errors.append("missing id")
for opin in data.get("reading", {}).get("opinions", []):
if not opin.get("text"):
errors.append("opinion without text")
for path_group in data["glyph"]["contour_paths"]:
for pt in path_group:
if not (0 <= pt["x"] <= 1 and 0 <= pt["y"] <= 1):
errors.append("coordinate out of range")
return errors
这个脚本不聪明，但它能在第一时间发现我偶尔会犯的手残错误，比如漏打冒号、把坐标写成 1.2、复制一个 JSON 却忘了改 id。真正的“去重”我不会只靠脚本，因为字形相似度判断本身有争议，我是靠“构件字符串集合”做初筛，把包含完全一致构件组合的记录标记出来，再由我本人看缩略图决定要不要合并或保留。
4.3 可视化校验与人工巡检
脚本只能查格式，不能查语义。我每周会抽半小时做“字形网格巡检”。做法是写一个脚本读取一批 JSON，把每一条的 bitmap_source 缩略图和 contour_paths 生成的轮廓叠在一起，拼成一个大的网格 PNG。
为什么要叠轮廓而不是只看原图？因为轮廓数据是后续矢量化的依据，如果轮廓往左偏了一个像素，最后导出的字体比例就错了。巡检时我会放大到 400%，检查：轮廓是否闭合、笔画转角处是否断裂、轮廓是否超出了原字形的边界、多余的小块噪声是否被意外当成轮廓。
这个环节很累，但恰恰是整个工程能不能“立碑”的关键。用结构化的眼光看，甲骨文不是打印体汉字，笔画弹性极大，机器提取的轮廓很多地方需要人工修正。我有一版脚本可以通过点击网格里的编号，直接打开对应 JSON 的专门编辑页面，然后把坐标偏移量微调后再存回去。由于整个过程有 Git 版本控制，误操作也能回滚。
4.4 版本化备份：让数据可回滚
所有字元档案我都在一个 Git 仓库里管理，按批次分目录，提交信息统一写成“[JY] add records 270-285”这种可读格式。我知道很多数字人文项目喜欢用数据库，但我选 Git 的原因很现实：数据库的迁移和数据改动不透明，而 Git 的 diff 可以让我看到每一次“一个字元从未释读变成有释读”的时间线和作者。
我还会在每次完成一批标注后，用 tar 打包整个仓库放到另外一块移动硬盘上。热备份、冷备份双轨走，避免某天仓库崩了只能拍大腿。规则不难，但要一直记得：所有文件必须用 UTF-8 编码、所有图像文件必须和 JSON 一起纳入备份、提交前必须跑一次 audit.py。
5. 踩坑实录与“搅屎棍”生存指南
5.1 明明用了UTF-8，Excel打开还是乱码
我第一次把生成的 CSV 给朋友看时，对方说打开全是乱码。我第一反应是编码问题，但我确认过文件确实是 UTF-8。后来才发现问题出在“没有带 BOM 的 UTF-8”上。Windows 下的 Excel 默认读取 ANSI，遇到纯 UTF-8 文本就当成系统本地编码去解析，中文自然全灭。
解决办法有两个：要么导出 CSV 时加上 BOM 头，也就是在文件开头写入 \ufeff；要么干脆导出成 XLSX，用 openpyxl 写一个简单导出脚本，彻底避开编码坑。我现在对外提供的数据统一使用带 BOM 的 CSV 和 XLSX 两个版本，内部存档则一律是无 BOM 的 UTF-8 JSON。
5.2 拓片有反光/裂纹，字形提取出来是碎的
青铜器铭文和甲骨拓片里，裂纹是最大敌人。裂纹会在二值化后变成和笔画一样粗的黑线，把完整的字形硬生生切断。我一开始靠连通域聚类去处理，但效果不稳定，有些字还是碎成了四五块。
后来我换了一种思路：先对灰度图做形态学膨胀，把细小裂缝造成的断口连接起来，再做连通域提取，这样就比直接在原始二值图上操作稳健得多。代价是膨胀会让字形边缘向外扩张一两个像素，所以我提取完连通域后，会再用腐蚀回缩同样大小，尽量恢复轮廓。这套“先膨胀后腐蚀”，其实就是形态学闭运算，看起来不起眼，却解决了我一半以上的切分问题。
5.3 不认识的字元如何处理，不硬编硬猜
我做数据时最怕的不是“不知道”，而是“假装知道”。甲骨文释读本身就伴随大量争议，同一个字形，可能有四五种释读，谁也不能说哪个就是绝对正确。面对不认识、不确定的字元，我的操作规范是：在 state 里标记为 uncertain，在 reading.preliminary 里留空，把“可能释读”放到 opinions 里并附上出处；这样哪怕以后有学者用我的数据，也能一眼看出哪些字段是可靠结论、哪些是待验证信息。
刚开始我也试过用某种模型自动补释读，但发现它会把完全不相关的字形强行归入常见字，污染数据的速度比人工快得多。所以后来凡是机器给出但没有文献依据的释读，我统统不写入正表，最多放到备注里当噪声记录。
5.4 数据覆盖丢失后的急救办法
数据丢失这种事，我确实遇到过一次。起因是我改轮廓坐标时直接覆盖了原 JSON，然后把错误保存成了新版本。如果不是 Git 提前提交了上一版，那二十几条标注就得重新做。从那以后我给自己定了三条规则：每完成 30 条新档案就提交一次；每次批量修改前先打 tag；任何自动化的修改脚本在运行前必须输出将要触碰的文件列表，并在第一屏显示“是否继续”的确认提示。
如果你没有版本管理习惯，也至少要做到“三二一”备份原则：三份拷贝、两种介质、一份异地。我的实际操作是仓库本体在工作机、热备份在 NAS、冷备份在移动硬盘。移动硬盘每周末插上同步一次，NAS 则用定时任务每小时同步一次。对一个独立项目来说，这种备份强度已经足够了。
6. 关于这个项目的最后一点体会
写到这里，我其实并不想把它包装成什么“重大突破”。CNSH 数字甲骨文字元立碑工程到现在仍然是我一个人在维护的独立档案库，没接入任何官方码位，也没被主流社区收编。标题里的“搅屎棍”三个字，我早就当成一种夸奖——我不懂你们的格式，正好给了我一个理由去做自己的格式。
我在实际建碑过程中最大的体会是：整理古文字数据，前期最耗时的根本不是算法和代码，而是“敢于承认自己不懂”的勇气。一个字段填成“未知”不需要多大本事，难的是在压力下还能保留这些未知，而不是拿假答案去填满空位。每一次巡检网格里发现的切分错误、每一个释读状态从“未释读”变到“待复核”，都比最终导出多少条漂亮数据更有价值。
如果你也想做一些被主流框架边角化、但心里觉得值得的数字人文项目，我的建议只有一条：不要等标准成熟再动手，先用自己的方式把第一批数据立起来。只要保留出处、保留修订痕迹、保留存疑名单，哪怕后来被证明走了弯路，这份数据也依然是可用的历史记录。至于别人怎么看，等碑立起来再说吧。