Word/PDF解析到结构化XML：三层管线与语义标签映射-北京尧图网络

做内容中台和知识库的朋友大概都碰过这个活手上一批 Word 交底文档、技术白皮书 PDF、还有一些扫描件要求统一转成结构化 XML喂给下游的检索、排版、归档系统。需求方一般只给一句话——“转成 XML”但真正落地的时候你会发现这句话背后藏着一整套工程问题什么算“高质量”Word 和 PDF 凭什么能用一套流程处理标题层级丢了怎么补跨页表格怎么接上我前后在三个不同规模的项目里干过这件事从最初直接调库一把梭到后来老老实实拆成三层管线踩的坑足够写一篇长文。这篇东西面向的是需要真正把文档转出可用 XML 的开发者、内容工程师和技术文档负责人不管你之前只写过几行python-docx还是已经在折腾版面分析模型下面的拆解应该都能对上你的场景。核心关键词就三个Word/PDF 解析、结构化 XML、语义标签映射。我不打算讲“XML 是什么”这种基础直接进入工程细节。1. 先把高质量 XML这件事定义清楚很多人一上来就问用什么库这个问题其实问早了。真正决定项目成败的是你对“高质量”的定义。我见过最典型的失败案例是脚本跑通了输出了几百个.xml文件用浏览器打开也不报错需求方验收的时候翻了两个文件就说不行。原因是转出来的东西长这样pstrong第一章概述/strong/p标题就是一段加粗的段落。文件是合法的 XML但下游拿不到任何结构信息目录生成不了锚点定位不了检索权重也没法按标题加权。这种活干完等于白干。1.1 结构质量从能打开到能机器消费XML 的质量其实有三个清晰的台阶我在项目里习惯把它们当作三个验收关卡。第一关是well-formed也就是标签闭合正确、属性加引号、有唯一根节点这关靠解析器就能保证基本不会有人栽在这里。第二关是valid能通过 XSD 或 DTD 校验元素名、层级、属性都符合你定义的词汇表这关开始有门槛了因为你需要先有一份 Schema而很多团队是先写转换代码、后补 Schema顺序反了就会反复返工。第三关是语义可消费这才是真正的分水岭——下游程序能不能只靠 XML 就还原出文档的逻辑骨架而完全不需要回看原始文件。举个具体的判断标准把转好的 XML 丢给一个完全没见过原文的人让他基于标签画出一份目录树和表格清单如果他能画对 90% 以上结构质量就过关了。这个测试方法比任何指标都直接我在两个项目里都用过非常好使。1.2 内容质量保真是有预算的必须接受一个现实转换不可能 100% 无损。Word 里的浮动文本框、艺术字、SmartArt、带旋转的图形组合这些东西在语义 XML 里几乎没有对应表达。硬要保真你就得把整页渲染成图片塞进去那还不如直接交付 PDF。我的做法是在项目启动阶段就跟需求方明确一张保真清单把内容分成三档。第一档是必须逐字无损的正文文字、数字、单位、上下标、公式符号、表格里的每一个单元格值这些错一个字符都是事故。第二档是允许结构近似的多栏排版可以拍平成单栏首字下沉可以退化成普通段落页眉页脚可以抽取成元数据而不进入正文流。第三档是允许丢弃的装饰性边框、底纹颜色、页码、水印。这张清单写进需求文档后面所有争议都有依据。提示保真清单必须由需求方签字确认尤其是页码是否保留这一条。页码看着无关紧要但如果下游要做引用定位缺了它会非常麻烦。1.3 语义质量标签体系别拍脑袋标签体系的设计有个很实际的取舍递归结构还是平铺结构。递归就是sectitle.../titlesec.../sec/sec靠嵌套表达层级平铺就是h1到h6一路排列靠标签名表达层级。递归结构更适合章节深度不确定的长文档XPath 查询也优雅平铺结构更适合深度固定、需要快速切片的内容比如一段一段喂给检索系统。我在一个技术手册项目里选了递归因为那批文档章节深度从两层到五层都有在另一个政策条文集的项目里选了平铺因为结构就是章-条-款三层固定死了平铺反而查询更快。选哪个不是技术问题是内容形态问题。判断方法很简单统计一下你所有源文档的标题层级分布如果第 4、5 级的出现频率低于 5%平铺加一个通用h带level属性就够用了。2. 整体链路与方案选型搞清楚质量定义之后才轮到架构。我最开始的做法是写一个大函数读文件、判断类型、分叉处理、直接拼 XML 字符串。这套东西在样本量小于 50 的时候勉强能用一旦上千份就彻底失控——因为你没有任何中间态可以检查出了问题只能靠肉眼比对原文和输出。2.1 三段式管线解析层 / 归一化层 / 序列化层后来我把流程拆成了三层这个改动是整个项目里收益最大的一次重构。解析层只负责一件事把 Word 或 PDF 变成统一的内存结构也就是中间表示IR不管源格式多恶心出口必须是干净的 Python 字典或对象。归一化层在 IR 上做清洗和修补字符规范化、标题层级补全、表格矩阵化、空段落剔除。序列化层把 IR 渲染成目标 XML做标签映射、属性填充、命名空间声明、缩进美化。拆开之后的好处立竿见影。调试的时候可以直接print(ir)看中间态问题定位从“猜哪一步坏了”变成“看 IR 对不对”。加新格式的时候比如后来要支持 Markdown只需要再写一个解析器后面两层完全复用。归一化规则调整的时候也不用再碰解析代码改动风险大幅降低。代价是代码量大概多了 40%多了一层数据结构定义。但考虑到你后面要反复调规则、加格式、修 bug这笔投入一两个月就能回本。2.2 Word 和 PDF 必须走两条完全不同的路这是新手最容易犯的错以为有个万能库能同时搞定两种格式。真相是Word 和 PDF 的信息密度差了一个数量级处理策略必须分开设计。维度Word.docxPDF内部结构完整的段落、样式、层级对象树只有绘图指令和字符坐标标题识别读样式名即可准确率接近 100%靠字号、字重、间距推断准确率 70%~90%表格识别有明确的表格对象和单元格边界靠线条检测或文本对齐推断阅读顺序文档流本身就是顺序必须重建多栏和浮动元素是灾难扫描件不存在这个概念需要 OCR误差叠加主要难点样式不规范、嵌套混乱版面复杂、字符编码异常看清这张表方案就明确了Word 走样式驱动的解析路线PDF 走几何驱动的解析路线。两者的 IR 出口统一但内部实现没有任何复用空间别在这上面浪费时间。2.3 目标词汇表怎么选自建还是用现成的这个决定影响后面所有的标签命名。我把常见的几个选项列出来对比词汇表适合场景优势局限DocBook技术文档、书籍元素丰富工具链成熟元素太多学习成本高容易用错TEI人文社科、古籍、校勘学术表达能力强通用业务场景显得笨重JATS学术期刊、论文元数据规范清晰面向期刊业务文档适配差自建最小集企业内部、检索入库完全贴合业务易维护需要自己写 Schema 和校验我的实际选择是自建最小集借鉴命名。核心元素控制在 15 个以内doc、meta、sec、title、p、list、item、table、row、cell、figure、formula、note、ref、code。这个集合覆盖了绝大多数业务文档新同事半小时就能记住。命名风格上参考 DocBook 的简短风格但只借名字不借复杂度。注意一旦词汇表定下来并开始产出数据改名的成本极高。定版前务必把未来两年可能的内容类型都过一遍尤其是公式、脚注、交叉引用这三类最容易在后期才发现没位置放。3. Word 侧实操从样式树里挖结构Word 这一侧的核心认知是.docx 本质上是个 zip 包里面是一堆 XML。你把后缀改成.zip解压会看到word/document.xml打开它你就能看到所有内容。这个认知很重要因为它意味着你完全可以绕开所有第三方库直接读原始 XML——当然一般没必要但遇到库不支持的特性时这是最后的退路。3.1 为什么不能直接用 Word 自带的另存为 XML有人会想Word 本身就能导出 XML为什么还要写代码因为 Word 导出的是 WordprocessingML标签长这样w:pw:pPrw:pStyle w:valHeading1//w:pPrw:rw:t第一章/w:t/w:r/w:p。这是排版描述语言不是语义标记。它告诉你这段用了 Heading1 样式、里面有个文本运行但你的下游系统要的是这是一个一级标题内容是第一章。中间那层映射还是得你自己做。更要命的是 WordprocessingML 的元素数量超过 200 个属性更多直接喂给业务系统谁看谁崩溃。所以正确做法是读 WordprocessingML映射成自己的最小词汇表输出语义 XML。别偷这个懒。3.2 工具取舍与骨架代码Python 生态里几个常见选择我按实际使用体验说一下。python-docx是最主流的API 友好段落、表格、样式都能直接访问缺点是它默认会做一些“友好化”处理比如自动合并相邻的相同格式 run有时候会吞掉你需要的信息。docx2python更偏内容抽取输出嵌套列表做纯文本导出很快但结构信息保留得不够细致。mammoth是 Node 生态的主打 docx 转 HTML思路很对强调语义映射Python 里有个mammoth包但功能弱一档。pandoc是万金油命令行一把梭能出很多格式缺点是它的 XML 输出受限于它自己的 AST你想要的自定义标签它不一定支持而且批量处理时启动开销不小。我的组合是python-docx 做主体解析遇到它搞不定的特性时直接 lxml 读原始 XML 兜底。骨架大概长这样from docx import Document from docx.table import Table from docx.text.paragraph import Paragraph def iter_block_items(parent): 按文档流顺序交替产出段落和表格这是关键 from docx.oxml.ns import qn parent_elm parent.element.body for child in parent_elm.iterchildren(): if child.tag qn(w:p): yield Paragraph(child, parent) elif child.tag qn(w:tbl): yield Table(child, parent)这段代码的价值在于顺序。很多人直接doc.paragraphs然后doc.tables分开遍历结果所有表格都被挪到文末位置信息全丢了。用iter_block_items才能保证段落和表格按照原文的先后顺序被处理这是能否还原正确阅读顺序的第一道关口。3.3 样式到标签的映射表怎么建拿到段落之后核心工作是判断它是什么。Word 里最可靠的信号是paragraph.style.name但这里有个大坑样式名会因语言版本而不同。同一份文档在英文版 Word 里叫Heading 1中文版里可能是标题 1还有些模板会自定义成1级标题、H1、章标题。如果你的映射表只写了一行Heading 1 - h1那中文文档全军覆没。我的做法是建一张 YAML 映射表用正则匹配优先级来兜底style_map: - pattern: ^(Heading|标题)\s*([1-6])$ tag: h{2} - pattern: ^(Title|标题)$ tag: h1 - pattern: ^(Subtitle|副标题)$ tag: p attrs: {role: subtitle} - pattern: ^(List Paragraph|列表段落)$ tag: item - pattern: ^(Caption|题注)$ tag: caption - pattern: ^(Quote|引用)$ tag: quote - pattern: .* tag: p最后那条通配规则很重要它是兜底用的。解析器按顺序匹配命中第一条就停所以具体规则一定要排在通配规则前面。这张表我建议单独放一个配置文件别硬编码在代码里因为不同客户、不同批次的文档样式命名差异极大改配置比改代码安全得多。除了样式名还有两个辅助信号可以用来纠错。一是字号如果某个段落样式是Normal但字号明显大于正文中位数很可能是个没套样式的标题我一般会把这种情况标记出来人工确认。二是编号段落文本以“一、”“一”“1.1”开头且字数少于 40 的大概率是标题可以作为交叉验证。3.4 表格、合并单元格、嵌套列表的处理Word 表格最麻烦的是gridSpan横向合并和vMerge纵向合并。python-docx 的cell.text在合并单元格上会重复返回同一份内容直接遍历会导致数据重复、列对齐全乱。正确的做法是先把表格还原成一个规整的二维矩阵再序列化。思路是先计算出总列数所有行的 gridSpan 之和的最大值然后逐行遍历遇到横向合并就在矩阵里占多个位置并记录colspan遇到纵向合并就沿用上一行的内容并记录rowspan。这个过程写起来大概七八十行代码但没有捷径。输出的时候合并信息放在属性里table idt1 cols4 row cell rowspan2 colspan1类别/cell cell colspan3指标说明/cell /row row cell上限/cell cell下限/cell cell单位/cell /row /table嵌套列表要单独说。Word 的多级列表不是靠样式表达的而是靠numPr里的numId和ilvl。ilvl就是层级从 0 开始。你需要读取paragraph._p.pPr.numPr.ilvl.val拿到层级然后用一个栈来维护当前列表的嵌套关系遇到同级就新开item遇到更深一级就嵌套list遇到更浅就出栈。这块逻辑不复杂但很容易写错建议用几个精心构造的测试文档反复验证尤其是“跳级”的情况从层级 0 直接到层级 2实际文档里真会出现。4. PDF 侧的实操版面分析加文本回填PDF 是完全不同的物种。它本质上是“如何在纸上画字”的指令集合每个字符带着自己的坐标、字体、字号、颜色被画到指定位置。文档的“结构”从头到尾都不存在你要做的是从几何信息里反推出结构。这个过程本质上是启发式的别指望 100% 准确目标是做到 90% 以上然后接受人工抽检。4.1 PDF 只有坐标先搞清楚你要抽什么打开一个 PDF 解析出来的词列表你会看到类似这样的东西{text: 第一章, x0: 72.0, x1: 108.5, top: 96.2, bottom: 114.8, size: 18.0}。页面上所有文字都变成了这样一个个带坐标的矩形框没有任何顺序保证。所以 PDF 侧的完整流程是先抽所有词再按坐标聚成行再按行聚成块再按字体特征分类最后按位置排序。每一步都有一堆参数要调下面逐个说。工具选择上pdfplumber适合抽词和表格坐标信息给得很细调试方便PyMuPDFfitz速度明显更快适合大批量处理但 API 的风格不太一样。我的常规组合是批量跑用 PyMuPDF 抽基础信息需要精细表格处理的时候降级到 pdfplumber 局部处理。速度差距实测在三到五倍文档量大时这个差距很致命。4.2 行与块的聚类容差怎么算把词聚成行靠的是纵坐标重叠。这里的关键参数是行容差我一开始拍了个 2 像素结果大部分文档都正常遇到几份字号混排的文档就崩了。后来改成动态计算sizes [w[size] for w in words if w[size] 0] median_size statistics.median(sizes) line_tol median_size * 0.5 # 行容差半个中位字号 col_gap median_size * 1.5 # 断行阈值1.5 倍字号以上的横向空隙为什么是 0.5 倍因为同一行内不同字号的字符垂直中心最多偏移半个字号超过这个量级基本就是两行了。为什么断行阈值用 1.5 倍因为正常词间距大约在 0.25 到 0.5 个字号之间而栏间距通常是 2 个字号以上1.5 是个偏保守的安全值宁可少断也不要错断——断错了会把一行拆成两段反而更难修。聚成行之后再按行距把行聚成块。段落之间的行距一般会大于段内行距我用的判据是gap median_line_gap * 1.4就认为是段落边界。这个 1.4 的系数同样是通过观察几十份文档的行距分布定下来的不是拍脑袋。4.3 用字号直方图定标题层级标题识别的核心假设是标题的字号大于正文。做法是先统计全文档的字号频次取出现次数最多的那个字号作为正文字号基准这个统计方法很稳因为正文永远占大头然后把明显大于基准的字号按大小排序映射到 h1 到 h6。有几个细节能显著提升准确率。第一加个字符数过滤一个字号很大的块如果字符数超过 40大概率是封面大标题或者引文不该进正文层级真正的小标题通常很短。第二考虑字重有些文档的标题字号和正文一样只是加粗这时候要把fontname里的Bold特征也纳入判断。第三位置加权靠近页面上部、且前面有较大空白间隙的块是标题的概率更高。这三条规则叠起来我在几批技术文档上测的标题识别准确率从七成提到了九成左右。from collections import Counter sizes Counter(round(w[size]) for w in all_words) body_size sizes.most_common(1)[0][0] # 正文基准字号 head_sizes sorted({s for s in sizes if s body_size * 1.15}, reverseTrue) size_to_level {s: fh{i1} for i, s in enumerate(head_sizes[:6])}1.15这个系数是经验值低于它会误判有些文档正文和标题只差一个磅值高于 1.3 会漏判小标题。另外记得给size_to_level做个兜底如果head_sizes超过 6 个多出来的全部映射到 h6别让层级溢出。4.4 阅读顺序重建PDF 转换最大的坑多栏排版是 PDF 转换的重灾区。一个双栏页面如果按坐标简单从上到下排你会得到“左栏第一行、右栏第一行、左栏第二行、右栏第二行”这种交错的结果完全没法读。我的处理顺序是先检测栏数再按栏分块最后栏内排序、栏间拼接。检测栏数的办法是画一条横向投影线把页面上所有文本块的 x 区间累加成一个数组找那些“所有块都不覆盖”的 x 区间这些空白带就是栏分隔线。如果找到 1 条贯穿全页的空白带就是双栏2 条就是三栏。页眉页脚要单独处理。判据是两个一是位置出现在页面上边缘 8% 或下边缘 8% 区域内的二是重复在多页的相同位置出现相似内容的。命中的块直接抽到meta里不进入正文流。这个处理一定要做否则每个页面的页码和文件标题都会混进正文噪音极大。跨页表格和跨页段落也是常见问题。段落好办比较上一页最后一个块和下一页第一个块的行距特征接近就合并。表格麻烦些我的做法是如果上一页最后一个表格没有闭合边框底边线缺失且下一页开头是个没有表头的表格就尝试合并。这个启发式规则准确率大概七八成剩下的靠人工抽检标记。4.5 扫描件OCR 加版面检测的组合拳扫描件是另一个量级的问题。整页就是一张图没有文字层必须先 OCR。预处理这一步千万别省转灰度、二值化、去噪、纠偏四步做完再送 OCR识别率能差出十几个百分点。分辨率上300 dpi 是个比较稳的起点低于 200 dpi 小字号基本废掉高于 400 dpi 收益递减但耗时线性增长。版面检测现在有现成的模型可用输出的是区域框加类别文字、标题、表格、图片。拿到区域框之后流程就跟文字版 PDF 接上了按区域坐标排序、区域内做 OCR、按类别映射到不同标签。这里有个容易忽略的点——OCR 结果是按行返回的但表格区域里的行可能是跨单元格的得先用线条检测把表格结构拿出来再把每个单元格区域单独送 OCR最后拼装。直接整块 OCR 会把表格拍成一堆错位的文本行。5. 归一化层把脏数据洗成可校验的树前面两层跑完你手上大概是一棵还算像样的 IR 树但里面一定有一堆脏东西。归一化层的工作就是把它们清理掉让序列化层可以不加判断地直接渲染。5.1 中间表示长什么样IR 我用的是嵌套字典结构大概这样{ type: doc, meta: {title: ..., source: a.docx, pages: 12}, children: [ {type: h1, text: 第一章概述, id: sec-1}, {type: p, text: 正文内容……, style: body}, {type: table, cols: 3, rows: [ [{text: 类别, rowspan: 1, colspan: 1}, ...] ]} ] }这个结构的核心是扁平的 children 列表显式的 type 字段。为什么不直接做成递归的sec嵌套因为 Word 的标题层级经常跳级从 h1 直接到 h3扁平结构允许你先收集再修补等层级补全之后在序列化阶段再决定要不要包成嵌套的sec。这个“先扁平后嵌套”的策略救过我好几次。5.2 字符清洗那些看不见的坑字符层面的问题看着琐碎但每一个都能让下游的检索和比对出错。我整理了一份必做的清洗清单问题类型具体表现处理方式全角半角混用数字、括号、冒号全角数字和标点统一转半角中文标点保留连字字符PDF 抽出的 ﬁ、ﬂ、ﬀ展开成 fi、fl、ff软连字符行末断词留下的 0xAD直接删除并拼接前后词不间断空格0xA0视觉上和空格一样转成普通空格零宽字符0x200B肉眼不可见全部删除中英文间距PDF 抽取后中英文间无空格按规则补入或保持需统一策略重复空格排版对齐留下的连续空格压缩为单个段落断词PDF 行末连字符跨行断开检测行末连字符与下一行首拼接这张表我建议直接做成一个clean_text()函数所有文本入口都过一遍。别嫌麻烦我曾经因为没处理软连字符导致同一个术语在检索系统里出现了七种不同拼法排查了半天才发现问题出在 PDF 的断词上。5.3 Schema 校验和流水线卡口XML 生成完不校验等于没做完。XSD 写起来不难关键是别写得太严。我第一版 XSD 把每个元素的属性都限制死了结果任何一点异常都会导致整批文件校验失败最后只能把校验关掉。后来改成分层校验必填元素和结构层级严格校验可选属性和文本内容宽松处理校验失败的文件单独落到一个quarantine目录不阻断整批流程。from lxml import etree def validate(xml_path, xsd_path): schema etree.XMLSchema(etree.parse(xsd_path)) doc etree.parse(xml_path) if not schema.validate(doc): errors [f{e.line}: {e.message} for e in schema.error_log] return False, errors return True, []校验放在 CI 里跑更有价值。每次转换规则改动跑一遍回归样本集看校验通过率和结构指标有没有退化。这套东西建立起来之后改规则的胆子会大很多因为你知道有网兜着。6. 质量评估与常见问题排查转换质量不能靠感觉得有指标。我用的三个核心指标是字符级召回率、块级结构 F1、表格单元格准确率。第一个衡量文字有没有丢第二个衡量结构对不对第三个单独盯表格这个最大的风险点。6.1 指标怎么算字符级召回最简单把源文档的纯文本和输出 XML 的纯文本都做规范化去空白、统一标点然后算1 - edit_distance / len(source)。这个指标低于 0.98 就要查原因了通常是 OCR 错误或者表格内容丢失。块级结构 F1 需要人工标注一批样本标出每个块的类型标题/段落/表格然后跟输出比对算精确率和召回率。这个成本高但样本量不用太大两三百个块就能看出问题。我在项目里标了 500 个块每次规则大改后重跑能及时发现“修复了一个问题、引入了两个新问题”的情况。表格单元格准确率单独算因为它是加权最高的部分。做法是人工核对表格里的值错一格算一个错误。我给自己定的目标是 99%实际在文字版 PDF 上能做到 99.5% 左右扫描件大概 97%。6.2 常见问题速查表下面这张表是我这些年攒下来的问题清单基本都是高频出现的现象大概率原因排查方向输出 XML 为空或极少解析器读到了空文档或者样式匹配全落到兜底规则打印 IR 中间态看 children 长度标题层级全是一级字号聚类只识别出一个层级或样式名全一致检查字号直方图分布表格内容重复合并单元格未做矩阵化直接被遍历检查 gridSpan/vMerge 处理逻辑中文变乱码或方框PDF 字体缺少 ToUnicode 映射换解析库试试或降级 OCR阅读顺序错乱多栏排版未检测或绝对定位元素干扰打印坐标检查栏分隔检测段落被拆成多段行距聚类阈值过小调大 gap 系数从 1.4 试到 1.8段落被合并成一段行距阈值过大或首行缩进未识别检查首行缩进特征是否被忽略校验批量失败XSD 过严或必填属性缺失分层校验先过结构再管属性处理速度极慢逐页调用重量级解析未做批处理换 PyMuPDF或分页并行6.3 几条踩坑换来的经验别用“一个脚本通吃”。我试过写一个自动判断格式、自动选择策略的万能入口结果发现 Word 和 PDF 的参数没有一个能共用最终那个函数变成了一个巨大的 if-else 分支可读性极差。老老实实写两个模块各自调优比什么都强。样本集比代码重要。项目初期我花了两周时间收集和标注 200 份有代表性的文档包括正常文档、复杂表格、多栏排版、扫描件、带公式的、带脚注的。后面每次改规则都拿这批样本回归。没有这个样本集所有的“优化”都是盲改。人工抽检不能省。自动化指标能发现大问题但发现不了“标题识别对了、但层级映射反了”这种逻辑错误。我一般每批抽 20 份手工看一遍目录结构二十分钟的事能拦住很多低级错误。字体信息不要丢。PDF 解析的时候顺手把字体名和字重记下来分类的时候用得上。有些文档标题不加粗不放大全靠字体区分比如正文用宋体、标题用黑体这个信号在中文文档里非常常见别浪费。先跑通再优化。我最开始总想着一步做到完美结果卡在表格合并的逻辑上两周没进展。后来改成先输出能用的版本表格拍平成段落让下游先接上再回头做表格结构化整个项目节奏才顺过来。给 id 加稳定规则。每个sec和table都要有 id方便下游引用。id 的生成别用随机数用“章节路径哈希”或者“序号标题 slug”保证同一份文档重复转换时 id 一致不然下游的增量更新会疯掉。6.4 一个容易被忽略的收尾动作转换完别急着交付最后一步做反向验证写个小脚本读你的 XML按标签重新渲染成纯文本或 HTML然后跟原始文档做并排对比。这一步能暴露出很多“格式正确但内容错位”的问题比如表格的行列转置了、列表项丢失了、脚注挂错了位置。我现在的标准流程里这一步和 Schema 校验是绑定的缺一不可。另外输出 XML 的可读性也别忽视。加个缩进美化器按层级缩进两个空格长文本行做适当换行。这东西不影响程序解析但会极大影响人工 review 的效率——毕竟你总要有人去看的一堆挤在一行里的 XML 谁看谁头疼。最后一个我自己的习惯每批转换任务留一份原始文档到输出的映射日志记录每份文件走了哪条分支、命中了哪些规则、耗时多少、有没有告警。出问题的时候按日志往回查比重新跑一遍快得多。这个日志我一般用 JSONL 存一份文件一行方便 grep。

Word/PDF解析到结构化XML：三层管线与语义标签映射

相关推荐

大语言模型的失效边界与推理坍缩现象解析

BQ40Z50中文手册：BMS保护、PF永久失效与阻抗跟踪调试

多租户酒店订房系统架构设计与高并发优化实践

更多资讯

训练到部署：Model-Optimizer打通深度学习模型优化全流程

一周8k+用户：高性价比人生指南衍生站的内容结构化与静态生成实践

静态站+客户端检索：5天打造高转化轻量工具站实战

AI工程从零开始：理论学习、实战项目与部署落地的完整指南

GBase 8a数据库智能运维管理系统GDOM实战解析

C++冒泡排序原理、优化与实战应用

今日更新

淘宝商品详情API开发实战与性能优化指南

Unity Package Manager刷新错误排查与解决方案

Java record 规范构造器能否被反序列化或反射绕过

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？