Article from https://blog.csdn.net/yuan_hong_wei/article/details/49148721 , thanks to the original author!
When I first entered the financial industry, you know IS08583 message protocol, I think, I have not entered the industry have already heard, you can see how much influence the ISO8583. Initially new to it, and indeed some of the details of the concept is not very clear, for there are places confused. In view of this, I think many colleagues will certainly have to go through the same stages, so I wrote this article, so that we can take some detours. At the same time, I am on the Internet ( http://blog.csdn.net/lysheng/archive/2005/03/03/309914.aspx wrote me to write "complete control of the ISO8583 message" and "in line with CEN / XFS) (ie, when writing "two articles WOSA / XFS) specification SP, a lot of people ask me when to write, we can see that many people need to understand this knowledge, even though I was not a lot of time, you have to try these two articles written out to those who need to provide some reference.
If you simply say the definition of IS08583 those fields, I do not think what it means, standard for each field have been explained in great detail, and if you feel that the English version of ISO8583 norms understand some difficulties, the Internet has the same behavior we translated Chinese version of the ISO8583 standard, so my goal is to reach after reading this article will know these to ISO8583, also know why, so basically no contact before it can reach people who master the ISO8583 message specification.
Well, we turn to the question of.
The very beginning, the financial system is only IBM these large companies to provide equipment, like a variety of hosts and terminals. Between the respective computer devices you need to exchange data. We know that the data is transmitted over the network, and the data transmitted on the network are based on a binary 0 or 1 such data, if the data is not encoded, the data no one can understand, the data belonging to no use. At first X.25, SDLC, and now the popular TCP / IP network protocol provides the underlying communication protocol encoding, they solved the lowest level of communication problems, a string of characters can be transferred from one place to another. However, just sending a string is not much sense of how to parse the string represents what is very important, otherwise the transfer of some "0123abcd" string is useless gibberish.
Let us return to some point in time as a few decades ago, assuming we pushed on to the stage of history, to us to design a common message protocol to address the exchange of messages between the financial system, saying the time being ISO8583 protocol is called protocol. In this case, technology is constantly forward, IBM had a single show the situation seems to have the worst of times, various sizes of companies have entered the financial industry in order to have gains, showing a flourishing situation. How do we design a text protocol packets, can all these companies have sprung up are included in, it is actually not a very simple thing.
We first consider it step by step. In fact, the financial sector is not related to the data content of thousands, not statistics, on the contrary, is relatively small. We can count them in my heart, like the types of transactions, account number, account type, password, transaction amount, transaction fees, date and time, merchant code, magnetic 2 3 magnetic data, transaction serial number, etc., all can be summed up To sum up all but about 100 data. Then we can first simple design ISO8583, 128 fields defined, all can be considered similar to the above-mentioned "account" and other types of financial data in accordance with a row order up, respectively corresponding to a field 128 field. Each data type accounted for a fixed length, the length of this order and we are well defined in advance. This simple, when a packet to be transmitted, field 128 will pick up the order, and then pick up the entire string of packets sent.
After receiving ISO8583 any financial software package, according to our definition of direct specification can unpack, because the whole message 128 from which a field where a representative of what we all know, just know that your packets are ISO8583 package can be, we have defined. Such as the first field is a "transaction type", a length of 4 bits, the second field bit is "account" for 19 and so on. The recipient can take the first 4, then take the next 19, and so on, until the entire packet 128 fields are solutions last.
In fact, this practice is really straightforward, basically to meet the needs. But we have a few questions to think about the next:
1, how do I know what type of data each field, digital or character?
2, each packet transmitted regard the 128 field are passed in the past, network bandwidth that can be affordable, sometimes I may only need five fields, the results of more than 123 received a useless field.
3, if the length is not fixed me some fields, are longer how to do, because now you unpack each field is treated as data packets are fixed, relying on direct pointer to take a fixed length when unpacked in C language of a as a character string field.
We have all the solutions to these problems.
The first question is simple, when I'm in the definition of ISO8583 In addition to defining what each field represents, but also the provisions of its content or digital characters, etc. can be. However, considering the type that may arise are the following: letters, numbers, special characters, such as date time, binary data. For example, I 128 fields defined in the "business type" field is a length 15, which also defines the type of letters. Then fine point, if the "business type" inside the data include both numbers and letters it? Then we define the type of letters may be, may be digital, i.e. a field may belong to multiple types simultaneously.
The second problem slightly more complex. Its essence is that if I only pass five field 128 field, the receiver know how I passed what few fields to it. If we fill all the rest of the 123 to zero or other special logo, indicating that the field does not need to use? This approach is not the slightest use, it does not solve the essential problem of network bandwidth, or to pass 128 field.
A change in thinking, I added a header in front of the packet, which contains header information that can let others know just pass the five fields. How to design this header, so can we use 16 bytes, ie 128 BI t (a byte is equal to 8bit) representing 128 fields in a field exists. Each bit in the binary 1 is the computer which is not 0, it means that if a field corresponding to this packet is present, if 0 is not present. So good, if someone received the ISO8583 message, you can according to the front of the packet header, packet header immediately know the message behind what field, which is not a field. For example, I want to send five fields, belonging to 128 fields of 2,3,6,8,9 field, I can just be 128bit packet header to fill 011001011000000000 ......... .., a total of 128 bit , back on the whole is a 0. Note first of 2,3,6,8,9 bit is 1, the other is 0.
With this header 128bit, we can send only a field of five. How to organize messages? This first placed 128bit, i.e., 16-byte header, then put back 2,3,6,8,9 header fields, these fields are close together, does not need to fill in between 3 and 4, 5, 6 these two fields of. The receiver receives the message, it will unpack head according 128bit message, it will know after the extraction of the three fields, it took sixth field directly behind the third field, a length of each field in the ISO8583 which are defined, easily put the packet solved the problem.
This is just great, in order to solve the second problem above, we have only increased 16 bytes of data in the packet, it is easy to get, and we put 16 bytes called bit map, bitmap, for It indicates that a position exists. But we look a little further optimized, taking into account the message does not require a lot of time so many 128 fields, 64 fields are not half will be able to run. I can be reduced to 128bit packet header by a 64bit, only when necessary and only then put the rest of the 64bit packets inside, so the message length is not less then 8 bytes you?
It is a good idea. We have 128 field ISO8583 of the most common are placed in the first 64 field, then we can deal with narrow double. Just send 64bit so when I usually send the message that a byte header, plus several fields need it. If some packets used in the field between 64-128 it? This is also easy to handle, I put the first bit 64bit header is used to represent special meaning, if the bit is 1, then later with the rest of the 64bit 64bit header; if the first bit is 0, it means no later 64bit 64bit with the rest of the packet header, the packet 128 is directly in the field. That it, the receiver will determine what the header of the first bit is a 1 or a 0, so they know the message header is 64bit or 128bit, and you can act accordingly. Because the header part of the second 64bit sometimes have, so we call Extended bit map expansion bitmap, 64bit corresponding packet header beginning we call Primary bit map thematic map. We fixed directly to the expansion bitmap field 128 into a first field, and the main bit map for each packet has, in front of all the Mandatory fields 128, 128 are not included in the field to .
The third problem can be considered solved. For example, the second field is the "account" is a variable length, may have bank account number is 19, some 17 and so on. When we set ISO8583 specification can be specified second field is 25, which is sufficient under the circumstances 19 and 17 are included in, but if after the emergence of how to do a 30-bit? Then we will now field as 100. After more than 100 how do Moreover, if you only have 19 accounts, we define the 100, and that 81 of the data is not wasted network bandwidth. It seems that we believe a pre-defined relatively large number of bits is not good.
Us, for the first two fields "account", the length of the "account" at the beginning of the field plus. Such as account number is 0123456789, a total of 10, we became 100 123 456 789, more than a note in front of 10, it indicates that the following 10 to account. If you come into contact with the inside of the COM BSTR, this treatment should be more familiar. After the receiver receives the field, it knows that the second predetermined field ISO8583 "account" is variable length, it will first take out the foregoing two, its value is obtained, this time length, and then know the length value based on the copy several field behind which the data is the real account. If you feel that if only two lengths can only represent 99 long, is not enough, we can also define the allowed length of the front three are of variable length fields, so there is 999 long, it should be enough of it. In the specification which if I define the properties of a field is "LLVAR", you pay attention, where LL represents the length, VAR indicates that the following data, two LL represent two long, the maximum is 99, and if three is " LLLVAR ", the maximum is 999. According to these letters directly to understand the meaning of a variable-length fields when ISO8583 specification document we look at this definition.
Some of the issues addressed here are resolved, we look back at ISO8583 norms of their own design. In fact, there is nothing, nothing more than the financial industry, the data may appear different categories, in good order, and then connect them together to form a packet sent it. Which the packet is designed for some optimization, introduces the concept of bit map bitmap, it would be a good idea.
The remaining work is simple, we just collect field data types of financial industry that may arise, divided into 128 field type, if not to the 128 so much on the first down to keep some, while taking into account that some people have special requirements, we can be defined 128 field several fields you define its content, can be considered an extension of.
In this way, we finally got the ISO8583 standard description goes on the field. Want to know the detailed meaning of each field can be directly in front of the table look relatively simple.
The End