在对账系统设计中，解析文件是其中的一个关键核心部分，那么，如果要设计好解析器，可以遵循什么样的设计原理？本篇文章里，作者针对解析器的设计方法和实现原理进行了分析总结，一起来看看吧。

解析文件是对账系统设计中非常核心的一个部分，但上述文章中的解析器描述的详细程度可能有所欠缺，所以，本文单独讲一下解析器的设计方法和实现原理。

一、文件与解析

获取文件并解析文件是对账系统非常重要的环节，也是后续进行对账的基础。

而获取文件主要指三类文件：平台的支付数据、渠道的清算数据、渠道的结算数据，平台数据可以通过SQL、MQ、接口、文件等形式获取，而渠道文件一般通过接口获取，或者人工下载并导入到对账系统内。

获取文件以后，如何将文件解析到数据库里形成数据库数据就需要解析处理的能力，当然可以由技术直接研发实现。

这样做的弊端比较明显，那就是新增渠道、或者渠道文件发生了变更，对账规则发生了变更，可能都需要走研发对解析规则进行修改，这将大大的增加研发的成本，降低了对业务诉求的反映效率。

所以，可以实现解析规则的配置化，这也就是本文要介绍的“坑位解析器配置”。

为什么叫坑位解析器呢，因为本模型的数据库表是固定的，而是将文件数据按照对应关系解析到固定的字段上去。

与之相对的另外一种解析模型就是将文件原样解析，保持文件的字段数量，但是，这样的解析模型会造成大量的数据表结构，后续的处理和对账设置会稍微麻烦很多。

二、文件与解析规则的关系

对于三方支付机构来说，交易对账就是核对平台的支付数据记录与渠道下发的清算文件中的记录的一致性，而平台数据可以通过SQL获得，而清算数据可以通过接口获得，获得以后进行文件的解析，而解析就需要解析的规则，如下图所示。

一个对账项目的解析器和清算文件是绑定关系，这样就意味着该对账项目的清算文件是由该对账项目绑定的解析器所设置的规则进行解析的。

三、如何设计配置工具

下图是某支付渠道的清算文件样式。

其中的商户订单号就是平台的请求唯一单号，也就是与平台数据进行核对的唯一标识，所以要解析出来，另外的交易状态代表了退款和支付类型，后面还有金额等对账需要的字段。

如何设置将这些字段解析到数据库表中的规则，就需要用到如下的配置工具。

整个配置工具由2部分组成。

第一部分是基础配置。

是配置该解析规则的基础信息，主要配置实现“我们需要哪些数据”，比如解析器的编号，所属对账项目，文件的格式、编码等内容。

其中，过滤字段设置的是“哪些数据不要”，比如示例中的含义就是通过文件中的第9列和第10列进行过滤，第9列是“未知、失败”或者第10列是01的数据不需要进行解析。

数据开始行的用途是指定从哪一行开始解析，因为有些渠道的文件开头有表头或者有些统计类信息不需要解析，应该刨除掉，如下面的文件就应该填“6”，从第6行数据开始解析，前5行数据不需要。

数据列数的配置用途其实也是用于设定解析哪些数据，可以跟“数据开始行”的配置同时使用，加强条件，比如填写了“12”，就代表只解析哪些有12个字段的数据行。

第二部分是解析规则的配置。

这部分是规则部分，主要是配置文件中的“数据如何放到数据表里”的问题。

配置一共有3列：

第一列就是数据库表的固定字段，例如银行订单号、交易类型、卡类型等。

第二列是字段位置，也就是这个字段取文件中那一列的数据，比如原型中银行订单号填写的是1，就是将文件中的第一列解析到银行订单号。

第三列是说明文件中的数据格式、单位或者数值。

这里要强调的是，整个规则配置主要可以分3大类。

第一类：取数型配置，如银行订单号等，只需要填写数据列“数”即可，不需要配置格式、单位、数值，直接将文件中的数据取过来即可。

第二类：映射型配置，如交易类型、卡类型，二者在数据库里是固定的枚举值，分别是“支付、退款”，“借记卡、贷记卡”，按原型示例的配置，含义就是卡类型根据第“13”列判断，如果是01则代表借记卡、02代表贷记卡，解析到数据库里时，卡类型字段会设置成“借记卡”或者“贷记卡”，而不是文件中的数值；同样原型中的交易类型字段，由第“10”列决定，当是“S13、S22、S23、S36、S37、S46、S54、S56、S64”时代表支付，当是“REFUND”时代表退款。

第三类：单位和格式型配置，比如原型中的金额需要配置文件中是什么单位，时间要配置说明文件中的时间格式是什么。

专栏作家

陈天宇宙，微信公众号：陈天宇宙，人人都是产品经理专栏作家。多平台支付领域专栏作者，十年资深产品；专注为10万支付产品经理和支付机构以及企业提供深度支付内容和服务！

本文原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议。

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。