I don't think it is meaningful to simply define the fields of IS08583. Each field is explained in detail in the standard. If you think the English version of ISO8583 specification is difficult to understand, there is also a Chinese version of ISO8583 specification translated by peers on the Internet, so my goal is to understand ISO8583 after reading this article, so that people who have not been in contact with it before can master the ISO8583 message specification. Well, it's time we got down to business. At first, only large companies like IBM provided financial system equipment, such as various hosts and terminals. Data needs to be exchanged between various computer devices. We know that data is transmitted through the network, and the data transmitted on the network is based on binary data such as 0 or 1. If the data is not coded, no one can understand it and it is useless data. The original X.25, SDLC and the popular TCP/IP network protocol all provide the underlying communication coding protocol, which solves the lowest communication problem and can transmit a string of characters from one place to another. However, it is of little significance to just transmit the string, and it is very important to analyze what the string represents, otherwise it is useless to transmit some "0 123abcd" strings. Let's go back to a moment decades ago with time. Suppose we are pushed to the historical stage, let's design a general message protocol to solve the message exchange between financial systems, which is called ISO8583 protocol for the time being. At this time, technology is constantly moving forward. At the beginning, IBM's dominance seemed to have been bad. Companies of all sizes have entered the financial industry in order to make some gains, showing a situation of letting a hundred flowers blossom. How to design a message protocol that can include all these companies that have sprung up like mushrooms after rain is actually not a very simple matter. Think about it step by step. In fact, there are not thousands of data involved in the financial industry, so it is impossible to count them. On the contrary, it is relatively small. We can all know the transaction type, account number, account type, password, transaction amount, transaction cost, date and time, merchant code, 2 magnetic 3 magnetic data, transaction serial number and so on. , and summarized all the data that can be summarized, but only about 100. Then we can simply design ISO8583, define the 128 field, and arrange all the financial data types mentioned above, such as "account number", in order to correspond to one of the 128 fields respectively. Each data type occupies a fixed length, and this order and length are defined in advance. It's simple. When sending a message, connect the 128 fields in sequence, and then send the connected whole packet. After receiving the ISO8583 packet, any financial software can unpack it directly according to the specification we defined, because everyone knows what the 128 field of the whole message stands for. As long as you know that your packet is an ISO8583 packet, we have already defined it. For example, the 1 field is "transaction type" with a length of 4 digits, the second field is "account number" with a length of 19 digits, and so on. The receiver can take 4 bits first, then 19 bits, and so on, until all 128 fields of the whole data packet are solved. In fact, this practice is really simple and direct, which can basically meet the demand. But we have several questions to think about:

1. How do I know the data type of each field, whether it is a number or a character?

2. Each transmitted message transmits 128 fields, and the network bandwidth can bear it. Sometimes I may only need 5 fields, and I get 123 useless fields.

3. What should I do if the length of some of my fields is not fixed, because now you unpack as if every field of the data packet is fixed, while C language unpacks directly by taking a string of fixed-length strings as fields. Let's solve these problems one by one. The first question is simple. When I defined ISO8583, I defined what each field stands for, and also stipulated that its content is numbers or characters. There are only the following possible types: letters, numbers, special characters, year, month, date and other time, and binary data. For example, I define the length of the "Merchant Type" field in the 128 field as 15 and its type as letters. More specifically, what if the data in "Merchant Type" includes both numbers and letters? Then we can define its type as letters or numbers, that is, a field can belong to multiple types at the same time. The second question is a little more complicated. The essence is that if I only sent five fields of the 128 field, how would the receiver know which fields I sent to it? What if we fill all the remaining 123 with 0 or other special symbols, indicating that this field is unnecessary? This kind of processing is useless, and it does not solve the essential problem of network bandwidth, but still needs to transmit 128 fields. In other words, I added a header in front of the message, and the information contained in the header can let others know that only five fields have been passed. How to design this packet header, we can use 16 bytes, that is, 128 bits (one byte equals 8 bits) to indicate whether a field in 128 field exists. In the computer binary, every bit is either 1 or 0. If it is 1, the corresponding field exists in the message; if it is 0, it does not exist. Well, if someone receives an ISO8583 message, they can first know which fields are behind the message header and which fields are not. For example, if I want to send five fields, which belong to the second, third, sixth, eighth and ninth fields in the 128 field, I can fill in1100110000. Please note that bits 2, 3, 6, 8 and 9 are 1, and all other bits are 0. With a header of 128 bits, we can only send the required 5 fields. How to organize messages? Put the header of 128bit first, that is, 16 bytes, and then put fields 2, 3, 6, 8 and 9 after the header. These fields are close together, and fields 4 and 5 between 3 and 6 need not be filled in. When the receiver receives this message, it will unpack it according to the header of 128bit. It naturally knows that after taking out the third field, it will directly take the sixth field after the third field, and the length of each field is defined by ISO8583, so it is easy to unpack the data packet. Well, in order to solve the second problem above, we just added 16 bytes of data to the message, which is easy to get. We use these 16 byte bit maps, that is, bitmaps, to indicate whether a bit exists. But let's optimize it a little. Considering that many times a message doesn't need as many fields as 128, half of its 64 fields may not be used up. Then I can reduce the message header from 128bit to 64 bits, and only put the remaining 64 bits into the message when necessary, so the message length is not 8 bytes less? That's a good idea. We put the most common 128 field of ISO8583 in the first 64 fields, which can double the processing. In this way, when I send a message, I only need to send 64bit, that is, a byte header, plus a few fields I need. What if some messages use fields between 64 and 128? This is easy to handle. I use the first bit of the 64-bit header to indicate the special meaning. If this bit is 1, it means that 64 bits are followed by the rest of the 64-bit header. If the first bit is 0, it means that there is no remaining 64-bit header after 64 bits, which is directly the message in the 128 field. Then, the receiver will judge whether the first bit of the header is 1 or 0, so as to know whether the header is 64bit or 128bit, and can do corresponding processing. Because the last 64 bits of the header are sometimes available, we call it an extended bitmap, while the first 64 bits of the corresponding header are called the main bitmap. We directly put the extended bitmap in the first field of 128 field, and the main bitmap is in every package, so it is forced to be placed in front of all 128 fields, not included in 128 fields. The third problem can be solved like this. For example, the second field is "account number", which is uncertain. Some bank accounts may have 19 digits, while others have 17 digits. When we set the ISO8583 specification, we can stipulate that the second field is 25 bits, which is enough to include 19 and 17, but what if there are 30 bits in the future? Now let's set this field to 100 bits. What if it exceeds 100 bits in the future? In addition, if you only have a 19 account, and we define 100, then 8 1 data does not waste network bandwidth. It doesn't seem good to define a large number of numbers in advance.

In this way, for the second field "account number", add the length of "account number" at the beginning of the field. For example, the account number is 0 123456789, and there is a *** 10. Let's change it to 100 123456789. Note that there is a 10 in front of it, which means that the following 10 bit is the account number. If you have been exposed to BSTR in COM, you should be familiar with this process. After receiving this field, the receiver knows that the second field "account number" specified by ISO8583 has become longer, so it will take the first two digits to get its value, which is the length at this time, and then know which bits should be copied after this field according to the length value, which is the real account number. If you think the length is only two digits, it can only represent 99 digits at most, which is not enough. We also define a variable length field, which allows the first three digits to be length, so it is 999 digits, which should be enough. In the specification, if I define the attribute of a field as "llVAR", you will notice that LL stands for length, VAR stands for the following data, and two LL stands for two digits long, with a maximum of 99. If it is three digits, it is "LLVAR" with a maximum of 999. In this way, when we look at the ISO8583 specification document defined by us, we can directly understand the meaning of variable-length fields according to these letters. Several problems that should be solved are solved here. Let's review the ISO8583 specification designed by ourselves. In fact, it's nothing, just sort out the data that may appear in the financial industry, arrange them in order, and then connect them to form a message and send it out. It is a good idea to optimize the design of this message and introduce the concept of bitmap bitmap. The rest of the work is simple. We will directly collect data field types that may appear in the financial industry and divide them into 128 field types. If it's not as much as 128, we'll keep some first. In addition, considering that some people have special requirements, we stipulate that you can define several contents in the 128 field by yourself, which is also an extension. In this way, we finally got the field description table of ISO8583 specification. If you want to know the meaning of each field in detail, just look at the table directly, which is relatively simple.