ISO8583协议(转载)

转贴

我刚进入金融行业时，就知道了 IS08583 报文协议，我想可能我还没进入这个行业都已经听过了，可知 ISO8583 的影响力有多大了。最初刚接触它时， 确实对其中的一些细节概念不是很清晰，对有些地方比较迷惑。鉴于此，我想很多同行也必然会经历同样得阶段，所以我写下本文，以便大家能够少走一些弯路。同 时，我在网上（ http://blog.csdn.net/lysheng/archive/2005/03/03/309914.aspx ）写下我要写 “ 全面掌握 ISO8583 报文 ” 和 “ 符合 CEN/XFS （即 WOSA/XFS ）规范的 SP 编写 ” 两篇文章时，很多人都询问我什么时候能够写出来，可知许多人是需要了解这方面的知识的，即使我时间不是很多，也得尽量将这两篇文章写出来，给需要的人提供一些参考。

     如 果单纯的讲 IS08583 那些字段的定义，我觉得没有什么意思，标准中已经对每个字段解释的非常详细了，如果你觉得理解英文版的 ISO8583 规范有些困 难，网上也有同行为我们翻译好的中文版 ISO8583 规范，所以我的目的是达到阅读本文后能够对 ISO8583 知其然，亦知其所以然，使以前基本没有接触 它的人也能够达到掌握 ISO8583 报文规范。

     好了，我们该转入正题了。

     最开始时，金融系统只有 IBM 这些大的公司来提供设备，象各种主机与终端等。在各个计算机设备之间，需要交换数据。我们知道数据是通过网络来传送的，而在网络上传送的数据都是基于 0 或 1 这样的二进制数据，如果没有对数据进行编码，则这些数据没有人能够理解，属于没有用的数据。起初的 X.25 、 SDLC 以及现在流行的 TCP/IP 网络协 议都提供底层的通讯编码协议，它们解决了最底层的通讯问题，能够将一串字符从一个地方传送到另一个地方。但是，仅仅传送字符串是没有太大意义的，怎样来解 析字符串代表什么内容是非常重要的，否则传送一些 “0123abcd” 的字符串也是无用的乱码。

     让我们随着时光回到几十年前的某 个时刻，假设我们被推到历史的舞台上，由我们来设计一个通用报文协议，来解决金融系统之间的报文交换，暂且称该协议叫做 ISO8583 协议。此时，技术是 在不断的前行，当初 IBM 一支独秀的局面好像已经不妙了，各种大小不一的公司都进入金融行业以求能有所斩获，呈一片百花齐放的局面。我们怎样来设计一个报 文协议，能够将这些如雨后春笋般出现的所有公司都纳入进来，其实也不是一件很简单的事。

     我们还是先一步步的来考虑吧。金融行业其 实涉及到的数据内容并不是成千上万，无法统计，恰恰相反，是比较少的。我们都可以在心底数得过来，象交易类型、帐号、帐户类型、密码、交易金额、交易手续 费、日期时间、商户代码、 2 磁 3 磁数据、交易序列号等，把所有能够总结出来的都总结起来不过 100 个左右的数据。那我们可以首先简单的设计 ISO8583 ，定义 128 个字段，将所有能够考虑到的类似上面提到的 “ 帐号 ” 等金融数据类型，按照一个顺序排起来，分别对应 128 个字段中的一个字段。 每个数据类型占固定的长度，这个顺序和长度我们都事先定义好。这样就简单了，要发送一个报文时，就将 128 个字段按照顺序接起来，然后将接起来的整串数据 包发送出去。

     任何金融软件收到 ISO8583 包后，直接按照我们定义的规范解包即可，因为整个报文的 128 个字段从哪一位到哪一 位代表什么，大家都知道，只要知道你的数据包是 ISO8583 包即可，我们都已经定义好了。比如第 1 个字段是 “ 交易类型 ” ，长度为 4 位，第 2 个字段位是 “ 帐号 ” ，为 19 位等等。接收方就可以先取 4 位，再取接着的 19 位，依次类推，直到整个数据包 128 个字段都解完为止。

     其实这种做法真是简单直接，基本上就可以满足需要了。不过我们有几个问题要思考下：
1 、 我怎么知道每个字段的数据类型呢，是数字还是字符？
2 、 每个传送的报文都把 128 个字段都传过去，那网络带宽能够承受得了，有时候我可能只需要其中 5 个字段，结果多收到了 123 个无用的字段。
3 、 如果我某些字段的长度不固定，属于变长怎么办，因为你现在解包是当作数据包每个字段都是固定的，用 C 语言解包时直接依靠指针取固定长度的一串字符做为一个字段。

     我们来一一解决这些问题。

     第 一个问题简单，我在定义 ISO8583 时除了定义每个字段表示什么，还规定其内容是数字或是字符等即可。考虑可能出现的类型不过有以下几种：字母、数字、 特殊字符、年月日等时间、二进制数据。比如我对 128 个字段中的 “ 商户类型 ” 字段定义其长度是 15 ，同时定义其类型为字母。再精细点，如果 “ 商户类型 ” 里 面的数据同时包括数字和字母呢？那我们就定义其类型为字母也可，为数字也可，即一个字段可以同时属于多个类型。

     第二个问题稍微复 杂点。其本质就是如果我只传 128 个字段的 5 个字段，接收方怎么知道我传了哪几个字段给它了。要是我们把剩下的 123 全部填成 0 或其他特殊标识，标明该字 段不需要使用？这种处理方法没有半点用处，没有解决网络带宽的本质问题，还是要传 128 个字段。

     换个思路，我在报文前面加上个包 头，包头里面包含的信息能够让别人知道只传了 5 个字段。怎样设计这个包头，可以这样，我们用 16 个字节，即 128 个 bit （一个字节等于 8bit ）来表示 128 个字段中的某个字段是否存在。每个 bit 在计算机的二进制里面不是 1 就是 0 ，如果是 1 就表示对应的字段在本次报文中存在，如果是 0 就是不存在。这样 好了，如果别人接收到了 ISO8583 报文，可以先根据最前面的报文头，就知道紧接着报文头后面的报文有哪些字段，没有哪些字段了。比如，我要发送 5 个字 段，分别属于 128 个字段中的第 2 、 3 、 6 、 8 、 9 字段，我就可以将 128bit 的报文头填成 011001011000000000……….. ，一共 128 个 bit ，后面就全是 0 了。注意其中第 2 、 3 、 6 、 8 、 9 位为 1 ，其他都为 0 。

     有了这个 128bit 的报文头，我们就可以 只发送需要的 5 个字段了。怎样组织报文？先放上这 128bit ，即 16 个字节的头，然后在头后面放 2 、 3 、 6 、 8 、 9 字段，这些字段紧挨在一起， 3 和 6 之 间也不需要填上 4 、 5 这两个字段了。接收方收到这个报文，它会根据 128bit 的报文头来解包，它自然知道把第 3 个字段取出后，就直接在第 3 字段的后面取 第 6 个字段，每个字段的长度在 ISO8583 里面都定义好了，很轻松就把数据包解出来了。

     这下好了，为了解决上面的第二问题，我 们只是在报文中增加了 16 个字节的数据，就轻松搞定了，我们把这 16 个字节称为 bit map ，即位图，用来表示某个位是否存在。不过我们再稍微优化一下，考虑到很多时候报文不需要 128 个字段这么多，其一半 64 个字段都不一定能够用完。那 我可以将报文头由 128bit 减到 64bit ，只有在需要的时候才把剩下的 64bit 放到报文里面，这样报文长度不又少了 8 个字节吗？

     是 个好主意。我们把 ISO8583 的 128 个字段中最常见的都放到前 64 个字段中，那我们可以将处理缩小一倍。这样我一般发送报文时只需发送 64bit ，即 一个字节的报文头，再加上需要的几个字段就可以了。如果有些报文用到 64 到 128 之间的字段呢？这个也好办，我把 64bit 报文头的第一位 bit 用来代表 特殊含义，如果该 bit 为 1 ，则表示 64bit 后面跟了剩下的 64bit 报文头；如果第一位 bit 为 0 ，则表示 64bit 后面没有跟剩下的 64bit 报文 头，直接是 128 个字段中的报文了。那们，接收方会判断一下报头的第一个 bit 是 1 还是 0 ，从而知道报文头是 64bit 还是 128bit 了，就可以做相应 处理。因为报文头第二个 64bit 属于有时候有，所以我们叫它 Extended bit map 扩展位图，相应的报文头最开始的 64bit 我们叫它 Primary bit map 主位图。我们直接把扩展位图固定放到 128 个字段的第一个字段，而主位图每个数据包都有，就强制性放在所有 128 个字段的前面，并不归入 128 个字 段中去。

     第三个问题可以考虑这样解决。比如第 2 个字段是 “ 帐号 ” ，是不定长的，可能有的银行帐号是 19 位，有的是 17 位等。我们 定 ISO8583 规范时可以规定第 2 个字段是 25 位，这下足够将 19 和 17 的情况都包含进来，但是如果以后出现了 30 位的怎么办？那我们现在将字段定为 100 位。以后超过 100 位怎么办，况且如果你只有 19 位的帐号，我们定义了 100 位，那 81 位的数据不是浪费了网络的带宽。看来预先定义一个我们认为比 较大的位数是不太好的。
  
     我们这样，对于第 2 个字段 “ 帐号 ” ，在字段的开头加上 “ 帐号 ” 的长度。比如帐号是 0123456789 ，一共 10 位，我们变成 100123456789 ，注意前面多了个 10 ，表示后面的 10 位为帐号。如果你接触过 COM 里面的 BSTR ，应该对这种处理比较熟悉了。接收方收到该字段后，它知道 ISO8583 规定第 2 个字段 “ 帐号 ” 是变长的，所以会先取前面的 2 位出来，获取其值， 此时为长度，然后根据该长度值知道应该拷贝该字段后面哪几位数据，才是真正的帐号。如果你觉得长度如果只有两位最多只能表示 99 位长，不太够，我们也定义 可以允许前面 3 位都为长度的变长字段，这样就有 999 位长，应该够了吧。在规范里面如果我定义某个字段的属性是 “LLVAR” ，你注意了，其中的 LL 表示 长度， VAR 表示后面的数据，两个 LL 表示两位长，最大是 99 ，如果是三位就是 “LLLVAR” ，最大是 999 。这样看我们定义的 ISO8583 规范文档 时直接根据这几个字母就理解某个变长字段的意思了。

     该解决的几个问题到这里都解决了，我们来回顾下自己设计的 ISO8583 规 范。其实没有什么，无非是把金融行业可能出现的数据分门别类，排好顺序，接着把它们连接起来，组成一个报文发送出去而已。其中针对该报文的设计进行了一些 优化，引入了 bit map 位图的概念，也算是一个不错的想法。

     剩下的工作就简单了，我们就直接收集金融行业可能出现的数据字段类型，分成 128 个字段类型，如果没有到 128 个这么多就先保留一些下来，另外考虑到有些人有特殊的要求，我们规定可以将 128 个字段中的几个字段你自己来定义其内容，也算是一种扩展了。

     这样，最后我们就得到了 ISO8583 规范的那张字段描述表了。想要详细的知道每个字段的含义直接对着表看就可以，比较简单。

全文完