定长报文

 

2.1 定长报文

2.1.1 定长报文介绍

定长报文，应该是目前使用最广泛的报文，是报文类型中的元老级别人物了，定长报文也比较简单，理解起来也比较方便。但是定长报文也有其局限性，它的最大弱点就是担心以后所定义域的长度要加长，这个时候配置或程序就要改变。

定长报文，使用固定的长度去表示一个信息，如银行开户时开户人的名称可用30个字节表示，因为我国的人名一般不会超过15个汉字，默认可以容纳所有开户人的名称了；如果超过15个汉字怎么办，为什么不定义50个字节25个汉字的长度呢？这个如果是简单的报文再定长一点没有关系，但是从银行本身来说，存有一些贵留问题，有一些银行的报文的最大长度就只支持2K，即2048个字节；如果定义长了，发送的报文超过了2048个字节，这个时候发送报文就会被截断，造成信息丢失；如果是人名少一个字还可以根据其它的信息去判断，如果是客户存了1000000000，结果发送过去的时候刚好超长了一位被截断了一个“0”，那就麻烦大了，客户就会找银行打官司了。

因而我们在定义报文的时候，不是定义越长越好，当然也不能够定义短了，刚好满足当时的情况，如果随着后面情况的变化，这个信息域变长了，那这个程序就不适应了，则说明定义的这个报文没有时间的扩展性。如某银行原来的日期在设计的时候只设计了8位的长度，格式为"YYYYMMDD"，可是后面要求是10位的"YYYY-MM-DD"日期格式，这个时候就要调整程序了。定长报文调整报文长度那可是相当痛苦的一件事，如果这个要调整的信息域是最后一个域，那相当简单，只调整一个域，但是如果这个域是第一个域，并且这个报文有数百个域，那你就知道什么叫痛苦了，一个个的调整位置，即使是配置型的，也的一个个的去数数耍了。

2.1.2 简单定长报文

我们看一下示例，就知道定长报文是个什么样的东东了；以一个储户到银行开户为例，当然我们不能够像银行一样弄那么多项把人给搞昏，弄一个非常简单的开启，只包括以下几个字段：

字段名称	字段类型	字段长度	说明	示例值
交易类型	Char	8	定义交易的类型， 00000001：柜台交易	00000001
交易码	Char	4	0001：表示开户 0002：表示销户	0001
客户名称	Char	30	开户人的名称	张三的表哥
客户地址	Char	60	开户人当前所住地址，不可以超过30个汉字	张三的表哥家隔壁的王大娘的邻居的朋友的大姨家楼上
身份证号码	Char	18	只可以是15位或18位	123456789987654
开户资金类型	Char	2	01：人民币 02：美元 03：英镑 04：其它	01
开户日期	Char	10	开户日期	2009-09-09

以上两个带蓝底的字段表示交易附加的信息字段，以便于系统识别是什么类型的交易，以及当前交易的具体操作。这个时候我们组织成报文发出去的时候就会是如下这样：

"000000010001张三的表哥                    张三的表哥家隔壁的王大娘的邻居的朋友的大姨家楼上            123456789987654   012009-09-09"

将这个报文发送给后台程序的时候，后台程序就根据以上表格中定义的标准，将接收到的报文进行解析，然后再进行处理。

2.1.3 带循环的定长报文

定长报文也会有要用到循环的时候，如网银客户需要通过网银查它在柜台交易记录，这个时候他只需要在网银上发起一个查询到核心，然后核心就将客户在柜台的交易记录以循环报文的格式返回来再展现给客户就可以了，用户就不用到柜台去了。我们对核心的返回报文做如下定义：

字段名称	字段类型	字段长度	说明	示例值
总笔数	Char	2	当前返回的总笔数
以下定义为循环字段，就定义两个字段
交易日期	Char	10	柜台交易的日期
交易金额	Char	15	柜台交易的金额	金额不可以有小数，将金额扩大100位返回，如交易金额为100.1，则返回10010，其它依次类推

这个时候假设客户有两笔交易，分别是2009-09-09发生了一笔123.45元的交易及2010-10-10发生了一笔23456的交易，此时用户在网银收到的报文就该是如下：

"22009-09-0912345          2010-10-102345600        "

网银首先获取返回的记录数，再循环展示给客户就可以了。

本文出自：冯立彬的博客