ISO8583报文协议介绍

为什么80%的码农都做不了架构师？>>>   

    最近在做中国银行的一个快捷支付渠道，使用的是ISO8583协议，一开始用的是JPOS框架，但是感觉框架比较臃肿，而且文档也比较少。在等待银行专线的过程中，自己抽空做了一个简单的8583报文解析框架（Simple8583），将程序重写了一遍，代码量少了不少，这几天中行的接口在测试环境终于调试完成了。抽空写一下这段时间自己学到的知识。

    首先，8583协议只是一种报文格式，定义了每个字段域的编码格式和长度，比如下面的这段报文（每两位一个字节，用16进制表示）

        00D5（报文头213，经验证正确）
        6000360000（TPDU，5）
        0100（Version，2）
        0220（MTI，2）
        7124058104F18005（BitMap，选中域为2,3,4,8,11,14,22,24,25,32,38,41,42,43,44,48,49,62,64）
        164096665528659482（数据域2，卡号，8，1字节头部长度）
        270000（数据域3，处理码，3）
        000000000001（数据域4，金额，6）
        2020202020202020202020（数据域8，终端号，11个空格）
        369797（数据域11，流水号，3）
        1607（数据域14，卡有效期YYMM，2）
        0012（数据域22，输入方式码，2，n3）
        0025（数据域24，NII，固定值025，2，n3）
        08（数据域25，服务条件码，1）
        2001（数据域32，接入机构代码，2）
        343830343832（数据域38，授权码，6）
        3331303130303030（数据域41，终端号，8）
        313034333130313533313131303131（数据域42，商户号，15）
        C9CFBAA3D0C2C0CBD6A7B8B620202020202020202020202020202020202020202020202020202020（数据域43，一级商户名，40）
        203230303132303134303730393238343935353139（数据域44，交易订单号，LLVAR，1+20字节）
        000739323033313533（数据域48，附加数据9203153，LLLVAR，2+7）
        0156（数据域49，货币代码,2,n3）
        00443032303037313537313932303134303730393134333935313230303132303134303730393238343935353139（数据域62，原始交易信息，包含几个子域）
            （0044（长度）
                30323030（原MTI，0220,4字节）
                373135373139（原交易流水，715719，6字节）
                3230313430373039313433393531（原交易日期+时间，20140709143951，14字节）
                3230303132303134303730393238343935353139（原交易流水号：20012014070928495519，20字节））
        D0087FDAAFBFA281(数据域64，MAC，8)

二、数据类型与编码格式：

    

三、BitMap：

四、LLVAR与LLLVAR：

    

五、to-be-continue：

转载于:https://my.oschina.net/gumpw/blog/289133