发票自动识别：XML、PDF与OFD文件的解析实战指南

做发票自动识别的需求，这几年基本是财务和行政岗绕不开的硬骨头。尤其是数电票全面铺开之后，手里攒下三种格式——xml、pdf、ofd，格式不同、内容结构不同、打开方式也不同，人工一份份录入台账简直是拿命在堆工作量。我自己因为帮几个朋友公司做过报销系统的数据接入，前后在Windows环境里倒腾过好几版发票识别工具，踩了不少坑，所以这篇直接把我最终沉淀下来的那套方案、代码思路和排查经验整理出来，给做同类型需求的朋友参考。

先说这个工具是干嘛的：它跑在Windows上，输入一个xml、pdf或者ofd格式的电子发票文件，输出一份结构化的结果，包括发票号码、开票日期、销售方、购买方、金额、税额、价税合计这些关键字段。可以单文件处理，也能批量丢进一个文件夹扫描。适合财务人员、报销系统开发者、以及所有需要把纸质化和电子化发票数据整理进台账的人。

1. 为什么是这三种格式：发票电子化的文件形态

抛开具体政策不谈，光从文件格式的技术角度，就能理解为什么电子发票最终会收敛到xml、pdf、ofd这三类：它们分别对应了“数据层”“展示层”和“版式层”三种完全不同的诉求。

1.1 XML：数电票的底层数据载体

XML在发票场景里扮演的是“数据母本”的角色。早期电子发票的交付文件就是xml，它把发票的每一个业务字段用标签语义化地标记出来，比如发票代码、发票号码、开票日期、含税金额、税额、商品明细等。因为XML本身就是树状结构，又天然适合描述这种“发票头-商品行-汇总”的关系模型，所以它在税务系统内部一直是数据交换的标准形态。

对开发者和使用者来说，XML的价值在于“字段可读”。你不需要OCR，不需要图像识别，只要把XML解析出来，按标签取值，所有关键信息就齐了。这也是为什么说“有XML就最好办”，因为它是所有格式里唯一一个信息零损耗、零失真、完全结构化的。

1.2 PDF：最普适的查看与打印形态

PDF大家都太熟了，它的定位是“版式固定、跨平台不变样”。电子发票提供PDF格式，主要是为了让人能直接打印、预览、存证，原始凭证的展示形态跟纸质发票完全一致。但PDF有个麻烦：它虽然包含了文字信息，但这些文字是排版在页面坐标上的，没有“发票号码”“价税合计”这种语义标签。你想从PDF里把字段摘出来，本质上是在做“坐标文本挖掘”。

而且PDF还有两个变种：文字型PDF和扫描型PDF。前者嵌入的是文本字体，可以用文本提取工具直接读；后者其实是图片，必须先OCR。这也是发票识别工具里PDF处理最麻烦的地方。

1.3 OFD：国产版式文件标准与数电票实践

OFD，全称Open Fixed-layout Document，是我国自主制定的版式文件格式标准，国标GB/T 33190-2016。它的定位跟PDF几乎一模一样：固定版式、不可篡改、适合存储和打印。但它跟PDF有个本质区别：OFD内部采用XML来组织文档结构和页面内容，所以它在“版式展示”和“数据可读”之间找到了一个折中位置——既能像PDF一样还原发票原貌，又不像PDF那样把文字锁死在坐标里。

这一点在实际做识别的时候是加分项：OFD其实是个zip压缩包，解压后能看到一堆xml文件，发票信息就藏在Document/content.xml这类文件里，直接解析文本节点就能拿到字段，比PDF的坐标挖词舒服得多。

数电票推行之后，OFD格式成了电子发票原文件的标配交付格式之一。所以一个发票识别工具如果说不支持OFD，基本等于瞎了一半。

1.4 三种格式的关键差异对比

我从技术视角做个简化版对比，方便你理解为什么同一张发票三种格式，处理难度完全不同：

在动手设计工具之前，先把这三种格式的本质差异看清，后面写代码才不会走弯路。我见过有人一上来就对XML文件上OCR，纯属拿着高射炮打蚊子，又慢又容易错。

2. 识别方案的整体设计：结构化提取优先，OCR兜底

识别工具的核心原则，我总结成一句话：能走结构化解析的坚决不走OCR，只有无路可走时才引入图像识别。这个原则决定了工具的速度、准确率和开发成本。

2.1 识别路线的分水岭：有没有“底层的结构化数据”

一张电子发票放在你面前，第一步不是急着写解析代码，而是先判断：它内部有没有结构化的数据层？

XML不用说，天生就是结构化的。OFD虽然是版式文档，但它的内容层是XML，所以也算半个结构化。PDF最特殊，它分两种：如果是Word生成、系统开具的文字型PDF，内部有文本对象，可以提取；如果是扫描件、图片型PDF，那就只剩像素了，必须OCR。

这个分水岭直接决定了你的代码路径。我早期犯过一个错误，不管什么输入格式都统一走“递归找文本”的思路，结果OFD解包时直接读取文本倒是没问题，但PDF文字型输出经常缺字、乱序，后来才意识到是没区分PDF内部是否有文本层。

2.2 XML和OFD：解包、解析、字段映射

XML的处理逻辑非常直白：读取-解析-映射-输出。难点不在解析本身，而在字段映射。

数电票XML里的字段名是带有命名空间的，比如fpdm代表发票代码、fphm代表发票号码、kprq代表开票日期、je代表金额、se代表税额、jshj代表价税合计。这些缩写不查资料根本猜不出来，我第一次看到fpdm是真的懵。所以做XML解析前，一定要准备好一张“发票字段对照表”，把xml里所有你需要提取的标签名和它们的业务含义映射起来。

OFD的处理比XML多一步解包。OFD文件本体是个zip压缩包，先要解压。解压后常见的顶层结构包括：OFD.xml（文档根描述）、Doc_0/Document.xml（文档元数据）、Doc_0/Pages/Page_0/Content.xml（页面内容）、还有一些资源文件。发票字段主要分散在Document.xml和Content.xml的文本对象里。做个简单的字符串定位，或者用XPath去查TextObject节点，都能把发票号码、金额这些字段捞出来。

2.3 PDF：文字版提取 + 扫描版OCR降级

PDF的处理要分两级走。第一级尝试用文本提取工具（pdfplumber、PyMuPDF都可以）直接抽文字。抽出来的结果是一堆按坐标排布的字符串，你需要根据版面规律去定位字段。比如“发票号码”四个字在PDF左侧，它的值就在同一行偏右的位置；“价税合计（大写）”后面跟的金额在不同票面上位置可能略有浮动，但规律总体一致。

第二级是OCR降级。如果文本提取出来是空、乱码，或者提取出的页码没有文字层，那就说明是扫描件。这时候要调用OCR引擎跑一遍整张票面，再结合关键词定位提取字段。OCR这块我在Windows上实测过很多方案，国产引擎对中文发票的支持度普遍比通用引擎好用得多，识别的关键点不在引擎本身，而在前置图像处理和后置字段校验。

2.4 Windows平台的技术选型说明

Windows环境有个特点：Python生态最省事，但打包分发最头疼。我的选型组合是Python 3.10 + lxml + PyMuPDF + pdfplumber + RapidOCR，前端如果需要图形界面，可以用Tkinter或者PySide6，但如果只是批量处理，命令行足够用。

选Python不选C#/Java的原因很简单：文档处理类库太齐全了，lxml一把梭XML，PyMuPDF对PDF的兼容性也强，OCR更是有一堆现成的轮子。如果团队本身熟悉.NET也不是不行，但生态差距在发票识别这种小众场景里会越拉越大。Windows上打包用PyInstaller，可以把整个工具封成exe，丢给财务同事双击就能用。这里有个坑是OCR模型文件很大，打包时会撑爆体积，后面详细说。

3. 实操：在Windows上从零搭建可用的发票识别工具

下面进入完整实操环节。我不贴整份工程代码，但会把每个模块的核心逻辑和关键代码片段写出来，你按这个骨架拼装，完全能跑出一个能用的版本。

3.1 环境准备：Python虚拟环境与依赖安装

我建议先建一个干净的虚拟环境，免得依赖冲突。Windows下用以下命令：

python -m venv venv venv\Scripts\activate pip install lxml pdfplumber PyMuPDF rapidocr_onnxruntime

这几个库的职能：

• lxml：解析XML和OFD内部XML文件，支持XPath，性能强。
• PyMuPDF：PDF文本提取，速度快，对扫描件的兼容性也不错。
• pdfplumber：更精细的PDF文本提取，适合按坐标抽词。
• rapidocr_onnxruntime：OCR引擎，内置中英文模型，运行在onnxruntime上，CPU就能跑，Windows下不需要额外装其他依赖。

这里特别提一句：OCR别用Tesseract，中文发票识别效果一般，安装还要配一堆训练数据，鸡肋。RapidOCR开箱即用的识别率就够能打，而且模型文件是内置的，打包时不用额外下载。

3.2 XML发票解析模块实现

XML解析的核心代码逻辑很简单，但字段拿全要下功夫：

from lxml import etree def parse_xml_invoice(content_bytes): root = etree.fromstring(content_bytes) nsmap = root.nsmap # 根据命名空间生成解析前缀，这里以常见的电子发票命名空间为例 # 数电票XML通常有默认命名空间，需通过 nsmap 映射 ns = {} for prefix, uri in nsmap.items(): if uri: ns[prefix or 'default'] = uri fields = {} # 用 XPath 定位，不用百分百匹配结构，走模糊查找 # 比如“发票号码”的标签通常是 fphm，但不同渠道略有差异 for tag, name in [ ('fpdm', '发票代码'), ('fphm', '发票号码'), ('kprq', '开票日期'), ('jshj', '价税合计'), ('hyfplx', '行业发票类型'), ]: # 直接在整个XML树里搜索标签名 el = root.find(f'.//*[local-name()="{tag}"]') if el is not None and el.text: fields[name] = el.text.strip() # 销售方、购买方信息在嵌套节点里 # 用递归方式把整个树遍历一遍，碰到关键标记词就记录 for el in root.iter(): local = etree.QName(el).localname if local == 'xfMc' and el.text: fields['销售方名称'] = el.text.strip() if local == 'gmMc' and el.text: fields['购买方名称'] = el.text.strip() return fields

这段代码的技巧点在于，不要死磕某个固定的XPath，因为不同开票软件导出的XML结构存在细微差异。用local-name()来忽略命名空间前缀，用已知标签名直接查找，容错率高得多。

还有一种情况是XML被base64编码嵌在别的文件里，比如PDF附件里有XML。这种要先base64解码再解析：

import base64 def extract_xml_from_base64(encoded_str): decoded = base64.b64decode(encoded_str) return decoded.decode('utf-8')

3.3 OFD发票解析模块实现

OFD的解包逻辑很套路化。先当zip打开，遍历内部文件，找到含关键字的XML，再走XML解析：

import zipfile from lxml import etree def parse_ofd_invoice(file_path): with zipfile.ZipFile(file_path, 'r') as z: # OFD内部文件列表 name_list = z.namelist() # 找到两个关键XML # OFD.xml 是文档根，Document.xml 在 Doc_x 下 doc_xml_name = None content_xml_name = None for name in name_list: if name.endswith('Document.xml'): doc_xml_name = name if 'Content.xml' in name or name.endswith('Content.xml'): content_xml_name = name fields = {} # 1. 解析 Document.xml 拿票据元数据 if doc_xml_name: doc_content = z.read(doc_xml_name) doc_root = etree.fromstring(doc_content) # 遍历所有文本节点，收集文本特征 all_texts = [el.text.strip() for el in doc_root.iter() if el.text and el.text.strip()] # 在文本列表中做关键词匹配 for text in all_texts: if '发票号码' in text or '发票代码' in text: # 提取字段值需要看相邻文本，这里简化为全部收集 pass # 2. 解析 Content.xml 拿页面上的核心发票信息 if content_xml_name: content_bytes = z.read(content_xml_name) content_root = etree.fromstring(content_bytes) texts = [] for el in content_root.iter(): if etree.QName(el).localname == 'TextObject': txt_content = el.find('{*}TextCode') # 具体路径要看实际文件 if txt_content is not None and txt_content.text: texts.append(txt_content.text.strip()) # 把收集到的所有文本拼接成一个大字符串，再用正则定位字段 full_text = '\n'.join(texts) fields = extract_fields_from_text(full_text) return fields

OFD解析的核心思路跟XML一样：它底层就是xml，字段藏得再深，最后也要落在文本节点上。区别只在多一层zip解包。但OFD也有个坑：不是所有OFD生成工具都会把发票字段清晰地写在TextObject里，有的把整张票面渲染成矢量图形，这时候就必须走图像方案了，后面再讲。

3.4 PDF发票提取与OCR兜底实现

PDF模块是最能体现“分层策略”的地方：

import fitz # PyMuPDF def extract_text_from_pdf(file_path): doc = fitz.open(file_path) full_text = '' for page in doc: full_text += page.get_text() return full_text def extract_invoice_from_pdf(file_path): # 第一次：尝试文本提取 text = extract_text_from_pdf(file_path) if text and len(text.strip()) > 50: return extract_fields_from_text(text) # 第二次：尝试pdfplumber再提取一次 import pdfplumber with pdfplumber.open(file_path) as pdf: text = '\n'.join(page.extract_text() or '' for page in pdf.pages) if text and len(text.strip()) > 50: return extract_fields_from_text(text) # 第三次：迫不得已，转图片OCR return ocr_invoice_pdf(file_path)

这个三层降级策略的核心逻辑是：文本提取永远比OCR快、比OCR准，哪怕多试几个库也不亏。

def ocr_invoice_pdf(file_path): from rapidocr_onnxruntime import RapidOCR import fitz ocr = RapidOCR() doc = fitz.open(file_path) result_text = [] for page_idx in range(len(doc)): # 用高分辨率渲染页面，OCR对模糊图片非常敏感 pix = doc[page_idx].get_pixmap(dpi=300) img_path = f'_temp_page_{page_idx}.png' pix.save(img_path) ocr_result, _ = ocr(img_path) if ocr_result: # OCR返回 [box, text, score] 结构 page_text = '\n'.join([line[1] for line in ocr_result]) result_text.append(page_text) return extract_fields_from_text('\n'.join(result_text))

OCR这一步我踩过最大的坑是DPI。有段时间扫描件识别率一直在75%左右晃悠，后来发现渲染PDF页面时用的默认DPI只有72，文字在低分辨率下糊成一团，引擎再强也白搭。把DPI提到200-300以后，识别率直接跳到95%以上。

3.5 统一数据输出与批量处理

三种格式都解析完之后，需要一个统一入口和一个批量处理器：

def parse_invoice(file_path): ext = file_path.lower().rsplit('.', 1)[-1] if ext == 'xml': with open(file_path, 'rb') as f: return parse_xml_invoice(f.read()) elif ext == 'ofd': return parse_ofd_invoice(file_path) elif ext == 'pdf': return extract_invoice_from_pdf(file_path) else: raise ValueError(f'不支持的格式: {ext}') def batch_parse(folder_path): from pathlib import Path results = [] for fp in Path(folder_path).glob('*'): if fp.suffix.lower() in {'.xml', '.ofd', '.pdf'}: try: data = parse_invoice(str(fp)) data['文件名'] = fp.name results.append(data) except Exception as e: # 单文件失败不影响整批 results.append({'文件名': fp.name, '错误': str(e)}) return results

批量处理一定要注意：单文件失败必须catch异常，不能让一个坏文件中断整个文件夹的扫描。财务手里的文件五花八门，有的PDF是扫描件、有的是图片手写、有的OFD损坏，各种情况都会遇到。

用pathlib遍历目录比os.walk简洁得多，glob('*')按后缀过滤也直观。

4. 常见问题与排查技巧实录

做工具的过程，真正烧时间的不是写代码，而是各种奇怪的环境和格式坑。这里挑几个典型问题，附上排查思路和最终解决方案。

4.1 乱码问题：XML/OFD中文乱码到底怎么破

很多人在解析XML时遇到中文乱码，第一反应是改协议、加请求头。其实大多数情况是编码声明和实际编码不一致。

排查步骤：

1. 用十六进制或文本编辑器直接打开XML文件，看看头部声明，比如<?xml version="1.0" encoding="GB2312"?>。
2. 如果声明是GB2312、GBK，但你的代码用了utf-8去解码，必然乱码。
3. 解决方案：读文件时不手动指定编码，用二进制读入，让lxml自动识别：

with open(file_path, 'rb') as f: content = f.read() root = etree.fromstring(content) # lxml会根据XML声明自动处理编码

这里的关键是：永远不要用文本模式打开XML再转码，直接二进制丢给lxml，它自己会看声明。手动decode('utf-8')反而是画蛇添足，遇到GBK编码的XML直接炸。

4.2 OCR识别率不稳定的定位与优化

OCR识别率不稳定，首先要判断是“整页都烂”还是“个别字段烂”。前者大概率是渲染问题，后者大概率是字段定位逻辑问题。

渲染问题我前面提过，DPI要提到300，这是性价比最高的一步。如果还不行，考虑二值化、去噪。RapidOCR内部做了很多预处理，外部不需要再做复杂的图像增强，反而过处理会引入噪点。

字段定位问题更常见。OCR输出的是识别出的文本块，但发票上“发票号码”和它的值在版面布局上，可能是水平排列也可能是垂直排列，OCR框的坐标顺序不一定符合阅读顺序。我的建议是：拿到OCR结果后，不要依赖顺序，而是用关键词匹配：先找到“发票号码”所在行的坐标，再去那一行或紧邻区域找数字串。这样准确率会高很多。

4.3 OFD文件解包后看不到内容？

有时候zipfile打开OFD成功，但找不到Document.xml，或者Content.xml里没有TextObject。这种情况通常是OFD的标准实现差异。

排查方式：

1. 用压缩软件（如Bandizip）直接打开OFD，看看内部文件树长什么样。
2. 如果根本没有Doc_0目录，说明这文件用的标准封装可能不同。
3. 用递归遍历的方式找所有.xml结尾的文件，逐个解析，别写死路径。

还有一种更恶心的：OFD内部页面内容不是TextObject文本，而是用Path矢量描边把字形画出来的。这意味着根本没有可提取的文本。遇到这种OFD，唯一的办法是渲染成图片走OCR。好在大多数发票OFD都采用了文本对象方式，因为这样才能在阅读器里做到全文检索。

4.4 Windows环境下的打包与分发问题

开发完工具，最后一步是打包成exe给同事用。PyInstaller打包时最容易踩的坑：

• OCR模型文件被漏掉：RapidOCR的模型文件不在代码里，打包时要手动加--add-data参数带进去。
• 路径写死导致闪退：同事双击exe后工作目录可能是C:\Windows\System32，如果你在代码里用相对路径找模型文件，必挂。最好用sys._MEIPASS定位打包后的临时解包目录。
• 杀毒软件误报：PyInstaller打的exe经常被Windows Defender误报，没什么好办法，可以加个微软的代码签名，或者分发zip格式附带使用说明。

还有个小技巧：Windows上打包时建议用--onefile模式，虽然启动慢一点，但对非技术同事来说，一个文件比一堆文件友好太多。

4.5 字段提取的边界问题：不是所有发票都一样

这是最后一个坑，也是做工具时最容易忽略的：不同行业、不同地区的发票，版式和字段位置不完全相同。专用发票、普通发票、卷票、通行费发票、数电票，每种票的字段分布都有差异。

我建议在字段提取函数里做多级容错：

1. 先尝试结构化路径提取（XML/OFD最准）。
2. 再尝试关键词定位（PDF文本层/OCR通用）。
3. 最后用正则兜底（比如金额格式、税号格式、日期格式都很固定）。

比如金额的正则可以是：

import re def extract_amount(text): # 匹配 1234.56 或 1,234.56 这类数字 matches = re.findall(r'(?<!\d)(\d{1,3}(?:,\d{3})*(?:\.\d{2})|\d+\.\d{2})(?!\d)', text) return matches

日期用\d{4}年\d{2}月\d{2}日或者\d{4}-\d{2}-\d{2}匹配，税号用18位数字加字母的组合匹配。正则兜底的作用不是主力提取，而是对结构化结果做二次校验，防止出现字段错位。

另外在导出结果时，建议把文件名、发票号码、开票日期、价税合计这几个字段作为去重键。做报销系统时，最怕的就是同一个人把同一张发票重复提交，用这三个字段做联合唯一约束，能省不少审核工作量。

写在最后的一点经验

这个工具从第一版能跑，到后面真正稳定用起来，中间差不多种了三个版本的坑。我最深的一个体会是：发票识别这件事，技术难点不在算法，而在对格式细节的了解和对异常情况的容忍度。XML有命名空间变化、OFD有封装差异、PDF有扫描和文字之分，任何一个环节没考虑周全，工具在真实文件面前就会掉链子。

如果你也准备做类似的工具，我建议从XML+OFD两种格式入手，先把结构化解析跑通再碰OCR，因为结构化数据的成功率高、反馈快，能帮你快速建立起字段映射、批量处理这些框架能力。PDF的OCR场景放在后面加上去，基本不会走弯路。

另外发票文件里有很多企业敏感信息，工具做出来后如果要在团队或公司内部使用，记得加上权限控制或脱敏导出功能，别把含税号、销售方信息的明细随便往外发。这个点虽然不涉及代码，但在实际使用中比任何功能都重要。