坐标数据的本质：四点框不是装饰

通用OCR对每张图返回若干文本行，每行带一个四边形——通常是左上、右上、右下、左下四个点的像素坐标，以及一个置信度。四边形之所以是四点而非矩形，是因为它要表达倾斜、透视变形、弯曲排版。但工程上常把它近似成包围盒：取四个点中最小的横纵坐标作为左上角，最大的横纵坐标作为右下角，得到左上角坐标与宽高。

这个包围盒有两个核心用途。其一是还原阅读顺序——按左上角纵坐标从小到大排得到“从上到下”，同纵坐标带内按横坐标从小到大排得到“从左到右”，这是中文单据最自然的阅读顺序。其二是还原字段关系——同一行的文字纵坐标重叠度高，同一列的控件横坐标重叠度高，靠这两个重叠度可以把“字段名”和“值”在几何上绑回来，而不依赖文字里是否恰好出现冒号。

忽略坐标只取文字，等于把OCR从“带位置感知的识别”降级成“乱序摘字”，后面所有结构化努力都在补这个窟窿。

行聚类：先把文字排回人类看到的行

OCR模型输出文本行的顺序通常不保证阅读顺序，尤其在多列排版、倾斜扫描、图文混排时，可能先出右下角的时间戳再出左上角的抬头。后处理第一步必须重排。

做法是对所有文本行计算包围盒的中心纵坐标（或左上角纵坐标），设定一个行容差——比如行高的六成到八成。中心纵坐标差小于行容差的归为同一行，跨过容差的切到下一行。归行后，行内按中心横坐标升序排，得到“先抬头后正文再落款”的自然顺序。

行聚类里最经典的坑是行高估计错。单据抬头字号大、正文字号小，若用固定像素容差，大字号行会被切成两行。稳健做法是先统计所有文本行高度的中位数作为基准行高，容差取基准行高的一定比例，对明显偏高的行（如标题）单独放宽容差或允许跨行合并。倾斜图片要先做旋转矫正，否则同一行文字的纵坐标会从左到右漂移，纯靠纵坐标聚类会把一行拆成三行。

列切分与字段名值配对：用位置代替冒号

归行之后，单行内往往仍是“字段名 值”的结构，比如“价税合计 壹仟贰佰元整”或“数量 3 单价 400.00”。如果靠正则找“合计”二字再向右截取值，遇到字段名缺字、值前有空格、竖线分隔时就会失手。

坐标法更稳：在单行内，把文本块按横坐标切分。连续文本块之间若横坐标间隙大于字宽阈值，视为字段边界。边界左侧的块拼成字段名，右侧的块拼成值。更进一步的做法是跨行做列对齐——把多行里横坐标重叠的块归为一列，列首行通常是字段名（“金额”“数量”“单价”），其下列里出现的数值就是该字段的值。这种方法不依赖任何关键词，对发票、盘点单、报关单这类版式固定但前缀常变形的单据特别有效。

列对齐还能处理多列表格。表头文字的横坐标决定了每列的横范围，数据行里每个文本块的横坐标落进哪个范围，就属于哪列。通用OCR不返回表格结构，但坐标能让你自己把表“画”出来——这是官网那句“返回文本行坐标信息”的真正分量。

置信度与坐标联合过滤：低置信度别急着转数值

每个文本行都带置信度。印刷体清晰场景下置信度常很高，但盖章压字、底色花纹、低分辨率扫描会让数字位置信度掉下来。单行过滤规则是：整行置信度低于阈值的，挂起交人工；行内单个数字块置信度低但同行其他块高，优先怀疑该数字块，转数值时标低置信标记。

坐标在这里辅助判断“这块是不是被盖住了”。如果某个数字块的包围盒与旁边印章文字的包围盒大面积重叠，即使置信度中等，也应降级处理。单纯信置信度会放过“盖在章上但模型硬猜对”的偶然正确，也误杀“清晰但字体生僻导致模型犹豫”的正常值；把重叠面积作为第二特征，过滤更贴近人工判断。

文本转数字的绑定：坐标把值送到对的字段里

前面几步产出的是“字段名—原始值串”的配对，比如“价税合计—1,200.00”“数量—3”“日期—2025年04月15日”。文本转数值的最后一步，是把这些原始值串清洗成程序类型，并绑到业务语义上。

绑定靠两层：一层是字段名语义映射（“价税合计”“金额合计”“总计”都映射到订单金额），一层是坐标亲缘性——同一行右侧的值归左侧的字段名，跨行同列的值归表头同列字段。只做字段名映射不做坐标绑定，会把“运费 50”误绑到“商品单价”；只做坐标绑定不做字段名映射，遇到字段名缺字时就不知道这列是什么。两者叠加，批量单据里才能稳定抽出金额、数量、税率、日期。

数值清洗本身不外乎去货币符、去千分位、全半角统一、中文大写走专用映射、日期按格式解析。但要把清洗结果写进哪张表的哪个字段，决定权在坐标聚类给出的“这是价税合计行”这个结论上，而不是在正则匹配“1,200.00”这个串上。后者在备注里出现“找零1,200.00”时会翻车，前者不会。

复杂版式下的模板兜底：坐标聚类为主，模板为辅

纯坐标聚类能解决大部分规整印刷体，但遇到两种特殊情况会吃力。其一是完全无固定版式的截图（如网页长图），行列逻辑弱，聚类只能做到“大致分段”。其二是版式高度固定但偶尔偏移的票据（如增值税专用票），坐标聚类够用但容错不如直接框选区域稳。

工程上常把两者结合：默认走坐标聚类通用解析；对已知版式（发票、营业执照、盘点单）维护一个轻量模板，模板里记录关键字段的预期坐标比例（如价税合计中心点位于图宽七成、图高八成附近）。解析时先按坐标聚类出候选，再用模板区域做空间校验——候选落进模板区域才采信，落在外面的即使文字像金额也降权。模板不需要像素级精确，给一个比例矩形就行，适配扫描缩放。

模板兜底的另一作用是跨页对齐。多页单据里同一字段在不同页的坐标比例一致，靠模板能把“第二页的合计”和“第一页的合计”识别为同一语义字段的不同实例，而不是两个陌生串。

排障视角：结构化解析错了先查哪层

解析结果乱了，按链路倒推。

文字本身就错（把“0”识成“O”）——这是OCR引擎层问题，靠图片预处理（二值化、放大、去噪）和置信度过滤缓解，后处理修不了根。

文字对但行序乱——行聚类容差或行高基准算错，或图片倾斜未矫正，查预处理和聚类参数。

行对但字段名值绑反——列切分间隙阈值不合理，或同行情文字块间空隙被误判为字段边界，调横坐标间隙阈值。

字段绑对但数值转错——清洗规则漏了某种格式（如法式分隔、中文大写带“整”字），补映射表，不是坐标问题。

数值对但写进错的表字段——字段名语义映射冲突，或坐标亲缘性在跨行时断链，查行聚类和列对齐的连贯性。

监控上把“OCR文字错误率”“行聚类翻转率”“字段绑定命中率”“转数值失败率”拆开，能直接定位是哪一层在漏水。

结语

天翼云通用OCR给的“文字内容及文本行坐标信息”，真正的价值不在文字那半句，而在坐标那半句。没有坐标，文本转数字只能拿正则去猜哪段是金额；有了四点坐标，文本行能重排成阅读顺序、能切出列、能把“价税合计”和“1,200.00”在几何上绑成一对，中文大写和阿拉伯数字才有了安静落进数据库字段的路。开发工程师做坐标结构化解析，核心不是发明多聪明的算法，而是把行聚类、列对齐、置信度联合过滤、模板兜底这四件事按顺序钉牢，让坐标从“返回字段里的一个数组”变成“版面理解的眼睛”。官网文档不会替你写后处理，但会把坐标交到你手里——接下来是把图还原成人眼看到的表，还是把图压扁成一段乱序字符串，区别就在这层解析里。