當前位置:外匯行情大全網 - 外匯開戶 - 如何解決ISO8583消息

如何解決ISO8583消息

我覺得簡單定義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位,第二個字段為“賬號”,長度為19位,以此類推。接收方可以先取4比特,然後取19比特,依此類推,直到整個數據包的所有128個字段都被求解。其實這種做法真的很簡單直接,基本能滿足需求。但是我們有幾個問題要思考:

1.我如何知道每個字段的數據類型,是數字還是字符?

2.每條傳輸的消息傳輸128個字段,網絡帶寬可以承受。有時候我可能只需要5個字段,結果收到123個無用字段。

3.我的壹些字段的長度不固定怎麽辦,因為現在妳解包就好像數據包的每個字段都是固定的,而C語言解包的時候直接依靠指針取壹串固定長度的字符串作為字段。讓我們逐壹解決這些問題。第壹個問題很簡單。當我定義ISO8583時,我定義了每個字段代表什麽,也規定了它的內容是數字或字符。只有以下可能的類型:字母、數字、特殊字符、年、月、日期和其他時間,以及二進制數據。例如,我將128字段中的“商戶類型”字段的長度定義為15,將其類型定義為字母。更具體地說,如果“商戶類型”中的數據既包括數字又包括字母,該怎麽辦?那麽我們可以將其類型定義為字母或數字,即壹個字段可以同時屬於多種類型。第二個問題稍微復雜壹點。本質是如果我只發送了128字段的5個字段,接收方怎麽知道我發送給它的是哪些字段?如果我們把剩下的123全部用0或者其他特殊符號填充,表示這個字段不需要,會怎麽樣?這種處理方式沒有用,沒有解決網絡帶寬的本質問題,還是要傳輸128個字段。換個說法,我在消息前面加了壹個頭,頭裏面包含的信息可以讓別人知道只傳遞了5個字段。如何設計這個包頭,我們可以用16字節,即128位(壹個字節等於8位)來表示128字段中的壹個字段是否存在。在計算機的二進制中,每壹位不是1就是0。如果是1,則該消息中存在對應的字段,如果是0,則不存在。嗯,如果有人收到ISO8583消息,他們可以首先知道哪些字段在消息頭後面,哪些字段沒有。比如我要發送五個字段,分別屬於128字段中的第二個、第三個、第六個、第八個、第九個字段,我可以填充110010110000000的消息頭。請註意,第2、3、6、8和9位是1,其他位都是0。使用128位的報頭,我們只能發送所需的5個字段。如何組織消息?先放128bit的頭,也就是16字節,然後把字段2、3、6、8、9放在頭後面,這幾個字段靠在壹起,3和6之間的字段4、5不用填。當接收方接收到此消息時,它將根據128bit的報頭對其進行解包。它自然知道取出第三個字段後,會直接取第三個字段後的第六個字段,每個字段的長度都是ISO8583定義的,所以很容易解包數據包。好吧,為了解決上面的第二個問題,我們只是在消息中增加了16字節的數據,很容易就能得到。我們把這些16字節的位映像,也就是位圖,來表示壹個位是否存在。不過還是稍微優化壹下吧,考慮到很多時候壹條消息不需要128字段那麽多,它的64個字段可能有壹半用不完。那我可以把消息頭從128bit縮減到64 bit,只在需要的時候把剩下的64 bit放到消息裏,這樣消息長度不是少了8個字節嗎?這是個好主意。我們將ISO8583最常見的128字段放在前64個字段中,這樣可以加倍處理。這樣我發消息的時候只需要發64bit,也就是壹個字節的消息頭,加上幾個我需要的字段。如果某些消息使用64到128之間的字段怎麽辦?這很好辦。我使用64位報頭的第壹位來表示特殊含義。如果該位是1,則意味著64位之後是64位報頭的其余部分。如果第壹位為0,則意味著64位之後沒有剩余的64位報頭,它直接是128字段中的消息。然後,接收方會判斷報頭的第壹位是1還是0,從而知道報頭是64bit還是128bit,可以做相應的處理。因為報頭的後64位有時是可用的,所以我們稱之為擴展位圖,而對應報頭的前64位稱為主位圖。我們直接把擴展位圖放在128字段的第壹個字段,而主位圖在每個包中都有,所以強制放在所有128字段的前面,不包含在128字段中。第三個問題可以這樣解決。比如第二個字段是“賬號”,不確定。有的銀行賬號可能是19位,有的是17位。我們在設置ISO8583規範的時候,可以規定第二個字段是25位,足以包含19和17兩個,但是如果以後有30位呢?那麽現在讓我們將該字段設置為100位。以後超過100比特怎麽辦?另外,如果妳只有壹個19位的賬號,我們定義的是100位,那麽81位的數據並不浪費網絡帶寬。提前定義壹個我們認為比較大的數字個數,似乎不好。

這樣,對於第二個字段“賬號”,在字段的開頭加上“賬號”的長度。比如賬號是0123456789,有壹個***10位,我們改成100123456789。註意前面有壹個10,表示後面的10位是賬號。如果妳在COM中接觸過BSTR,妳應該熟悉這個過程。接收方在接收到這個字段後,知道ISO8583指定的第二個字段“賬號”變長了,所以會取前兩位得到它的值,這個值就是此時的長度,然後根據長度值知道這個字段後面應該復制哪些位,才是真正的賬號。如果妳覺得長度只有兩位的話,最多只能表示99位,不夠,我們還定義了壹個變長字段,允許前三位是長度,所以是999位,應該夠了。在規範中,如果我定義壹個字段的屬性為“llVAR”,妳會註意到LL代表長度,VAR代表下面的數據,兩個LL代表兩位數長,最大為99,如果是三位,就是“LLVAR”,最大為999。這樣,當我們查看我們定義的ISO8583規範文檔時,我們可以根據這些字母直接理解變長字段的含義。這裏解決了幾個應該解決的問題。讓我們回顧壹下我們自己設計的ISO8583規範。其實也沒什麽,只是把金融行業可能出現的數據整理出來,按順序排列,然後連接起來,形成壹個消息,發出去。優化此消息的設計並引入位圖位圖的概念是壹個好主意。剩下的工作很簡單。我們會直接收集金融行業可能出現的數據字段類型,劃分為128字段類型。如果沒有128那麽多,我們就先保留壹部分。另外,考慮到有些人有特殊要求,我們規定妳可以自己定義128字段中的幾個內容,這也是壹種擴展。這樣,我們最終得到了ISO8583規範的字段描述表。想詳細了解每個字段的含義,直接看表就可以了,比較簡單。

  • 上一篇:申請中山居住證有什麽用?
  • 下一篇:投資理財師如何給客戶做規劃
  • copyright 2024外匯行情大全網