轻松掌握ISO8583报文协议.doc资源-CSDN文库

版权申诉

177 浏览量 2023-09-14 13:45:24 上传评论收藏 33KB DOC 举报

资源推荐

资源详情

资源评论

轻松掌握 ISO8583 报文协议

我刚进入金融行业时，就知道了 IS08583 报文协议，我想可能我还没进入这个行业都已经听过了，可知

ISO8583 的影响力有多大了。最初刚接触它时，确实对其中的一些细节概念不是很清晰，对有些地方比

较迷惑。鉴于此，我想很多同行也必然会经历同样得阶段，所以我写下本文，以便大家能够少走一些弯路。

同时，我在网上（http://blog.csdn.net/lysheng/archiv.../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 个字段都解完为止。

其实这种做法真是简单直接，基本上就可以满足需要了。不过我们有几个问题要思考下：

本内容试读结束，登录后可阅读更多

下载后可阅读完整内容，剩余2页未读，立即下载

内容反馈

版权申诉

小小哭包

粉丝: 2050
资源: 4206

最新资源

资源上传下载、课程学习等过程中有任何疑问或建议，欢迎提出宝贵意见哦~我们会及时处理！点击此处反馈

feedback-tip