Big endian & little endian

Big-Endian and little-Endian <>

Fill: x86 is a small end (note when modifying the Partition Table), the single-chip microcomputer is generally a large end Today, I encountered a question about the byte sequence. Although it seems very simple, I have never fully understood it. I simply found the information and figured it out. Because the current computers are all stored in eight bytes, a 16-bit integer, that is, the short in C language, there can be two storage sequence in the memory: Big-Endian and litte-Endian. consider a short integer 0x3132 (0x32 is the low position, 0x31 is the high position) and assign it to a short variable. There may be two scenarios for storing it in the memory:Big EndByte (big-Endian): ----------------- >>>>>>> short variable address 0x1000 0x1001 _____________________________ | | 0x31 | 0x32 | _______________ | ________________ The high byte is before the low byte, that is, the high byte is at the end of the low memory address. You can remember this way (Big End-> High-> front-> normal logic order)Small TerminalByte (little-Endian): ----------------- >>>>>>> short variable address 0x1000 0x1001 _____________________________ | | 0x32 | 0x31 | ________________ Low-level bytes are at the front of high-level bytes, that is, the low-level bytes are at the end of the low-level memory address. Remember this way (Small Terminal-> Low level-> front-> opposite to normal logic order) You can create an experiment using the following program in Windows # include <stdio. h> # include <assert. h> void main (void ){ Short test; File * FP; Test = 0x3132; // ('1' of 31asiic code, '2' of 32asiic Code) if (FP = fopen ("C: // test.txt ", "WB") = NULL) assert (0 ); Fwrite (& test, sizeof (short), 1, FP ); Fclose (FP);} Then open the test.txt file on the C drive. You can see that the content is 21, and test is equal to 0x3132. Obviously, we can see that the byte sequence of X86 is low. if we put the same code on the (big-Endian) machine for execution, the file is 12. this is no problem in the local machine. but when you copy this file from a big-endian machine to a little-endian machine, the problem occurs. as in the above example, we created the test file on the big-endian machine, copied it to the little-endian machine, and then read it into a short using fread, what we get is no longer 0x3132 but 0x3231, so the data we read is wrong. Therefore, we need to focus on the byte order when transmitting data on two machines with different bytes, understanding the byte sequence can help us write more code. because of the differences in the byte sequence, big-Endian is used to define all data related to the byte sequence during network transmission. The BSD Code defines four macros for processing: # define ntohs (n) // network byte order to host byte order n Represents net, H represents host, s represents short # define htons (N) // host byte order to network byte order n Represents net, H represents host, s represents short # define ntohl (n) // network byte order to host byte order n Represents net, H stands for host, S stands for long # define htonl (n) // host byte order to network byte order N stands for net, H stands for host, S stands for the example of long to illustrate the implementation of one of these macros: # Define sw16 (X )/ (Short )(/ (Short) (x) & (short) 0x00ffu) <8) |/ (Short) (x) & (short) 0xff00u)> 8) Here we implement one exchange of two bytes. The other macros are similar. Let's rewrite the above Program # include <stdio. h> # include <assert. h> # Define sw16 (X)/(short )(/ (Short) (x) & (short) 0x00ffu) <8) |/ (Short) (x) & (short) 0xff00u)> 8 ))) // Because x86 is below the low position, you need to switch to the network byte order # define htons (x) sw16 (x) void main (void ){ Short test; File * FP; Test = htons (0x3132); // ('1' of 31asiic code, '2' of 32asiic code ') If (FP = fopen ("C: // test.txt", "WB") = NULL) assert (0 ); Fwrite (& test, sizeof (short), 1, FP ); Fclose (FP);} if the machine in front of the high byte is in the same sequence as the network byte, we can do nothing, just put # define htons (X) replace the sw16 (x) macro with # define htons (x ). when I understood this question at first, I was wondering why other data does not need to be exchanged in byte order? For example, when we write a buffer to a file, we finally want to understand it, because it is all written in unsigned char type, one byte and one byte. This order is fixed and there is no problem with the byte sequence, stupid enough ..