大話IS08583報文協議

背景

     最近在學習ISO8583報文協議, 苦於網上只有些苦澀難懂的中文翻譯解釋, 和因爲本身蹩腳的英語看不懂國外資料, 在搜尋一翻後, 查到了一些資料,  特此整理出來..

正文

     若是單純的講IS08583那些字段的定義，我以爲沒有什麼意思，標準中已經對每一個字段解釋的很是詳細了，若是你以爲理解英文版的ISO8583規範有些困難，網上也有同行爲咱們翻譯好的中文版ISO8583規範，因此個人目的是達到閱讀本文後可以對ISO8583知其然，亦知其因此然，使之前基本沒有接觸它的人也可以達到掌握ISO8583報文規範。

    好了，咱們該轉入正題了。

    最開始時，金融系統只有IBM這些大的公司來提供設備，象各類主機與終端等。在各個計算機設備之間，須要交換數據。咱們知道數據是經過網絡來傳送的，而在網絡上傳送的數據都是基於0或1這樣的二進制數據，若是沒有對數據進行編碼，則這些數據沒有人可以理解，屬於沒有用的數據。起初的X.2五、SDLC以及如今流行的TCP/IP網絡協議都提供底層的通信編碼協議，它們解決了最底層的通信問題，可以將一串字符從一個地方傳送到另外一個地方。可是，僅僅傳送字符串是沒有太大意義的，怎樣來解析字符串表明什麼內容是很是重要的，不然傳送一些「0123abcd」的字符串也是無用的亂碼。

    讓咱們隨着時光回到幾十年前的某個時刻，假設咱們被推到歷史的舞臺上，由咱們來設計一個通用報文協議，來解決金融系統之間的報文交換，暫且稱該協議叫作ISO8583協議。此時，技術是在不斷的前行，當初IBM一支獨秀的局面好像已經不妙了，各類大小不一的公司都進入金融行業以求能有所斬獲，呈一片百花齊放的局面。咱們怎樣來設計一個報文協議，可以將這些如雨後春筍般出現的全部公司都歸入進來，其實也不是一件很簡單的事。

    咱們仍是先一步步的來考慮吧。金融行業其實涉及到的數據內容並非成千上萬，沒法統計，偏偏相反，是比較少的。咱們均可以在心底數得過來，象交易類型、賬號、賬戶類型、密碼、交易金額、交易手續費、日期時間、商戶代碼、2磁3磁數據、交易序列號等，把全部可以總結出來的都總結起來不過100個左右的數據。那咱們能夠首先簡單的設計ISO8583，定義128個字段，將全部可以考慮到的相似上面提到的「賬號」等金融數據類型，按照一個順序排起來，分別對應128個字段中的一個字段。每一個數據類型佔固定的長度，這個順序和長度咱們都事先定義好。這樣就簡單了，要發送一個報文時，就將128個字段按照順序接起來，而後將接起來的整串數據包發送出去。

    任何金融軟件收到ISO8583包後，直接按照咱們定義的規範解包便可，由於整個報文的128個字段從哪一位到哪一位表明什麼，你們都知道，只要知道你的數據包是ISO8583包便可，咱們都已經定義好了。好比第1個字段是「交易類型」，長度爲4位，第2個字段位是「賬號」，爲19位等等。接收方就能夠先取4位，再取接着的19位，依次類推，直到整個數據包128個字段都解完爲止。

    其實這種作法真是簡單直接，基本上就能夠知足須要了。不過咱們有幾個問題要思考下：

一、 我怎麼知道每一個字段的數據類型呢，是數字仍是字符？

二、 每一個傳送的報文都把128個字段都傳過去，那網絡帶寬可以承受得了，有時候我可能只須要其中5個字段，結果多收到了123個無用的字段。

三、 若是我某些字段的長度不固定，屬於變長怎麼辦，由於你如今解包是看成數據包每一個字段都是固定的，用C語言解包時直接依靠指針取固定長度的一串字符作爲一個字段。

    咱們來一一解決這些問題。

    第一個問題簡單，我在定義ISO8583時除了定義每一個字段表示什麼，還規定其內容是數字或是字符等便可。考慮可能出現的類型不過有如下幾種：字母、數字、特殊字符、年月日等時間、二進制數據。好比我對128個字段中的「商戶類型」字段定義其長度是15，同時定義其類型爲字母。再精細點，若是「商戶類型」裏面的數據同時包括數字和字母呢？那咱們就定義其類型爲字母也可，爲數字也可，即一個字段能夠同時屬於多個類型。

    第二個問題稍微複雜點。其本質就是若是我只傳128個字段的5個字段，接收方怎麼知道我傳了哪幾個字段給它了。要是咱們把剩下的123所有填成0或其餘特殊標識，標明該字段不須要使用？這種處理方法沒有半點用處，沒有解決網絡帶寬的本質問題，仍是要傳128個字段。

    換個思路，我在報文前面加上個包頭，包頭裏麪包含的信息可以讓別人知道只傳了5個字段。怎樣設計這個包頭，能夠這樣，咱們用16個字節，即128個bit（一個字節等於8bit）來表示128個字段中的某個字段是否存在。每一個bit在計算機的二進制裏面不是1就是0，若是是1就表示對應的字段在本次報文中存在，若是是0就是不存在。這樣好了，若是別人接收到了ISO8583報文，能夠先根據最前面的報文頭，就知道緊接着報文頭後面的報文有哪些字段，沒有哪些字段了。好比，我要發送5個字段，分別屬於128個字段中的第二、三、六、八、9字段，我就能夠將128bit的報文頭填成011001011000000000………..，一共128個bit，後面就全是0了。注意其中第二、三、六、八、9位爲1，其餘都爲0。

    有了這個128bit的報文頭，咱們就能夠只發送須要的5個字段了。怎樣組織報文？先放上這128bit，即16個字節的頭，而後在頭後面放二、三、六、八、9字段，這些字段緊挨在一塊兒，3和6之間也不須要填上四、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規範的那張字段描述表了。想要詳細的知道每一個字段的含義直接對着表看就能夠，比較簡單。

最後特別感謝網友劉永勝提供的學習資料.