对账是指计算机应用系统间对一个清算周期的交易信息进行核对，以确认交易信息的一致性和正确性的过程。对账内容包括应用系统间的总账核对、总账与明细账核对、明细账与明细账间的勾对等。通常两个系统间先进行总账核对，再进行明细账与明细账间的勾对。但是，总账核对正确并不代表明细账核对也正确，反过来，交易明细如果能一一核对无误，总账肯定正确。因此，作为明细账核对的基础，对账明细文件就显得重要。
本文主要描述银企互联中的对账细细文件产生机制。随着经济的发展，越来越多的人倾向于刷卡消费，各类企业（商户）收费时也提供了现金、刷卡等多种模式供客户选择。刷卡收费时，企业从收费系统发起扣款，直接从银行客户个人账户上扣取应收的费用。企业收费系统与银行系统之间通过网络相连。每天营业结束后，银行系统与企业收费系统之间通过对账明细文件（以下简称对账文件）进行账务核对。由于客户账户均由银行管理，银企互联的对账一般都是以银行方交易结果为准进行核对，因此对账明细文件也由银行系统生成。当银行系统互联的企业收费系统逐渐增加，每个收费企业的对账文件格式又不一样时，如何实现对账明细文件的统一生成，实现灵活配置化管理，避免重复开发，是一个值得研究的问题。
1 基于结构体的文件动态生成机制
对账文件中的交易明细数据都保存数据库中，一般情况下，数据库软件本身不直接进行文件操作，需要通过应用程序先将数据从数据库读取到出来到内存（变量），再从内存写入文件。也就是说，对账文件的生成主要有两步：第一步是将对账文件所需要的数据从数据库中读取出来，第二步是将读取出来的数据按文件要求进行格式化。基于结构体的动态配置文件生成机制就是先将数据读取的结构体变量，再从结构变量将数据写入文件。该机制实现了从结构体变量写入文件这一过程的动态配置。具体文件生成机制如下：
1） 定义与数据库交易明细表结构一一对应的C语言结构体变量。
2） 从数据库提取对账文件格式与结构体变量之间对应关系配置。
3） 创建对账文件，打开文件指针。
4） 从数据库中搜索的交易明细数据，循环对每条明细进行处理：
①将数据保存至对应的结构体变量；
②根据文件格式与结构体变量元素对应关系配置，将数据从结构体转化成文件格式要求的字符串；
③将转化后的字符串写入文件。
5） 关闭保存文件。
由于结构体变量的成员与数据库交易明细表的字段是一一对应的，从数据库中读取的交易明细数据，每个字段的值都会完整地保存到结构体变量中，虽然会有一定的冗余，但至少不会有遗漏，保证了文件生成第一步的实现。接下来是从结构体变量中抽取对账明细需要的字段，格式化成字符串。为了解决此问题，考虑从三方面入手，首先，要明确对账文件需要用到哪些字段，这一点可以通过事先配置好字段名来解决；其次，要把参与对账的字段对应的值准确地从结构体变量中取出来，这个最困难；最后，将取出来值格式化后拼成字符串，这一点也可以通过配置好格式化串，将取出来的字段值按顺序进行格式化即可。下面重点分析一下如何把把参与对账的字段对应的值准确地从结构体变量中取出来。
2 结构体成员的值的通用提取方法
在C语言中，不管是结构体变量还是字符串变量，本质上就是系统分配的一小块内存。如果知道内存的地址和大小，可以在不知道变量名的情况下，直接将存储在对应内存中的变量值取出来。从结构体变量中提取对账字段的值正是利用这个原理。在C语言中，系统分配给结构体变量的是一块连续的内存，即变量中各成员的内存按顺序紧挨在一起。只需要计算出成员的相对地址以及该成员的内存长度，就可通过地址将对应的字段值取出来，如下列所示：
假设数据库的对账明细表table_tran_dtl有三个字段，其中tran_dt， tran_at 参与对账：
tran_dt varchar（8）， /*交易日期， 8位字符串*/
tran_sq varchar（20）， /*交易流水号， 20位字符串*/
tran_at number（15.2） /*交易金额， 15位数字型，含两位小数*/
与该表结构对应的结构体变量定义如下：
typedef struct{
char tran_dt[9]； /*相对地址为0，内存长度为9个字节（含结束符）*/
char tran_sq[21]； /*相对地址为9，内存长度为21个字节*/
double tran_at； /*相对地址为30，内存长度为8个字节*/
}str_table
现在要把参与对账的tran_dt， tran_at两个字段的值从结构体变量中取出来，只需要直接通过内存拷贝的办法，即memcpy （存放变量， 变量名+相对地址， 成员占用内存长度），如下所示：
memcpy （sTmp， str_table+0， 9）； /*取tran_dt*/
memcpy （sTmp， str_table+30， 8）； /*取tran_at，取出来后进行数据类型转化*/
从前面可以看出，提取结构体中成员的值是很简单的，但前提是要知道成员的相对地址和内存大小，而这些都是事先已经知道的，可以提前配置在数据库。
3 文件格式与结构体变量映射
从结构体变量中提取对账文件所需的字段值，需要首先建起结构体成员与对账字段之间的对应的关系，也就是明确对账文件需要哪些字段，以及这些字段在C语言内存中的相对地址和内存大小，具体实现方法如下：
1）定义与数据库交易明细表结构一一对应的C语言结构体变量。
2）计算结构体每个成员在宿主语言中的数据类型、相对地址、所占的字节长度，将计算结果保存在数据库中。
3）将交易明细表的字段名与文件域按顺序一一对应，将匹配结果保存数据库中，作用为对账文件产生的格式配置信息。
沿用前面的例子，经过上面的第1、2步后，数据库会产生如下所示的信息：
表1
[表名＼&字段名＼&数据类型＼&长度＼&相对地址＼&字段说明＼&table_tran_dtl＼&tran_dt＼&char＼&9＼&0＼&交易日期＼&table_tran_dtl＼&tran_sq＼&char＼&21＼&9＼&交易流水＼&table_tran_dtl＼&tran_at＼&double＼&8＼&30＼&交易金额＼&]
之所以保存表名是因为产生对账文件所用的交易明细表不是固定的，不同
的互联企业在银行系统中可能会对应不同的交易明细表。表中的“长度”是指在缩主语言（C语言）所点的内存长度。
由于不是所有的字段都用于产生对账文件，需要将字段与对账文件的域建立起映射关系系，也就是上面所说的第3步，最后产生的格式配置信息如下所示：
表2
[企业标识＼&序号＼&字段名＼&数据类型＼&长度＼&相对地址＼&格式化＼&字段说明＼&M000012＼&1＼&tran_dt＼&char＼&9＼&0＼&%-8s＼&交易日期＼&M000012＼&2＼&tran_at＼&double＼&8＼&30＼&%015.2f＼&交易金额＼&]
假设数据库交易明细表中的信息如下：
表3
[交易日期＼&交易流水＼&交易金额＼&20140101＼&00000000123＼&100.2＼&20140101＼&00000000789＼&60.78＼&]
那么产生的对账明细文件记录如下：
201401010000000000100.20
201401010000000000060.78
除了上表所描述的格式配置信息外，还可以配置文件域分隔符、文件行是否定长、是否换行、是否有回车符、数值型数据是否进行扩大或缩小、默认值等信息，可以实现对账文件格式的灵活定制。
4 基于动态SQL的文件动态生成机制
在交易明细表不变的情况下，基于结构体的动态文件生成机制完全能满足需求，但是，上述机制也存在不少的缺点，主要有体现在三个方面：1） 需要定义与数据库字段一一对应的结构体变量，不能动态适应表结构变化；2） 只能对应一个数据库表，不能多表数据联合处理；大部分情况下，银行系统产生对账明细文件时，通常都会涉及到一个以上的数据表。多表数据综合才能产生完整的对账明细文件。这个缺陷最为严重。3） 配置过程过于复杂。
从上述文件生成机制的处理流程不难看出，造成其使用不够灵活、配置复杂的主要原因在于使用了结构体变量和相对地址的方法来获取各字段的值。新的文件生成机制必须去掉结构体变量的限制，采用新的数据结构来存储从数据表读取的数据，以适合各种随时变化的数据记录。Pro *C动态SQL中的查询描述区恰好能满足这种要求。
首先，查询描述区是一个动态内存结构，它根据查询语句中字段个数、字段长度等情况动态分配存储空间，完美地解决了原有机制中结构体变量无法通用的问题；其次，查询描述符提供了数组下标来访问不同的字段值，不需要繁琐的位移计算来定位字段值的地址，简化了配置；再次，查询描述区动态内存能适应各种合法的SQL查询语句，包括多表联合查询、嵌套查询等。因此，有时候甚至只需要配置一条合法SQL语句即可产生文件。
使用动态SQL查询描述区进行查询处理的操作步骤主要如下：
1）初始化存储空间：分配查询描述区 （sqlda结构），为指示变量、查询字段值分配内存等。
2）使用查询描述区解析SQL字符串，获取字段个数、字段名、字段名长度、数据类型、字段值长度、字段是否为空等信息。
3）对查询描述区中的每一个字段进行数据类型转换，将oracle数据类型转换到C语言数据类型，重新设置字段长度和重新分配内存。
4）读取数据记录至查询描述区，对查询描述区的每一个字段，进行格式化后拼接成字黏符串，写入文件。
5）释放空间：释放查询描述区、指示变量等内存空间。
新机制在克服原有文件产生机制缺点的同时，继承了原来的文件格式灵活配置优点，特别是数据格式化处理的优点。整合后的新文件生成机制处理流程如下：
1）初始化存储空间：分配查询描述区 （sqlda结构），为指示变量、查询字段值分配内存等
2）从配置信息表获取SQL查询语句。
3）使用查询描述区解析SQL字符串，获取字段个数、字段名、字段名长度、数据类型、字段值长度、是否为空等信息。
4）从文件格式配置表获取文件格式配置信息
5）对查询描述区中的每一个字段进行数据类型转换，将oracle数据类型转换到C语言数据类型，重新设置字段长度和重新分配内存。
6） 逐条读取数据记录至查询描述区，对每一个字段，根据配置信息进行数据格式化处理后，拼接成字符串，写入对账明细文件。
7）释放空间：释放查询描述区、指示变量等空间。
上面的操作步骤可能需要视情况进行不同程度地细化，如SQL语句重组、动态加入查询条件、文件域分隔符追加、数值型数据扩大或缩小、默认值填充等等。
新的文件生成机制去掉了繁琐的位移计算及结构体变量的字段对应关系，此因，配置信息较少，配置操作也简单多了。只需要配置动态SQL查询语句和文件格式信息即可。实际上，新机制使用的配置信息已全部包含在旧机制的配置信息中，因此原有机制的配置信息不需要进行任何变化就可拿来配置在新机制中使用，可以有效地避免数据移植风险。
5 总结
本文针对现有的银企互联中多种多样的对账文件，提出了两种动态文件生成机制，一种是基于结构体的动态文件生成机制，它适用于对账明细数据源表固定的情况，但不适合多数据表的联合处理，而且配置复杂。另外一种动态文件生成机制是与动态SQL结合起来，不再限制于同一个数据源表，可以多表联合查询处理，同时又继承了文件格式灵活配置的优点。与基于结构体的文件生成机制相比，基于动态SQL文件生成机制适应范围更广，配置化程度更高，而且配置简单便捷，增强了系统的灵活性和适应性，节约了开发成本，提高了生产效率，具有一定的现实意义。
参考文献：
[1] 盖国强.深入浅出Oracle—DBA入门、进阶与诊断案例[M]. 北京：人民邮电出版社， 2006：99-101.
[2] （澳）麦克唐纳（Mcdonald，C.）等.精通Oracle PL/SQL [M]. 蔡伟毅，译.北京：人民邮电出版社， 2009：47-53.
[3] （美）阿拉派蒂（Alapati，S.R）. Oracle10g数据库管理艺术[M]. 钟鸣，等，译.北京：人民邮电出版社， 2007：92-93.
