ISO20ISO9000认证依据对工作有什么帮助?有没有好的认证机构推荐?

最开始时金融系统只有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个t(一个字节等于8bit)来表示128个字段中的某个字段是否存在。每个bit在计算机的二进制里面不是1就是0如果是1就表示对应的字段在本次报文中存在,如果是0就是鈈存在这样好了,如果别人接收到了ISO8583报文可以先根据最前面的报文头,就知道紧接着报文头后面的报文有哪些字段没有哪些字段了。比如我要发送5个字段,分别属于128个字段中的第2、3、6、8、9字段我就可以将128bit的报文头填成000000………..,一共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个字段“帐号”在字段的开头加上“帐号”的长度。比如帐号是一共10位,我们变成注意前面多了个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规范的那张字段描述表了想要详细的知道每个字段的含义矗接对着表看就可以,比较简单

}

我要回帖

更多关于 ISO认证 的文章

更多推荐

版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。

点击添加站长微信