护照 OCR API：ICAO 9303 MRZ 与字段提取

护照 OCR 是针对护照数据页布局做了专门优化的光学字符识别。通用 OCR 把护照当作普通文档：返回一组扁平的文本块，并不知道哪一行是证件号、哪一行是出生日期、MRZ 从哪里开始到哪里结束。

护照 OCR API 在通用 OCR 之上做了两件事。第一，按 ICAO 9303 严格格式定位并解析数据页底部的 MRZ，并校验字符串内嵌的校验位。第二，识别 MRZ 上方的可视字段，并以命名字段（passportNumber、name、birthDay、expiryDay 等）返回结构化 JSON。你不再需要对原始文本写一堆正则，而是直接消费固定结构的对象。

MRZ 是每本符合 ICAO 9303 旅行证件数据页底部的两行或三行 OCR-A 字体文本。它编码了护照号、签发国、姓名（以 < 字符分隔）、出生日期、性别、有效期、国籍，以及五个独立的校验位，用数学方式验证周围的数据。

PicToText 的解码分三步：先用 OCR-A 字符集分行，再按 ICAO 9303 规范把每一段定宽字段映射到含义，最后按规范算法重新计算校验位并与印刷值比对。如果某个校验位失败，引擎会照常返回读取到的值，同时在响应中标注 MRZ 字符串，便于你的应用决定是重试、提示用户重新拍摄，还是把证件升级到人工复核。

支持所有符合 ICAO 9303 的旅行证件，包括本式护照（TD3 — 两行各 44 字符）和卡片型旅行证件（TD1 — 三行各 30 字符；TD2 — 两行各 36 字符）。实际意义上，这覆盖了几乎所有联合国成员国签发的现代护照，以及难民旅行证件、紧急旅行证件等大多数特殊证件。

覆盖 200+ 国家和地区。早于 ICAO 9303 强制要求之前签发的非机读护照（多数国家是 2010 年前，部分国家更早）不在支持范围内，因为这些证件根本没有 MRZ。如果你需要的国家或文档类型目前识别效果不理想，最快的路径是发几张样本图过来 — 新增可视布局通常 1-2 周内可以上线。

准确率取决于输入。对一张完好的护照做扫描件，MRZ 几乎可以稳定干净地提取，因为 OCR-A 字体本身就是为机读设计，且引擎会校验校验位 — 这是护照能给出的最可靠信号。出生地、签发地这类可视字段从 MRZ 上方的 VIZ 提取，因为各国字体和排版差异较大，准确率通常会低几个百分点。

手机拍照场景下，常见的失败原因是相片覆膜反光、运动模糊以及数据页倾斜拍摄。引擎对这三类问题都做了预处理（旋转校正、反光抑制、页面检测），所以做一个"引导式拍摄"流程（用屏幕上的对齐框提示用户放正后再拍）能在不重试的情况下覆盖大多数情况。我们不公开单一的准确率数字，因为没有测量方法的数字本身意义有限 — 我们愿意基于你的图片分布做一次基准测试。

适合 — 护照 OCR 是 eKYC 管线中的标准组件之一，API 的设计就是为了作为数据提取环节嵌入。结构化的 JSON 输出能轻松接入下游服务：PEP 与制裁筛查（需要标准化的姓名、出生日期、国籍）、年龄核验（出生日期）、证件有效期检查（有效期）以及黑名单匹配。

合规级别的流程通常还会叠两层：第一，文档真实性信号 — 我们响应里的 MRZ 校验位结果是其中一种，配合电子护照芯片 NFC 读取（用户手机端）可以进一步提高门槛。第二，自拍活体检测或人脸比对，把证件与出示者绑定。OCR API 是数据层，真实性与活体层是你掌握的策略决策。

API 是单一的 REST 接口，接受 multipart/form-data，因此任何具备 HTTP 客户端的语言都可以调用。公开文档包含 cURL、Python (requests)、Node.js (fetch + FormData)、PHP (cURL)、Java (OkHttp) 与 Ruby (Net::HTTP) 的可粘贴示例。如果你的技术栈是 Go、Rust、C#、Elixir 之类的其他语言，调用结构是完全一致的。

移动端建议在客户端采集护照图片（iOS 的 PHPickerViewController、Android 的 CameraX、React Native 的 vision-camera），然后由你的移动后端再 POST 给 API，避免把 API Key 嵌入到 App 里。我们也提供 OpenAPI / Postman collection，便于你为自己的语言生成强类型客户端。

护照图片在内存中处理后生成 OCR 结果。我们不要求你授权我们长期保存图片用于识别。默认情况下，原始图片字节在响应返回后不再保留；只有请求元数据（时间戳、账户 ID、文档类型、成功/失败状态）会被记录，用于计费和滥用防护。

如果你需要更严格的处理方式 — 比如完全不存储任何衍生数据、客户托管密钥、指定处理区域 — 这些都可以在企业方案中配置。合规受监管的工作负载，我们可以按需提供数据处理协议 (DPA)，并把部署范围限定在特定区域。如果你对数据驻留有明确要求，建议在接入前先与销售沟通；初次就配置正确比之后再迁移要轻得多。

按成功识别次数计费，免费试用包含 100 次调用，便于你在真实图片上做集成测试再做决定。试用之外，方案按规模从按量付费（适合原型与低量）过渡到按月套餐（适合稳定生产流量），高量或合同型用户提供企业谈判价。

护照、身份证、驾照三个接口定价一致，所以你可以混合使用各种文档类型而不会有意外开销。我们不按字段加价，也不为 MRZ 解析额外收费 — 每次护照识别都包含完整的 10 个字段。具体单价与套餐阈值见定价页。

Mindee 和 Nanonets 提供通用文档 AI 平台，护照接口只是其中之一。如果你的团队还需要在同一个平台上识别小票、发票或任意表单，它们是不错的选择。AWS Textract 是更底层的通用 OCR 原语 — 返回文本块和表格，但你需要在它之上自行实现护照专属解析逻辑，包括 MRZ 校验位算法。

PicToText 更聚焦：护照、身份证、驾照本身就是产品，而不是某个功能模块。带来的好处是响应结构稳定且有主张（没有 30 个可选字段开关），底层模型也专门针对旅行与身份证件做了调优。代价是如果你还需要在同一平台 OCR 任意业务文档，我们不是合适选择。选我们的团队大多在做身份或 KYC 流程，希望在三类证件上有一致的接口和聚焦的供应商。

从接收到 multipart 请求到返回 JSON 响应的端到端延迟，在图像清晰的情况下通常处于个位数秒级，主要来自图像解码与 OCR 模型推理。延迟会随输入分辨率上升：4 百万像素的手机拍照比 1080p 的截图占用更多挂钟时间。

对延迟敏感的场景（实时酒店入住、App 内注册），你能控制的最有效杠杆是客户端预处理 — 按合理分辨率拍摄（数据页长边大约 1200px 就足够读 MRZ），剥离 EXIF，按 JPEG 质量约 85 重新编码后再上传。在移动网络上，这能显著减少上传时间，而上传时间往往比服务端处理时间占的比例更大。