摘要： PDF 适合阅读，却不天然等于结构化数据。本文从页面文本、坐标与表格的差异出发，给出"翻译辅助理解---PDF 转 JSON---Schema 设计---清洗校验---接入 LLM 或知识库"的完整流程，并说明复杂表格、公式、扫描件和跨页结构为什么仍需人工抽检。
很多项目拿到 PDF 后，下一步不是继续阅读，而是希望把内容交给程序：提取报告元数据、拆出每页段落、读取表格记录，或者整理成适合 LLM 和 RAG 使用的数据。此时常见误区是认为"页面上看起来有标题和表格，转换后自然就会得到干净字段"。
事实上，PDF 的主要目标是稳定呈现页面。一个表格可能只是若干带坐标的文字块和线条；一段正文也可能被拆成多行、多个文本框。PDF 转 JSON 能把页面对象变成程序可读的结构，但从"可读结构"走到"业务字段"，通常还需要 Schema 设计、清洗和验证。
先明确：JSON 解决什么问题
Markdown 更适合编辑、人工阅读和按标题切分；JSON 更适合表达字段、数组、层级、坐标和数据类型。若目标是建立内容库，Markdown 往往更直观；若要按页追踪来源、提取表格记录、调用校验程序或构造 LLM 输入，JSON 的边界更清晰。
这并不意味着 JSON 一定更"准确"。它只是保留结构的容器。源 PDF 没有可用文本层、阅读顺序混乱，或表格跨页合并时，输出仍可能需要重建。
PDF 中常见的三层信息
第一层是文档级元数据，例如文件名、标题、作者和页数；第二层是页面级信息，例如页码、宽高和旋转方向；第三层是内容元素，包括文本、坐标、字体信息、链接或表格结构。不同工具输出字段会有差异，因此下游代码不能只凭想象写死字段名，应先查看真实样本。
如果外文内容会影响字段设计，可以先用 PDF Translator 生成辅助阅读版本，理解章节和术语后，再对原始 PDF 做结构化提取。翻译稿适合解释含义，原始文件适合保留页码、字符和数据证据，两者不要混为同一份数据源。
从 PDF 到可用 JSON 的完整流程
第一步：检查源文件类型
尝试选中并复制正文。如果复制结果基本正常，通常说明存在文本层；如果整页只能作为图片选中，则可能是扫描件，需要先进行 OCR。还要观察是否存在多栏、旋转页、重复页眉页脚、跨页表格和大量公式，这些都决定后续抽检强度。
第二步：先做小范围转换
不要直接把数百页文件送入下游。先选择包含标题、正文、复杂表格和脚注的代表性页码，检查输出是否保留页序、文本内容、坐标和字体层级。官方 PDF to JSON 页面目前介绍的是浏览器本地处理，可选择页码范围，并输出元数据、页面尺寸和带坐标及字体信息的结构化文本元素；页面建议文件控制在 50MB 以下以获得更稳定的体验。
第三步：设计面向业务的 Schema
转换工具的原始 JSON 适合保存页面对象，但未必等于业务需要。可以在清洗层定义更稳定的中间结构，例如：
json
{
"source_file": "report-en.pdf",
"page": 12,
"section": "Evaluation",
"content": "The evaluation covers three datasets...",
"table": [
{"dataset": "Set-A", "metric": "F1", "value": 0.87}
]
}这里的 source_file 和 page 用于追溯，section 支持按章节过滤，content 保存连续文本，table 承载记录。实际项目还可增加 document_version、language、bbox 或 checksum，但应从检索、审计和更新需求出发，不必一次设计所有字段。
第四步：清理重复和断行
页眉、页脚、页码、水印可能在每页重复出现；英文换行还可能留下断词连字符。清洗时先统计重复模式，再依据位置和频率删除，避免把正文中真正重复的警告语误删。多栏页面应按坐标恢复阅读顺序，不能简单按字符串出现顺序拼接。
第五步：重建表格并校验类型
检查表头是否对应正确列，合并单元格是否被拆散，跨页表格是否重复或缺失表头。随后把数字、日期、布尔值和空值转换成明确类型。例如字符串 "0.87" 与数值 0.87 在排序、过滤和统计中表现不同；N/A 也不能在不了解语义时一律变成零。
第六步：接入 LLM、RAG 或分析流程
进入 LLM 前，可按章节或语义块组织 content，并把页码和来源字段一同带入，以便回答时回溯原文。进入 RAG 时还要设计切块长度、重叠、元数据过滤和引用返回；进入数据分析时则要先通过 Schema 校验和抽样比对。PDF Translator 与 JSON 转换在这条链路中承担不同角色：前者辅助理解外文语义，后者提供程序可读的页面结构，并不代表已经自动完成某个知识库平台的集成。
怎样设计一组有效的转换测试
正式批处理前，可以建立一个十几页的代表性测试集：普通单栏正文用于验证阅读顺序，多栏页面用于检查坐标排序，带合并单元格的表格用于验证行列，扫描页用于确认 OCR 边界，再加入公式、脚注、链接和旋转页。测试集不追求页数多，而要覆盖真实资料中最容易失败的结构。
验收时同时做结构检查和内容检查。结构检查关注 JSON 是否可解析、字段是否稳定、数组层级是否符合 Schema；内容检查则将若干页与原 PDF 逐项对照，确认文本、数字、单位、页码和表格关系。可以为每类元素设定允许人工修复还是必须阻断流程，避免所有错误都被当成同一等级。
当转换工具或清洗规则升级后，应重新运行这组样本，并比较字段数量、空值比例、重复段落和表格记录数。若输出结构改变，下游切块、索引和提示模板也可能需要同步调整。把测试样本和预期结果纳入版本管理，能让文档数据管道像普通程序一样具备回归验证能力。
建议加入的自动检查
- 必填字段是否存在，页码是否连续且在合法范围内；
source_file、版本和校验值能否定位到原始文件；- 文本是否出现异常乱码、重复段落或错误断词；
- 数字、日期、单位和空值的数据类型是否符合 Schema；
- 表格行列数是否与代表性页面一致；
- 每个切块是否保留章节、页码和来源信息；
- LLM 输出中的结论能否回到原 PDF 对应位置；
- 扫描页、公式、多栏和跨页表格是否进入人工抽检样本。
复杂内容的处理边界
扫描 PDF 的首要问题是 OCR，而不是 JSON 格式；复杂公式可能以字符、图片或绘制对象存在；跨页表格则需要理解上一页表头和下一页续表关系。即使转换结果语法合法，也不代表语义完整。对财务数字、实验数据、合同条款等高风险内容，应建立逐项复核或双人验收机制。
总结
PDF 转 JSON 的关键，不是得到一个能被解析的文件，而是建立可追溯、可校验、适合下游任务的数据结构。比较稳妥的流程是：先识别源文件类型，用小样本观察真实输出，再设计 Schema、清洗重复内容、校验表格和数据类型，最后接入 LLM 或知识库。保留原文件、页码和抽检记录，才能让结构化结果在后续更新与问题排查中持续可用。
推荐标签： PDF JSON LLM RAG 数据处理