物流提单智能解析海运空运自动化处理方案GitHub开源

面向国际物流场景的提单智能解析工具，可处理海运提单、海运单及空运单的PDF、扫描件或拍照件，自动识别单据类型并抽取发货人、收货人、起运港、货物描述、件数、重量、体积等核心字段，输出统一JSON结构，具备版式还原、字段定位及多单位标准化能力。

GitHub 项目地址：https://github.com/intsig-textin/xparse-sample-projects

国际物流业务的复杂性，很大程度体现在单证处理环节。海运提单、海运单、空运单尽管同属运输单据，但字段位置、标题命名及版式风格差异显著。发货人、收货人、通知方、起运港、目的港、货物描述、箱号封号等关键信息可能分布在单据不同区域，且货物描述部分常出现跨页、表格与自由文本混合的情况。

这类文档若完全依靠人工录入，不仅效率低下，还对操作经验有极高要求。真正成熟的物流提单解析方案，其价值并非“看懂一张单据”，而是构建一套不依赖固定模板、能灵活适配多种船司与货代版式的结构化处理能力。

一、为什么提单自动化处理始终难做？

提单场景的难点主要来自三个方面。

第一，单据类型多样。Ocean Bill of Lading、Sea Waybill、Air Waybill 虽都是运输单据，但字段侧重点各不相同。海运更关注船名航次、箱号封号和正本份数，空运则侧重计费重量与处理信息。

第二，字段表达不稳定。相同字段在不同模板上可能名称各异，港口和机场既有全称写法，也有缩写或代码形式。

第三，货物区域结构复杂。货物描述、件数、重量、体积可能出现在规则表格中，也可能由多段拼接文本构成。传统模板方法往往在此处失效。

因此，物流提单智能化的关键，不是让系统记住所有版式，而是使其具备跨版式理解和统一映射的能力。

二、一条更适合物流单证的技术路线

面向提单场景，更可靠的方案通常包含四层：

[提单文件]↓[版式感知 OCR]保留字段块、表格、页面位置↓[单据分类层]判断海运提单 / 海运单 / 空运单↓[统一字段抽取层]将不同单据类型映射为同一套业务结构↓[规则归一化与校验]日期、重量、体积、件数标准化↓[TMS / ERP / 关务 / 供应链系统]

这条技术路线的核心在于先分类，再映射。

分类层的作用并非直接输出最终业务结果，而是帮助系统理解当前单据类型、货物区域更接近表格还是自由文本，以及后续应优先关注哪些别名和字段块。只有这一层足够稳定，后续的统一抽取才有意义。

统一字段抽取层则负责将海运和空运中真正重要的信息收敛到一套稳定 schema 中。这样，前端和下游系统无需为不同单据类型维护多套独立处理逻辑。

三、如果要快速落地，一个提单工具至少需要这几层实现

提单工具的技术结构，建议明确拆分为五块：

文件接入层↓OCR 解析层↓单据分类层↓统一字段抽取层↓标准化与复核层

这五块中，最容易被忽略的不是 OCR，而是分类层和标准化层。分类层决定抽取策略，标准化层决定结果能否真正进入业务系统。

1. OCR 中间层要保留字段块和页面坐标

提单中包含大量块状区域，例如发货人、收货人、通知方、港口和货物描述。为支持后续抽取与复核，OCR 返回结构建议至少包含一份“文本结构 + 页面定位”中间层：

{"content_markdown": "...","page_snapshots": [{"page_number": 1,"page_ref": "page_1","page_size": { "width": 1600, "height": 2300 },"blocks": [{ "text": "Shipper", "bbox": [100, 120, 180, 145] }]}]}

其中：

content_markdown：为分类层和抽取层提供结构化文本
page_ref：每页的唯一引用，用于加载原图及页级缓存
page_size：原始页面尺寸，用于坐标换算
bbox：文本块在页面上的位置框，支持点击字段后高亮原文

2. 分类层要输出“抽取提示”，而不是只输出单据类型

一个可直接落地的分类结果应包含：

document_type：具体的单据类型
language：文档语言
layout_style：版式风格
cargo_region_type：货物区域的类型
likely_sections：可能的区域划分
strategy_hints：抽取策略提示

例如：

{"document_type": "air_waybill","cargo_region_type": "table_like","strategy_hints": {"prefer_table_extraction_for_cargo": true,"prefer_block_extraction_for_parties": true,"focus_aliases": ["AWB No.", "Consignee", "Airport of Departure"]}

这一步的意义，是让后续抽取不必在一份完全未知的文档上盲目展开，而是先获得结构理解和策略提示。

3. 统一字段 schema 应覆盖共性字段，差异字段做可选项

一个适合提单场景的结果结构可以设计为：

{"standard_fields": {"document_no": "123-12345678","shipper": { "name": "ABC Trading", "address": "..." },"consignee": { "name": "XYZ Imports", "address": "..." },"port_of_loading": "Shanghai","port_of_discharge": "Los Angeles","description_of_goods": "Plastic household goods","gross_weight": "12500 KGS","measurement": "86.5 CBM","chargeable_weight": null},"extra_fields": [],"missing_fields": [],"warnings": []}

海运和空运的差异字段，如 vessel、voyage_no、chargeable_weight、handling_info，可作为可选项存在。这样结果层就能保持稳定，无需为不同单据重建前端。

4. 标准化层负责日期、重量、体积和件数

提单抽取的结果通常包含大量原始值，例如：

12,500 KGS
27,000 LBS
86.5 CBM
500 CARTONS

这些字段最好在规则层再做一次标准化：

代码语言：ja vascript

const normalized = {issue_date_iso: normalizeDate(issueDate),gross_weight_kg: parseWeight(grossWeight),measurement_cbm: parseVolume(measurement),package_count_int: parseCount(packageCount)};

这样既保留原始字段，又能直接为 ERP、TMS 或关务系统提供稳定数值。

四、方案真正的价值：摆脱“按船司模板逐个维护”的旧路径

物流单证项目最常见的陷阱是按模板做。短期看，这种方法上线快；长期看，一旦版式增多，维护成本会迅速攀升。

更有价值的方案，是将通用能力建立在文档解析链路上：

OCR 负责适应版式变化，而不是人工维护位置模板
分类层负责识别单据语义差异，而非为每类单据重做一套页面
统一 schema 负责承接业务字段，避免下游系统面对不稳定结果
规则层负责完成重量、体积、件数等标准化，减少后续处理成本

这种方案的优势在于：当新增船司、货代或新版式出现时，系统多数情况下只需调整策略和规则，而无需为每种模板重新投入人工建模。