4. 数据来源与格式
在银行余额与交易流水自动导入的实战中，数据来源决定了整个导入链路的架构上限。很多项目失败并非因为解析算法不够强，而是选错了数据入口：用OCR硬啃扫描版PDF，或用人工下载的Excel去支撑高频对账。本节把常见来源拆成五类，逐一分析其特点、格式结构与适用边界，帮助你做出正确的技术选型。
一、核心原理：五类来源的本质差异
所有银行数据来源，本质上都在回答三个问题：数据由谁产生、以什么载体传递、以什么频率到达。网银导出是“人工触发+文件载体+低频”；银企直连是“系统触发+专线报文+高频”；API接口是“系统触发+HTTP报文+实时”；PDF对账单是“银行生成+版式文件+低频”；Excel/CSV则是“人工整理+结构化文本+不定频”。理解这条主线，就能预判每类来源的解析难度与运维成本。
二、方法流程：从来源到结构化数据的解析路径
不同来源的解析流程差异很大，但可以归纳为统一的四步：获取 → 识别 → 解析 → 校验。下面按来源分别说明关键动作。
- 网银导出：登录网银→选择账户与日期→导出Excel/CSV→本地解析。难点在于各银行表头位置不固定，常需跳过前N行。
- 银企直连：通过银行前置机或银企平台，以专线报文（如XML/定长）获取。需配置证书、报文格式与对账密钥。
- API接口：调用银行开放平台RESTful接口，返回JSON。需处理鉴权、分页、限流与签名。
- PDF对账单：分为文本型PDF与扫描型PDF。文本型可直接抽取文字层，扫描型必须走OCR。
- Excel/CSV：最灵活也最不规范，需处理合并单元格、多级表头、金额千分位与日期格式。
以网银导出的CSV为例，常见的前置处理代码如下：
import pandas as pd
# 跳过前5行说明文字，指定真实表头行
df = pd.read_csv("icbc_flow.csv", skiprows=5, encoding="gbk")
# 统一列名
df.columns = ["交易日期", "交易时间", "借方发生额", "贷方发生额", "余额", "对方户名", "摘要"]
# 金额清洗：去除千分位与货币符号
df["借方发生额"] = df["借方发生额"].astype(str).str.replace(",", "").str.replace("¥", "")
df["借方发生额"] = pd.to_numeric(df["借方发生额"], errors="coerce").fillna(0)
print(df.head())
三、案例/场景：不同来源的选型对照
下表汇总了五类来源在真实项目中的关键参数，可作为选型清单使用。
| 来源 | 典型格式 | 实时性 | 解析难度 | 适用场景 |
|---|---|---|---|---|
| 网银导出 | Excel/CSV | 低（人工） | 中 | 中小企业、低频对账 |
| 银企直连 | XML/定长报文 | 高 | 高（需专线） | 集团资金池、高频收付 |
| API接口 | JSON | 实时 | 中 | 互联网平台、SaaS集成 |
| PDF对账单 | PDF（文本/扫描） | 低 | 高（OCR） | 历史补录、审计留档 |
| Excel/CSV | 表格文本 | 不定 | 低-中 | 手工整理、临时导入 |
选型建议：若日均流水超过500笔，优先考虑银企直连或API；若仅月度对账，网银导出+Excel解析即可，不必过度设计。
四、误区/复盘：常见踩坑与纠正
误区一：所有PDF都能直接抽取文字。扫描版PDF没有文字层，直接解析会得到空结果。正确做法是先判断PDF是否含文字层，再决定是否启用OCR。
误区二：CSV编码统一为UTF-8。国内银行导出文件常用GBK或GB18030，直接按UTF-8读取会乱码。建议先探测编码，再指定读取。
误区三：忽略金额正负号与借贷方向。部分银行用“借方发生额/贷方发生额”两列，部分用“金额+借贷标志”。解析时必须统一为带符号金额，否则余额校验必然失败。
复盘一个真实案例：某企业用网银导出Excel做每日对账，初期运行正常，但月末流水量激增后，人工下载频繁出错，且表头行数因银行改版而变化，导致解析失败。后来改为银企直连获取XML报文，并保留Excel作为备用通道，才彻底解决。这说明来源选择要匹配业务量级，并预留降级方案。
最后强调一个校验原则：无论来源如何，导入后都必须做余额连续性校验——上一笔余额加减本笔金额应等于本笔余额。这是发现解析错误最有效的手段，也是自动导入系统必须具备的兜底能力。