현재 위치 - 대출자문플랫폼 - 외환 플랫폼 - ISO8583 메시지 해결 방법

ISO8583 메시지 해결 방법

간단히 IS08583 을 정의하는 필드는 의미가 없다고 생각합니다. 각 필드는 표준에 자세히 설명되어 있습니다. 영어판 ISO8583 규범을 이해하기가 어렵다고 생각하시면 인터넷에도 동업자가 번역한 중국어판 ISO8583 규격이 있습니다. 그래서 제 목표는 이 문장 다 보고 ISO8583 을 알아보는 것입니다. 이전에 접촉한 적이 없는 사람도 ISO8583 신문 규범을 장악할 수 있도록. (윌리엄 셰익스피어, ISO8583, Northern Exposure (미국 TV 드라마), 영어명언) 글쎄, 우리는 사업에 대해 얘기해 야 합니다. 처음에는 IBM 과 같은 대기업만이 다양한 호스트, 터미널과 같은 금융 시스템 장비를 제공했습니다. 데이터는 다양한 컴퓨터 장치 간에 교환해야 합니다. 우리는 데이터가 네트워크를 통해 전송되고 네트워크에서 전송되는 데이터는 모두 0 또는 1 과 같은 바이너리 데이터를 기반으로 한다는 것을 알고 있습니다. 데이터가 인코딩되지 않으면 아무도 읽을 수 없으며 쓸모없는 데이터입니다. 초기 X.25, SDLC 및 현재 널리 사용되는 TCP/IP 네트워크 프로토콜은 기본 통신 인코딩 프로토콜을 제공하여 가장 낮은 통신 문제를 해결하고 한 곳에서 다른 곳으로 문자열을 전송할 수 있습니다. 그러나 문자열 전송만 의미가 크지 않다. 문자열이 나타내는 것을 분석하는 것이 중요하다. 그렇지 않으면' 0 123abcd' 문자열을 전송하는 것은 소용이 없다. 시간이 지남에 따라 수십 년 전의 어느 순간으로 돌아갑시다. 우리가 역사의 무대로 밀려났다고 가정해 봅시다. 금융 시스템 간의 메시지 교환을 해결하기 위해 범용 메시지 프로토콜을 설계합시다. 이를 ISO8583 프로토콜이라고 합니다. 이때 기술은 끊임없이 발전하고 있다. 당초 IBM 일가의 독자적인 국면이 줄곧 좋지 않은 것 같다. 각종 대형 회사들이 성과를 거두기 위해 잇달아 금융업계에 진출하기 위해 백화제방 국면을 보이고 있다. 이러한 모든 회사를 포함할 수 있는 메시지 프로토콜을 설계하는 방법은 결코 쉬운 일이 아닙니다. 먼저 차근차근 생각해 봅시다. 사실 금융업계와 관련된 데이터는 수천 개가 없어 통계할 수 없다. 반대로 상대적으로 작습니다. 우리는 모두 거래 유형, 계좌 번호, 계좌 유형, 비밀번호, 거래금액, 거래비, 날짜시간, 상인 코드, 2 자기 3 자기 데이터, 거래 유수 번호 등을 알 수 있다. , 요약 가능한 모든 데이터를 요약했지만 100 정도밖에 되지 않았습니다. 그런 다음 먼저 ISO8583 을 간단하게 설계하고 128 필드를 정의하고 위에서 언급한' 계정' 등 모든 재무 데이터 유형을 128 필드 중 하나에 맞게 순차적으로 정렬할 수 있습니다. 각 데이터 유형은 미리 정의된 순서와 길이로 고정된 길이를 차지합니다. 이것은 매우 간단합니다. 메시지를 보낼 때 128 필드를 순서대로 연결한 다음 연결된 전체 패킷 문자열을 보냅니다. 모든 금융 소프트웨어가 ISO8583 패키지를 받으면 전체 메시지의 128 필드가 나타내는 것을 모두 알고 있기 때문에 우리가 정의한 사양에 따라 직접 패키지를 해제할 수 있습니다. 귀하의 패킷이 ISO8583 패키지라는 것을 알기만 하면 이미 정의했습니다. 예를 들어 1 필드는' 거래 유형', 길이는 4 자리, 두 번째 필드는' 계정', 길이는 19 자리 등입니다. 수신자는 먼저 4 비트를 취한 다음 전체 패킷의 모든 128 개 필드가 해결될 때까지 19 비트를 선택할 수 있습니다. 사실 이런 방법은 정말 간단하고 직설적이어서 기본적으로 수요를 만족시킬 수 있다. 하지만 우리는 생각해야 할 몇 가지 질문이 있습니다.

1. 각 필드의 데이터 유형이 숫자인지 문자인지 어떻게 알 수 있습니까?

2. 전송당 메시지 전송 128 개 필드, 네트워크 대역폭은 견딜 수 있습니다. 때로는 5 개의 필드만 필요할 수도 있고, 그 결과 123 개의 쓸모없는 필드가 수신될 수도 있습니다.

3. 내 일부 필드의 길이가 고정되지 않으면 어떡하죠. 지금 포장을 풀면 패킷의 각 필드가 고정된 것 같고, C 언어는 포장을 풀 때 포인터에 직접 고정 길이의 문자열을 필드로 가져오니까요. 이러한 문제를 하나씩 해결해 보겠습니다. 첫 번째 질문은 간단합니다. ISO8583 을 정의할 때 각 필드가 나타내는 것과 그 내용이 숫자인지 문자인지를 정의했습니다. 문자, 숫자, 특수 문자, 연도, 월, 날짜 및 기타 시간, 이진 데이터 등의 가능한 유형만 있습니다. 예를 들어 128 필드에서' 고객 유형' 필드의 길이를 15 로 정의하고 유형을 문자로 정의하겠습니다. 보다 구체적으로,' 고객 유형' 의 데이터에 숫자와 글자가 모두 포함되어 있다면 어떻게 해야 합니까? 그런 다음 해당 유형을 문자나 숫자로 정의할 수 있습니다. 즉, 한 필드가 동시에 여러 유형에 속할 수 있습니다. 두 번째 질문은 조금 더 복잡합니다. 본질은 128 필드의 5 개 필드만 전송하면 수신자는 내가 보낸 필드를 어떻게 알 수 있습니까? 나머지 123 을 모두 0 이나 다른 특수 기호로 채우면 이 필드가 필요하지 않다는 뜻입니다. 어떻게 될까요? 이런 처리 방식은 소용이 없고, 네트워크 대역폭의 본질적인 문제를 해결하지 못하고, 128 개 필드를 전송해야 한다. 다른 말로 하자면, 나는 메시지 앞에 머리를 하나 추가했는데, 머리 안에 들어 있는 정보는 다른 사람에게 5 개의 필드만 전달되었다는 것을 알릴 수 있게 해 주었다. (윌리엄 셰익스피어, 햄릿, 메시지명언) 이 헤드를 디자인하는 방법 16 바이트, 즉 128 비트 (1 바이트가 8 비트와 같음) 로 128 필드의 필드가 있는지 여부를 나타낼 수 있습니다. 컴퓨터의 이진수에서 각각 1 또는 0 이 아닙니다. 1 이면 메시지에 해당 필드가 있고 0 이면 존재하지 않습니다. 음, 누군가가 ISO8583 메시지를 받으면 먼저 메시지 헤더 뒤에 어떤 필드가 있는지, 어떤 필드가 없는지 알 수 있습니다. 예를 들어 128 필드 중 두 번째, 세 번째, 여섯 번째, 여덟 번째, 아홉 번째 필드에 속하는 다섯 개의 필드를 보내려고 합니다.1100/을 채울 수 있습니다. 두 번째, 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 개 필드에 배치하여 두 배로 처리할 수 있습니다. 이렇게 하면 메시지를 보낼 때 64 비트, 즉 1 바이트의 메시지 헤더와 내가 필요로 하는 몇 개의 필드만 보내면 된다. 일부 메시지가 64 에서 128 사이의 필드를 사용하는 경우 어떻게 합니까? 이것은 매우 하기 쉽다. 나는 특별한 의미를 나타내기 위해 64 비트 보고 헤더의 1 위를 사용한다. 이 비트가 1 이면 64 비트 뒤에 64 비트 보고 헤더의 나머지 부분이 있음을 의미합니다. 첫 번째 비트가 0 이면 64 비트 뒤에 64 비트 헤더가 남아 있지 않고 128 필드의 메시지입니다. 그런 다음 수신자는 헤더 1 위가 1 또는 0 인지 판단하여 헤더가 64bit 인지 128bit 인지 알고 그에 따라 처리할 수 있습니다. 보고 헤더의 마지막 64 비트를 사용할 수 있는 경우가 있기 때문에 이를 확장 비트맵이라고 하고, 해당 보고 헤더의 처음 64 비트를 주 비트맵이라고 합니다. 확장 비트맵을 128 필드의 첫 번째 필드에 직접 배치하겠습니다. 마스터 비트맵은 각 패키지에 있으므로 128 필드가 아닌 모든 128 필드 앞에 강제로 배치합니다. 세 번째 문제는 이렇게 해결할 수 있다. 예를 들어, 두 번째 필드는 "계정" 입니다. 확실하지 않습니다. 어떤 은행 계좌는 19 자리, 어떤 은행 계좌는 17 위일 수 있습니다. ISO8583 사양을 설정할 때 두 번째 필드는 19 와 17 을 포함할 수 있을 만큼 25 비트로 지정할 수 있습니다. 하지만 앞으로 30 자리가 있다면 어떨까요? 이제 이 필드를 100 비트로 설정해 보겠습니다. 앞으로 100 비트를 넘으면 어떻게 하죠? 또한 19 비트 계정이 하나뿐이고 100 비트를 정의한다면 8 1 비트 데이터는 네트워크 대역폭을 낭비하지 않습니다. 우리가 비교적 크다고 생각하는 숫자의 수를 미리 정의하는 것은 좋지 않은 것 같다.

이렇게 하면 두 번째 필드인' 계정' 의 경우 필드 시작 부분에' 계정' 길이를 추가합니다. 예를 들어 계정은 0 123456789 이고, *** 10 비트가 있는데, 우리는10012345679 로 바꿨다 앞에 10 이 있는데, 이는 뒤에 있는 10 비트가 계정임을 의미합니다. 만약 당신이 COM 에서 BSTR 을 접촉한 적이 있다면, 당신은 이 과정에 익숙해져야 합니다. 수신인은 이 필드를 받고 ISO8583 에 지정된 두 번째 필드인' 계정' 이 길어졌다는 것을 알고 처음 두 자리를 취하여 그 값을 얻습니다. 이 값은 현재 길이입니다. 그리고 길이 값에 따라 이 필드 뒤에 복제해야 할 비트가 실제 계정이라는 것을 알 수 있습니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), Northern Exposure (미국 TV 드라마) 길이가 두 자리밖에 없다고 생각한다면 최대 99 자리까지만 나타낼 수 있습니다. 충분하지 않습니다. 우리는 또한 길이가 긴 필드를 정의했습니다. 처음 세 자리는 길이이므로 999 자리입니다. 충분해야 합니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 길이명언) 사양에서 필드의 속성을 "llVAR" 로 정의하면 LL 은 길이를 나타내고 VAR 은 아래 데이터를 나타내고 두 개의 LL 은 두 자리 길이, 최대 99, 세 자리, 즉 "LLVAR" 은 최대 999 를 나타냅니다. 이렇게 하면 우리가 정의한 ISO8583 사양 문서를 볼 때 이 글자에 따라 긴 필드의 의미를 직접 이해할 수 있습니다. 여기서 해결해야 할 몇 가지 문제가 해결되었다. 우리가 직접 설계한 ISO8583 사양을 검토해 보겠습니다. 사실, 아무것도, 그냥 금융 업계에서 나타날 수 있는 데이터를 정렬, 순서 대로 정렬, 그리고 연결, 메시지를 형성, 전송 합니다. 이 메시지의 디자인을 최적화하고 비트맵 비트맵 개념을 도입하는 것이 좋습니다. 나머지 일은 매우 간단하다. 금융업계에서 나타날 수 있는 데이터 필드 유형을 직접 수집하여 128 필드 유형으로 나눕니다. 128 만큼 많지 않다면, 우리는 먼저 일부를 보류할 것이다. 또한 일부 사람들이 특별한 요구 사항을 가지고 있다는 점을 감안하면 128 필드의 몇 가지 내용을 직접 정의할 수 있다고 규정하고 있으며, 이는 확장이기도 합니다. 이렇게 우리는 결국 ISO8583 사양의 필드 설명표를 얻었다. 각 필드의 의미를 자세히 이해하려면 표를 직접 보면 됩니다. 비교적 간단합니다.

copyright 2024대출자문플랫폼