Iso8583 메시지 인코딩 및 디코딩

Question

제 질문은 ISO8583 거래 메시지 표준을 기반으로합니다. 내 문제 문장은 16 진수 형식의 입력으로 제공되는 ISO8583 메시지를 디코딩 할 앱을 개발하는 것입니다. MTI : 0200 필드-3 : 201,234 필드-4 : 000000010000 필드 -를 내가이 16 진수 코드를 분석하고 다음과 같이 출력은 JPOS 라이브러리를 사용하여 내 입력 = 0200B22000000010000000000000008000002A5DFGR021ABCDEFGHIJ 1234567890

:

예에 대한

7 : 0110722180 필드-11 : 123456 필드-44 : A5DFGR 필드-105 : ABCDEFGHIJ 1234567890

지금이 내가 그것을 내가를 변환 할 예를 디코딩 할 출력을 구문 분석 nto는 문자열 형식입니다. 균형 조회 또는 거래 요청 인 경우 정확하게 전달할 내용을 알고 싶습니다.

그래서 내 질문은 iso8583 메시지의 16 진수 코드를 이해하는 데 사용할 수있는 도구가 있습니까?

Answer 1

예제 입력은 표준 ASCII ISO-8583 입력 문자열처럼 보이며 모든 종류의 16 진수 또는 16 진수 형식이 아닙니다. 따라서 모든 입력 내용이 문제의 큰 덩어리가 이미 해결 된 것처럼 보이는 경우.

당신이 가지고있는 것을 이해하는 한, ISO-8583 메시지 형식 및 그 값의 해독과 관련하여 공개적으로 사용 가능한 수많은 정보가 있습니다. 대부분의 경우 표준 필드 형식을 따르지만 사양에 고유 한 사용자 정의 필드 값을 가질 수 있습니다. 가장 큰 예외는 VISA와 MasterCard이지만 미국 지역의 경우 일반적으로 ISO-8583-87에 매우 가깝습니다.

위키 피 디아 페이지와 jPOS 문서는 "44 란 무엇입니까?"와 같은 정보를 찾고 있다고 생각합니다. 필자는 ISO-8583 규격을 15 년 간 유지 관리하고 있으며 ISO-8583 사양을 보았습니다. 일반적으로 데이터의 모든 변형과 인터페이스 고유의 고유 한 데이터 처리를 위해 특정 공급 업체 사양을 직접 가져야합니다. 공개적으로 사용할 수있는 몇 가지가 있으며 Google에서 "ISO-8583 .PDF"를 검색하면 쉽게 찾을 수 있습니다.

캐치는 대부분 사양이며 특히 ISO 조직 자체의 원래 ISO-8583 사양에는 특정 트랜잭션의 예가 들어 있지 않습니다. 데이터 요소 003의 내용을 알고있는 경우 파서 프로그램에 대한 트랜잭션 유형 (예 : 310000 = 기본 잔액 조회)을 식별 할 수 있도록 논리적으로 많은 기본 메시지 유형을 조합 할 수 있어야하지만 캐치는 지원되는 모든 필드를 알고 있습니다 및 해당 필드를 실제로 그 머리 또는 꼬리를 만드는 데 필요한 엔티티 사양에 특정하지만, 너무 상식을 사용하여 그것을 함께 조각 수 있습니다.

일단 ISO-8583에 익숙해지면 위와 같은 텍스트 블록을 볼 수 있습니다.이 블록에는 바이너리가없고 정신적으로 대부분의 텍스트를 구문 분석하여 텍스트없이 트랜잭션 유형을 알 수 있습니다 비트 맵은 특정 변형에 대해 잘 알고있는 경우도 있습니다.

Answer 2

1987 년, 1993 년 및 2003 년부터 ISO 8583 사양에 기반한 방언이 많이 있습니다. 수정 된 프로토콜은 필드에서 ASCII, Binary, BCD, EBCDIC 데이터의 혼합을 사용합니다.

메시지 샘플은이 사양에서 사용되지 않는 필드 105를 제외하고 OmniPay 호스트 대 호스트 구현과 유사합니다.이 https://iso8583.info/lib/OmniPay/H2H/msg

에서 온라인 도구에 의해 구문 분석 추가 수정없이

이 메시지를 사용하여 "진"표현 : 여기

0000: 30 32 30 30 42 32 32 30 │ 30 30 30 30 30 30 31 30 0200B22000000010 
0010: 30 30 30 30 30 30 30 30 │ 30 30 30 30 30 30 38 30 0000000000000080 
0020: 30 30 30 30 32 30 31 32 │ 33 34 30 30 30 30 30 30 00002
0030: 30 31 30 30 30 30 30 31 │ 31 30 37 32 32 31 38 30 0100000110722180 
0040: 31 32 33 34 35 36 30 36 │ 41 35 44 46 47 52 30 32 12345606A5DFGR02 
0050: 31 41 42 43 44 45 46 47 │ 48 49 4A 20 31 32 33 34 1ABCDEFGHIJ 1234 
0060: 35 36 37 38 39 30  │       567890 

는 원래 메시지의 일부 쓰레기,하지만 그것은 잘못이 아닙니다 파서의))

--- # Cheef's parser (Limited version - 5 levels deep only) 
- msg: # OmniPay H2H message 
    MTI: "0200" # Message Type ID. 
    DE000: "B220000000100000" # Primary bitmap // 1.3.4.7.11.44. 
- BM0: # Fields at Primary Bitmap 
    DE001: "0000000000800000" # Secondary bitmap // 105. 
    - DE003: # PC 
    S01: "20" # Transaction Code. // Refund 
    S02: "12" # Account, from. 
    S03: "34" # Account, to. 
    DE004: "000000010000" # Amount, transaction. // 10000 
    - DE007: # Date and time, transmission 
    date: "0110" # Date, local transmission. // 2015.01.10 
    time: "722180" # Time, local transmission. // 00:22:20 
    DE011: "123456" # STAN. 
    - DE044: # Additional response data 
    len: "06" 
    - val: 
     RFU: "A5DFGR" 

여러 가지 방언에 대해 정의 된 온라인 구문 분석기는 메시지 데이터를 가지고 놀고 결과를 분석 할 수 있도록합니다.