8583报文协议

最开始的时候,金融系统只有IBM这些大的公司来提供设备,像各种主机和终端等等,在各个计算机设备之间,需要交换数据。我们知道数据是通过网络来传送的,而在网络上传送的数据都是基于0和1这样二进制数据。

我们需要一个通用报文协议,来解决金融系统之间的报文交换(让我们知道我们传输的数据代表什么意思),暂且称之为ISO8583报文协议,这个报文协议需要容纳所有公司的数据交互,所以我们需要一个通用的格式。

第一步考虑,金融行业涉及的数据内容并不是很多,我们可以细数过来,比如说,交易类型,账户,账户类型,密码,交易金额,手续费,日期时间,商户代码,交易序列号,等等,我们综合起来不超过100个类,那我们设计简单的ISO8583,定义128个类,将所有能够考虑到的上面提到的金融类型,按照顺序排列起来分别对应128个字段的一个字段,每个数据类型占固定的长度(长度和顺序事先定义好),要发送一个报文,就将这128个字段按照顺序连接起来然后将接起来的整串数据包发出去就好了。

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

但是,我们有几个问题需要考虑一下

1.我怎么知道每个字段的数据类型呢 ? 是数字还是字符?

2.每个传送的报文都把128个字段都传过去了,网络带宽受得了吗?有时候我们只需要5个字段,但是缺传了128个字段,多余123个无用的?

3.如果某些字段的长度不固定,属于自动变长的怎么办?


第一个问题很简单,我们定义的时候发现可能出现的数据类型不过以下几种;字母,数字,特殊字符,年月日,二进制数据等等,所以我们定义数字和字母都可以,一个字段可以属于多个类型。

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

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

我们将报文中增加的两个字节称为bitmap,即位图用来表示某个位置是否存在,那么我们再稍微优化一下,考虑到我们有些时候报文不需要使用到128个字段这么多,我们把它缩成一半一半的,我们将ISO8583报文中最常见的都放在前64个字段中,这时候包头就只需要64bit即1个字节。

如果有些报文用到64到128之间的字段呢?我们将64bit报文头的第一位用来表示特殊含义,如果该bit为1,则表示64bit后面跟了剩下的64bit报文头;如果第一位bit为0,则表示64bit后面没有跟剩下的64bit报文头接收方会判断一下报头的第一个bit是1还是0,从而知道报文头是64bit还是128bit了,就可以做相应处理。

因为报文头第二个64bit属于有时候有,所以我们叫它Extended bitmap 扩展位图

相应的报文头最开始的64bit我们叫它Primary bitma主位图

我们直接把扩展位图固定放到128个字段的第一个字段,而主位图每个数据包都有,就强制性放在所有128个字段的前面。


第三个问题,我们在账号字段的前面加上账号的长度,比如0123456789,我们变成100123456789,表示后面的账号是10位的,接收方收到该字段后,它知道ISO8583规定第2个字段“帐号”是变长的,所以会先取前面的2位出来,获取其值,此时为长度,然后根据该长度值知道应该拷贝该字段后面哪几位数据,才是真正的帐号。

规范里面如果我定义某个字段的属性是“LLVAR”,你注意了,其中的LL表示长度,VAR表示后面的数据,两个LL表示两位长,最大是99,如果是三位就是“LLLVAR”,最大是999。这样看我们定义的ISO8583规范文档时直接根据这几个字母就理解某个变长字段的意思了。


我们回顾一下自己设计的ISO8583报文协议,把金融行业可能出现的数据分门别类排好顺序,然后连接起来组成一个报文发送出去,针对报文设计进行一下优化工作引入bitmap位图作为索引。

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

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

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,937评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,503评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,712评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,668评论 1 276
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,677评论 5 366
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,601评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,975评论 3 396
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,637评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,881评论 1 298
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,621评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,710评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,387评论 4 319
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,971评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,947评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,189评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 44,805评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,449评论 2 342

推荐阅读更多精彩内容