表中表：嵌套表格解析为什么是文档理解最难啃的骨头之一
一、一张业务申请表里的解析盲区
你接入了某个文档解析服务，处理一批扫描的业务申请表。表格主体看起来规整——账户名称、账号等，各占一行。但在各项“金额”栏里，旁边还嵌着一个小表格，分别列出“万、仟、佰、拾、元、角、分”对应的大写汉字金额。
.jpg "image")
解析结果拿到后，主表格的行列都对，文字也没少。但金额小表中，大写数字被拍平成几行散落的文本，和主表格混在一起。你无法判断它们分别对应的是哪一笔申请，也不知道它和下面的小写数字是什么关系。
表格结构识别错误
这不是文字识别出错，而是表格结构识别的问题——具体来说，是嵌套表格的解析失败了。本文聚焦这一特定类型，拆解它的难点、场景和解决思路。
二、什么是嵌套表格
嵌套表格（Nested Table），指的是在表格的某个单元格内部，存在另一个具有独立行列结构的子表格。它和“相邻的两张表”“跨页表”本质不同——关键在父子隶属关系。
这种结构在真实业务文档里并不少见，常见形式包括：
一对多明细：客户信息表里，每个客户名下挂一段订单明细。这是最高频的一类。 金额分项表：业务申请表、报销单、发票中，总金额旁嵌着大小写对照、币种拆分、费用类目明细等子表。 条款内的计划表：合同条款中嵌入付款计划（付款阶段、条件、金额），一一列出。 分类下的子项：财务报表中，某个科目单元格内展开子科目明细。
对于下游系统来说，嵌套表格的数据价值不在“被识别出来”，而在父子关系被准确保留。子表一旦被拍平，和主表的关联就断了——对下游而言，这张表等于白解析了。
子表格隶属关系
三、为什么嵌套表格难以被解析工具“看懂”？
嵌套表格不是单一技术点的挑战，而是对解析系统数据模型、输出架构和版面理解能力的综合考验。核心难点有三个。
根因一：二维网格模型装不下树形结构
大多数表格解析工具的底层假设是“一张表格 = 一个M×N矩阵”，每个单元格由行列索引唯一确定。这个模型在处理规整表格时高效，但嵌套表格本质上是一个树形结构——一个单元格的内部不是“一个值”，而是“一张子表”。用网格去套树，子表信息必然被丢弃或拍平。
解析失败后是什么情况？如上面的Bad Case图例所示，解析结果中，主表的行列依然规整，但子表的内容变成了主表中凭空多出的几行，和主表信息混在同一层级。你分不清这些大写数字属于哪一行的金额字段——主表结构看起来完整，但子表数据已经“溶”进了主表里，父子关系彻底消失。
根因二：输出schema不支持嵌套
主流文档解析的输出格式，比如Markdown或扁平JSON数组，在设计时并没有考虑“单元格内容可能是另一张表”这种情况。即便识别环节在内部检测到了嵌套关系，最终输出时也会因为schema不支持而被强制扁平化。解析器其实“看见了”，但它“输不出”。
解析失败后是什么情况？即使解析系统在内部处理时识别出了嵌套结构，最终输出的JSON里，子表依然被展开成一串扁平对象。原本应该是这样的嵌套结构：
{
"客户": "A公司",
"订单明细": [
{ "订单号": "001", "金额": 5000 },
{ "订单号": "002", "金额": 3000 }
]
}
实际拿到的却是三条平铺的记录：
{ "客户": "A公司" }
{ "订单号": "001", "金额": 5000 }
{ "订单号": "002", "金额": 3000 }
下游系统拿到后，根本没法判断后两条订单属于谁。
根因三：版面边界模糊
嵌套表格的子表通常没有完整边框，只靠缩进、字号变化或轻微的分隔线与外层区分。人眼能根据上下文判断边界，但算法容易把子表的行当作主表的新行，或者把子表内容和外层单元格的相邻文本混在一起。边界识别错误是嵌套表格最常见的失败模式。
解析失败后是什么情况？子表的第一行被正确归入外层单元格，但第二行起因为缩进偏移或分隔线缺失，被误判为一张独立的新表。原本属于同一个父单元格的子表被拆成了两块——一块留在原位，一块变成了“孤儿表”。下游看到的是一张和原始上下文完全断开关系的表格碎片。
四、嵌套表格数据丢失，下游会发生什么
回到开头的业务申请表。如果那张金额子表在解析中丢失或拍平，下游系统会发生什么？这不仅仅是“少了几行数据”的问题，而是一连串连锁反应。
ETL / 数据入库：金额字段写入错误
业务申请表中的大小写金额子表，本质上是同一笔金额的结构化表达——小写数字用于计算，大写汉字用于合规校验。解析时如果子表丢失或拍平，小写金额和大写金额的对应关系就断了。入库后可能出现大写金额挂错申请记录、大小写金额不一致却无法校验、甚至金额子表中的“角、分”被写入了其他字段的情况。对于一个日均处理上万份申请的系统来说，这类错误不是偶发 bug，而是系统性脏数据。
RAG / 文档问答：金额查询答非所问
用户问“这笔申请的大写金额是多少”，RAG 系统检索到了子表中的汉字金额。但父子关系断裂后，模型无法判断“捌仟元整”对应的是哪一笔申请记录。返回的答案可能是另一笔申请的金额——数字本身没错，但对应关系是错的。在金融、财务、审计这类场景里，“看起来很对”比“找不到答案”更危险。
合同 / 采购审核：付款金额漏审
合同中的付款计划往往以嵌套表格形式出现——每一笔付款的金额、条件、时间节点依次列出。如果金额子表被拍平，审核系统可能漏掉对某一笔付款金额的校验。比如分三期付款、每期金额不同的条款，解析后变成了孤立的几个数字，审核规则根本无法匹配到对应阶段。
Agent 自动化：金额驱动的任务链路中断
Agent需要“读取每笔申请的金额→根据金额大小分流审批→对大额申请触发补充材料流程”这样的层级操作。嵌套关系丢失后，Agent 无法将大写金额、小写金额和申请记录一一绑定。后续的金额判断、规则匹配、审批流转全部无法执行——不是某一环出错，而是整个金额驱动的自动化流程中断。
五、解决嵌套表难题，要做对哪些事
TextIn xParse在嵌套表格上实际给出了什么样的结果？我们来看三个关键点。
第一，输出结果保留嵌套结构
xParse的输出中，当一个单元格包含子表时，该单元格的值不是字符串，而是一个完整的子表对象——有自己的行列结构、表头和内容。开发者拿到结果后，可以直接遍历父行，再从父行中获取子表数据进行二次遍历，不需要从扁平数据中反向推断归属关系。
第二，子表边界被准确识别
从输出结果来看，子表的内容被完整保留在所属单元格内，不会溢出到主表的其他行列中。无论是通过缩进对齐的无线框子表，还是字号缩小以示区分的嵌套明细，最终输出中子表和外层单元格的隶属关系明确，不会出现“半个子表在外、半个在内”的情况。业务申请表里的“万、仟、佰、拾、元、角、分”金额子表，会被完整保留在对应的金额字段下。
第三，父子映射自动建立
输出的JSON结构中，子表记录的路径天然包含父行信息。开发者不需要通过行号推算或关键词匹配来重建主从关系。拿到结果后可以直接消费——ETL 写入主表和从表、Agent 做层级遍历、RAG 做上下文关联，都不需要额外写后处理逻辑。
六、用你的嵌套表格来测一次
嵌套表格的解析效果，用同一张表对比不同方案，差异立现。
带上你的样本去测试时，可以使用三个检查维度：结构对不对（子表是否被保留，还是被拍平？）、关系对不对（父子映射是否准确建立？）、内容对不对（子表内的数字、单位、大写汉字是否完整？）。这三个维度在嵌套表格场景下同样适用，而且通常只需扫一眼输出结构就能判断前两层。
xParse Playground支持你上传一张带嵌套表格的真实PDF或图片，同时看到不同方案的输出结果。
嵌套表格不是边缘场景，而是文档理解进入生产环境的必答题。带上你手头那份带金额子表的业务申请表、那份内嵌订单明细的客户清单、那份包含付款计划的合同附件，来真实测一次。
