PDF Parser

1. 自定义字段提取
   自己设置需要提取的字段名称和数据类型，包括字符串、数字、日期和布尔值，AI 根据字段定义寻找对应内容。
2. PDF 与图片解析
   除了 PDF，还支持 JPEG、PNG、WebP、TIFF、BMP、GIF 等常见图片格式。
3. JSON / CSV 输出
   结果可以导出为 JSON 或 CSV，前者方便程序处理，后者可以直接放进 Excel、Google Sheets 等表格工具。
4. 批量处理
   支持一次上传多个文件，适合连续处理发票、合同、简历等重复文档。
5. REST API
   开发者可以通过 API 把文档上传、字段提取和结果获取接进现有系统。
6. Live Preview
   在网页端定义字段后直接查看提取结果，不需要先写代码才能测试。

Web 界面没什么学习成本。

上传文件，定义字段，点击 Extract，结果直接出现在旁边。从打开页面到拿到第一份 JSON，两分钟左右就能走完。

我先用了一份标准机打发票，提取：

“发票编号、日期、总金额、供应商名称”。

这类版式规整的文件表现比较稳定，几个主要字段都能找到，数字也没有明显错位。

但不能把这种效果直接套到所有 PDF 上。

扫描质量差、字体模糊、印章盖住正文或者混有手写内容时，识别稳定性会下降。

它更适合本身就比较规整的业务文件，而不是拿来救所有“看不清”的扫描件。

字段怎么写也会影响结果。

比如只定义 total_amount，文档里同时有小计、税费和最终金额时，模型可能需要自己判断。

把描述改成：

“the final total amount including all taxes”

结果会更明确。

所以字段名只是第一层，遇到容易混淆的数据，最好顺手补一句说明。

免费额度也比较适合这种测试方式。

20 页不用绑信用卡，可以拿几种真实文件一起跑：正常 PDF、扫描件、不同供应商的发票或者版式不同的合同。

比只上传一份最干净的样例更容易看出实际准确率。

优缺点

优点

• 设置简单。 不需要先写正则表达式或为每一种版式制作解析模板。
• 字段可以自己定义。 同一个工具可以用于发票、合同、简历等不同场景。
• 支持图片。 不局限于原生 PDF。
• JSON 和 CSV 都能直接用。 对开发者和表格用户都比较方便。
• 免费额度不用绑卡。 可以拿真实文件测试以后再决定是否付费。
• 有 API。 比单纯的网页提取工具更容易接进批量流程。

缺点

• 复杂扫描件不够稳定。 手写、模糊、遮挡都会影响结果。
• 单文件限制 20MB。 高分辨率扫描合同可能需要先压缩或拆分。
• 按页收费。 文档页数波动很大时，月度成本需要提前算。
• 未使用额度不会结转。
• 不支持退款。 付费前最好先把典型文件跑一遍。

适合谁 / 不适合谁

适合：

• 财务团队。 批量从发票、账单和银行流水里提取固定字段。
• HR 团队。 把简历里的姓名、联系方式、经历等内容整理成结构化数据。
• 经常处理合同的人。 需要从大量类似文件中抓取日期、金额、主体等信息。
• 小企业和个人用户。 不想自己搭 OCR 和解析流程，可以直接从网页端开始。
• 开发者。 需要把 PDF 数据转成 JSON，再接数据库、自动化或 AI 工作流。

不太适合：

• 主要处理手写文件的人。 识别结果容易受字迹和扫描质量影响。
• 文档严重模糊或变形的场景。 上游图像质量太差时，后面的字段提取也很难稳定。
• 需要完全实时返回结果的系统。 单次解析仍需要一定处理时间。
• 数据不能离开内网的团队。 文件需要上传到云端处理，不适合严格禁止外传的资料。
• 需要本地部署的企业。 当前产品形态以 SaaS 和 API 为主。

PDF Parser 解决的问题比较单一：

把 PDF 里的指定信息批量整理成结构化数据。

如果文件本身比较规整，又总是在重复提取姓名、日期、金额、编号这些字段，它比人工复制或者自己写一套解析规则省事很多。

真正需要先确认的是准确率，而不是功能数量。

尤其同一种业务里往往会出现不同供应商、不同模板和不同扫描质量，只拿一份漂亮样例测试没有太大意义。

先用免费 20 页把手头几种典型文件都跑一次。

如果字段基本能直接用，只需要少量人工复核，再按每月实际页数选择套餐。要是大量结果都得重新检查和修改，自动提取本身就省不了多少时间。