8583 Agreement in depth understanding 1__null

deep understanding of the 8583 protocol

Initially, the financial system only large IBM companies to provide equipment, such as host and terminal, and then many large and small companies to enter, how to design a message protocol to solve the financial system between the exchange of messages, the agreement is called the ISO8583 agreement. For example, the ' Repeat Member management system ' is used on POS machines for 8583 messages.

The financial industry involved in the data content is relatively small, such as transaction type, account number, account type, password, transaction amount, transaction fees, date time, merchant code, 2 Magnetic 3 magnetic data, transaction serial number, etc., are summed up but 100 or so data. We can simply design ISO8583, define 128 fields, arrange all financial data fields in order, and correspond to 128 fields respectively. Each data type occupies a fixed length, when a message is sent, the 128 fields are connected sequentially, and the entire string of data packages sent out.

Any financial software that receives the ISO8583 package will be able to unpack it directly according to our defined specifications, since 128 fields of the entire message are predefined. For example, the 1th field is "transaction type", the length is 4 digits, the 2nd is "account", for 19 digits and so on. The receiver can take 4 bits first, then the next 19 bits, and so on, until the entire packet 128 fields have been sorted out.
      But we have a few questions to think about:
1, how do I know the data type of each field, is a number or a character.
2, each transmitted message passes through 128 fields, and sometimes I just need 5 of those fields.
3, if the length of some of my fields is not fixed, it is how long to do.
    first question. I define ISO8583 In addition to defining what each field represents, and it also stipulates that its contents are numeric or character types. There are several types that may occur: letters, numbers, special characters, days of the year, and binary data. For example, the Merchant Type field defines its length as 15, and the type is a letter. If "Merchant Type" includes both numbers and letters. Then we define a field that can belong to multiple types at the same time.
    second question. The essence is that if I only pass the 5 fields of 128 fields, how can the receiver know which fields I have passed. I prefix the message with a header, 16 bytes, that is, 128 bit to represent the existence of a field in 128 fields. Each bit if it is 1 indicates that the corresponding field exists in this message, and if it is 0 it does not exist. For example, I want to send 5 fields, which belong to the 2nd, 3, 6, 8, 9 fields in 128 fields, so I can fill in the 128bit headers into 011001011000000000 ... 0.
     We refer to these 16 bytes as bit map, the ascended map, to indicate whether a bit exists. Considering that a lot of times the message does not need 128 fields, you can reduce the packet head from 128bit to 64bit, the most common in the ISO8583 128 fields are placed in the first 64 fields, only when needed to put the remaining 64bit into the message inside.

I used the first bit of the 64bit header to represent the special meaning, if the bit was 1, then the 64bit followed the remaining 64bit message header, and if the first bit is 0, then the 64bit is followed directly by the data field content. Because the second 64bit of the packet header is sometimes there, so we call it extended bit map extension bitmap, the first 64bit of the packet header we call it primary bit map thematic map. We put the extended bitmap directly into the first field in the 128 field, and the theme map has every packet, and it's forced to precede all 128 fields.
A third question. For example, the 2nd field is "Account", is indefinite long, may have the bank account number is 19 bits, some 17 bits, at the beginning of the field plus "account" length. For example, the account number is 0123456789, a total of 10, we become 100123456789, the receiver received the field, it knows that the 2nd field "Account" is ISO8583, will take the first 2 digits out, and then get the account number according to the length. Define a field in the specification of the property is "Llvar", where ll represents the length, Var represents the data, two ll said two-bit long, the largest is 99, three bits is "Lllvar", the largest is 999.

In addition, given that some people have special requirements, we define the 128-field section as a custom field, which is an extension.

Definition of field fields

typedef struct ISO8583

{

int Bit_flag; /* field Data type 0--string, 1--int, 2--binary*/

Char *data_name; /* Domain Name * *

int length; /* Data field length * *

int length_in_byte;/* actual Length (if it is longer) * *

int Variable_flag; /* Whether the variable length flag 0: No 2:2 Bit Longer, 3:3 bit length * *

int Datatyp; /*0--string, 1--int, 2--binary*/

Char *data; /* Store Specific Value * *

int attribute; * * Reserved/*

} ISO8583;

ISO8583 tbl8583[128] =

{

/* FLD 1 */{0, "BIT map,extended", 8, 0, 0, 2, null,0},

/* FLD 2 */{0, "PRIMARY account Number", 0, 2, 0, null,0},

/* FLD 3 */{0, "processing CODE", 6, 0, 0, 0, null,0},

/* FLD 4/{0, "AMOUNT, TRANSACTION", 0, 0, 1, null,0},

/* FLD 5 */{0, "NO use", 0, 0, 0, null,0},

/* FLD 6 */{0, "NO use", 0, 0, 0, null,0},

/* FLD 7/{0, "TRANSACTION DATE and Time", 0, 0, 0, null,0},

/* FLD 8 */{0, "NO use", 8, 0, 0, 0, null,0},

/* FLD 9 */{0, "NO use", 8, 0, 0, 0, null,0},

/* FLD {0, "NO use", 8, 0, 0, 0, null,0},

/* FLD {0, "SYSTEM TRACE AUDIT number", 6, 0, 0, 1, null,0},

/* FLD {0, "time, local TRANSACTION", 6, 0, 0, 0, null,0},

/* FLD {0, "DATE, local TRANSACTION", 4, 0, 0, 0, null,0},

/* FLD {0, "DATE, Expiration", 4, 0, 0, 0, null,0},

/* FLD {0, "DATE, Settlement", 4, 0, 0, 0, null,0},