古籍PDF转TXT：OCR全流程实践指南

一、为什么古籍OCR是一件“难事”

与印刷体现代文档相比，古籍扫描件对识别管线提出了高得多的要求，主要体现在四个方面：

1. 版式特殊：绝大多数古籍采用竖排排版，阅读顺序为“从右到左、自上而下”，与横排文本完全相反。如果OCR引擎缺乏竖排版面分析能力，输出的字符顺序往往会被打乱，甚至按“从左到右”错误拼接，得到一页“每个字都对、整页不可读”的结果。
2. 字符集复杂：古籍以繁体字为主，还大量存在异体字、俗字、避讳字，部分字符位于Unicode扩展区（如扩展A区、扩展B区）。一些引擎的输出字符集无法覆盖这些字形，会表现为乱码或空心方框。
3. 图像质量参差：扫描件常伴有纸张发黄、墨迹晕染、虫蛀、水渍、装订遮挡等问题，字迹与背景对比度低，直接识别效果差。
4. 缺乏标点：不少刻本原文没有现代标点，即便文字识别全部正确，也还需要考虑是否句读、如何断段，这属于另一个层面的加工决策。

理解这些难点，有助于在后文有针对性地选择工具与参数，而不是盲目追求“一键转换”。

二、整体技术链路设计

一条可复用的古籍数字化流水线通常包含五个阶段：

扫描PDF → 页面渲染 → 图像预处理 → OCR识别 → 后处理 → TXT

各阶段目标明确、职责单一：

• 页面渲染：把PDF每一页变成高分辨率图像，是所有后续处理的原材料；
• 图像预处理：提升文字与背景对比度、纠正倾斜、去除噪声；
• OCR识别：完成字符识别与版面分析，输出结构化结果（字符、坐标、置信度）；
• 后处理：还原阅读顺序、清理噪声字符、统一编码与格式；
• 人工校对：抽样评估与定点修正，形成质量闭环。

把环节拆开来做的好处是：任何一个环节的质量问题都能被单独定位和调优，而不是把所有误差混在一起无从下手。

三、页面渲染：别让第一步偷走识别率

古籍PDF几乎都是图像型扫描件，内部没有可提取的文本层，必须先“渲染”为图像。这一步有两个关键参数：

• 分辨率：建议不低于300 DPI；对于小字号、残损页面，可提高到400~600 DPI。分辨率过低会丢失笔画细节，过高则拖慢识别速度、放大噪点，需要结合样本实测来权衡。
• 图像格式：中间结果保存为无损格式（如PNG、TIFF），避免JPEG有损压缩在文字边缘引入振铃伪影，给后续二值化埋雷。

示意代码（伪代码，函数名仅作说明）：

# 将PDF逐页渲染为高分辨率图像
pages = render_pdf_to_images("guji.pdf", dpi=300, fmt="png")

四、图像预处理：识别率的一半在输入

经验上，预处理对最终准确率的影响不亚于识别引擎本身。常用手段包括：

1. 灰度化与自适应二值化：古籍背景往往不均匀，全局阈值容易把发黄区域误判为墨迹，采用自适应阈值（如大津法及其局部化变体）效果更稳；
2. 倾斜校正：扫描或装订常导致页面歪斜，竖排文本倾斜几度就会显著增加列切分难度，可用投影法或霍夫变换估计倾斜角度后旋转回正；
3. 去噪与去污：中值滤波、形态学操作可去除孤立噪点；对大面积水渍，可结合局部对比度增强处理；
4. 裁剪版心：页眉、页码、鱼尾、边框对正文识别没有价值，反而干扰版面分析，预处理阶段可按版心位置统一裁剪。

建议把预处理参数做成配置项，对不同批次、不同来源的扫描件分别调优，并记录每组参数对应的识别效果，形成可回溯的实验记录。

五、识别引擎选型：按能力维度评估

市面上的方案大致分为四类，选型时建议按能力维度而非品牌来评估：

方案类型	适用场景	关注点
桌面/在线OCR工具	少量页面、一次性任务	是否支持竖排与繁体、是否有批量入口
云服务商OCR API	大批量、需集成到自有系统	竖排与版面分析能力、并发与计费、数据安全
开源引擎自建	有研发能力、需私有化部署	模型对古籍字体的适配、训练与微调成本
专业古籍数字化平台	大规模整理、出版级项目	校对工具链、项目管理能力

以通用云服务为例，主流云厂商（如百度智能云）的文字识别服务通常提供通用文字识别、版面分析等能力，并支持通过API批量调用；具体支持的语言、版式与接口参数应以官方文档为准。无论采用哪类方案，都建议先用具有代表性的10~20页做小样测试，再决定是否全量跑批。

选型时重点核对以下能力清单：

• 是否支持竖排文本的列切分与正确的阅读顺序；
• 是否覆盖繁体字及Unicode扩展区字符；
• 是否提供版面分析，能区分正文、批注、印章等区域；
• 是否支持批量接口、异步回调与失败重试；
• 是否满足数据合规要求（古籍文本多为公有领域，但扫描件本身可能涉及合作方权益）。

六、版面还原：把“列”读对

竖排文本的输出顺序是古籍OCR最容易出错、也最容易被忽视的环节：

• 引擎需要先做列检测，把每页切分为若干竖排列；
• 再按从右到左的顺序拼接各列，每列内部自上而下输出；
• 页眉、页码、夹批、印章应被版面分析标记出来，或过滤、或单独存放；
• 跨页的段落需要在后处理阶段按语义合并，避免每页都从新行开始。

如果所用引擎不提供竖排版面分析，就需要自行实现列切分：对二值化图像按列做垂直投影，找到列间空白带作为切分点，再从最右侧列开始依次输出。这一步的逻辑不复杂，但对边界情况（如夹批小字、双行小注）要有容错设计。

七、后处理与文本规范化

识别结果距离“干净的TXT”还有一段距离，常见处理包括：

1. 编码统一：输出统一为UTF-8，避免扩展区字符在后续流程中丢失或变成问号；
2. 空白与换行清理：去除列拼接产生的多余空格，按项目规范重排段落；
3. 全半角与标点：统一全角/半角形式；是否自动添加现代标点应谨慎，学术用途通常保留原貌，句读交由人工完成，机器句读结果只宜作为参考；
4. 异体字处理：建立“异体字—正字”映射表，按项目规范决定保留原字形还是归一化；映射表应可配置、可追溯，不要在文本上做不可逆替换；
5. 简繁转换：如最终需要简体版本，应在校对完成后再做转换，并始终保留繁体母本，避免转换误差混入校对环节。

八、批量自动化：一个可复用的处理骨架

下面的伪代码展示了一条最小可用流水线的骨架：

import pathlib
CONFIG = {"dpi": 300, "lang": "zh-classical", "layout": "vertical"}
def pdf_to_txt(pdf_path, out_path):
    pages = render_pdf_to_images(pdf_path, dpi=CONFIG["dpi"])
    lines = []
    for idx, img in enumerate(pages):
        img = preprocess(img)                  # 二值化、纠偏、裁剪版心
        result = ocr_recognize(img, **CONFIG)  # 调用OCR，返回结构化结果
        text = restore_reading_order(result)   # 从右到左拼接竖排列
        lines.append(clean_text(text))
        log(f"page {idx + 1} done")
    pathlib.Path(out_path).write_text("\n".join(lines), encoding="utf-8")

工程化落地时还需补充：

• 断点续跑：记录已完成的页码，任务失败后从断点恢复，避免整批重跑；
• 限流与重试：调用云API时遵守并发与频率限制，对超时和限流错误做指数退避重试；
• 结构化留存：除TXT外，建议同时保存OCR的原始结构化输出（含坐标与置信度），便于后续定位错字、重新校对与二次开发。

九、质量评估与人工校对

自动化流水线无法做到零错误，质量闭环必不可少：

• 抽样评估：从每批结果中随机抽取若干页，人工比对统计字符准确率，并按错误类型（形近字、漏识、乱序）分类归因；
• 对照校对：采用“左图右文”的双栏界面校对效率最高，可基于OCR输出的坐标信息自动定位到原图对应位置；
• 词典辅助：利用古籍词表、人名地名表对低置信度片段做候选提示，但最终判断应交给人；
• 迭代优化：把高频错误反馈到上游——是DPI不够、二值化过度，还是字体风格超出模型覆盖——针对性调整参数或补充训练样本，而不是反复手工改错。

十、常见问题速查

• 输出顺序混乱：几乎都是版面分析问题，确认引擎支持竖排，或自行实现列切分；
• 整页大量错字：优先检查DPI与二值化参数，再评估字体是否特殊（如手写体、书法体）；
• 生僻字变成方框或乱码：字符集覆盖不足，需更换支持扩展区字符的引擎，或补充字形映射；
• 虫蛀、水渍区域无法识别：预处理难以挽救时，标记该区域转人工补录，不要强行输出错误文本污染全文；
• 跨页段落断裂：在后处理中按上下文合并，必要时引入轻量的语句连贯性判断。

十一、小结

把古籍PDF转成TXT，本质上是一条“图像—版面—文本”的重建流水线，而不是单点工具的一键转换。先把渲染、预处理、竖排版面、后处理、校对五个环节拆开来做，每一环都有明确的输入输出和质量标准，再按批次的扫描特点持续调参，就能以较低的人工成本获得接近出版级质量的文本。对于希望以API形式集成到自有系统的团队，可以先在主流云厂商（如百度智能云）的文字识别服务上做小样验证，再权衡自建或采购，让技术选型始终服务于古籍整理的质量目标。