HarmonyOS 7 + OCR Kit + Vision Kit 技术干货：票据文档识别、文本框定位与结构化提取闭环【鸿蒙心迹】

Ss88688

11人浏览 · 2026-09-29 11:47:16

Ss88688 · 2026-09-29 11:47:16 发布

这篇不想只讲“识别一张图片里的文字”。真正落到工程里，OCR 更像一条链：图片从哪里来，文本块怎么定位，倾斜内容怎么纠正，识别结果怎么结构化，最后又怎么让业务真正可用。

一、很多 OCR Demo 能跑，但离业务闭环还差很远

第一次接 OCR 能力时，最容易满足于一个简单结果：

选择图片；
调一下识别接口；
把整段文字吐出来；
页面上能看到结果。

如果只是学习接口，这样当然够了。

但只要你把需求往真实业务里放一步，问题马上就多起来了：

识别的到底是票据、发票、证件还是文档？
原图里哪些是正文，哪些是干扰信息？
文本块坐标有没有拿到？
倾斜、旋转、小字号文本是否可用？
最终业务要的是“一整段文字”，还是“金额、时间、编号、商户名”这类结构化字段？
识别失败时，用户是重新拍照，还是手动修正？

我后来越来越觉得，OCR 真正有价值的地方，不是“把字认出来”，而是把原始图片转成业务可消费的数据结果。

所以这次我没有把重点放在单纯的“识别文本”，而是拆成了四段：

图片输入：相册、拍照或已有文档；
文本块定位：先知道识别到了哪些区域；
结果结构化：把原始识别结果转成业务字段；
结果验证与导出：让用户能看清、复制、导出和复核。

二、页面设计先别花，先让链路跑顺

我做这种能力型页面时，一般不会一上来就做得很复杂。

因为 OCR 这种需求的难点，不在于卡片圆角或者配色，而在于链路是不是完整。所以首页我会先只保留最必要的几个区域：

原始图片预览；
识别入口；
识别状态；
结构化结果展示；
导出或复制操作。

先让链路闭合，后面再谈体验优化。

真正跑起来以后，页面最好能同时回答两个问题：

系统识别到了什么？
系统是从哪里识别出来的？

这也是为什么我后面特意保留了“原图识别区域”和“结构化字段结果”两个视角。因为很多 OCR 页面只展示最终文本，却不告诉用户这些内容是从哪块图上取出来的，一旦结果不对，用户根本不知道该怎么判断。

三、第一步不是显示结果，而是把 OCR 服务初始化稳定

很多人把 OCR 逻辑全塞进按钮点击里，我不太建议这样写。

因为 OCR 服务初始化、模型状态检查、权限和异常处理，最好在页面进入时就先准备好。这样到了真正识别那一刻，链路才不会太仓促。

我这次的处理方式，是在页面出现时先初始化 OCR 服务：

import { OcrService } from '../service/OcrService'
import { promptAction } from '@kit.ArkUI'

aboutToAppear() {
  OcrService.getInstance().init().then(() => {
    console.info('OCR 服务初始化完成')
  }).catch((err: Error) => {
    console.error('OCR 服务初始化失败: ' + err.message)
    promptAction.showToast({ message: 'OCR服务初始化失败' })
  })
}

这段代码不复杂，但它有两个好处：

识别之前，先把能力准备好；
初始化失败时，问题暴露得足够早。

这种处理特别重要。因为 OCR 这类能力一旦失败，读者看到的通常只是“没结果”，但真正的问题可能出在模型没加载、服务没准备好、资源初始化异常等更前面的阶段。

这张 DevEco 图里，我保留了几处红色标注，目的很明确：

初始化 OCR 服务；
发起识别调用；
解析识别结果；
查看日志中的文本块与置信度。

这种标法非常适合技术文章，因为它不是单纯展示界面，而是在帮读者快速建立“代码 → 模拟器 → 日志”之间的对应关系。

四、真正的核心不是文本字符串，而是文本块

OCR 如果只返回一整段文字，当然也有价值，但工程价值有限。

因为只要业务稍微复杂一点，你就会发现真正要用的是：

文本内容；
文本块位置；
文本置信度；
文本之间的结构关系。

所以我在识别完成后，没有直接把结果拼成一整段字符串，而是先保留文本块数组：

async recognize() {
  if (!this.imagePath) {
    promptAction.showToast({ message: '请先选择图片' })
    return
  }
  this.isLoading = true
  try {
    const ocrResult = await OcrService.getInstance().recognize(this.imagePath)
    this.textBlocks = TextBlockParser.parse(ocrResult)
    this.resultText = TextBlockParser.toText(this.textBlocks)
    console.info(`识别完成，共 ${this.textBlocks.length} 个文本块`)
  } finally {
    this.isLoading = false
  }
}

这一步很关键。

因为一旦你有了 textBlocks，后面的很多事情才有抓手：

在图片上画识别框；
判断哪些字段更像金额、日期、编号；
对低置信度文本做单独标记；
支持点击某块文本进行修正。

也就是说，OCR 的中间态决定了这个能力后面能不能继续长。

五、结构化提取，才是业务真正想要的结果

对于票据、发票、身份证这类场景，业务方通常不想要“一大段文本”，而是直接要字段。

比如一张消费票据，常见目标字段至少包括：

商户名称；
日期时间；
金额；
票据编号；
支付方式；
交易流水号。

所以我后来加了一层简单的结构化解析，把识别结果按规则映射成字段。

export class TextBlockParser {
  static extractReceiptFields(blocks: OcrTextBlock[]): ReceiptFields {
    return {
      merchantName: this.findByPattern(blocks, /咖啡|公司|商户/),
      dateTime: this.findByPattern(blocks, /\d{4}-\d{2}-\d{2}/),
      amount: this.findByPattern(blocks, /¥?\d+\.\d{2}/),
      ticketNo: this.findByPattern(blocks, /\d{12,}/),
      payMethod: this.findByPattern(blocks, /微信支付|支付宝|银行卡/)
    }
  }
}

这段代码当然还不是完美的通用方案，但已经足够说明一个关键思路：