吃鸡蛋引发的血案，详解内存中的字节序

吃鸡蛋引发的血案，详解内存中的字节序

传送门: 柏链项目学院

---

  我们曾经看过一个馒头引发的血案，那么吃鸡蛋也能引发血案吗？确实能！英国作家乔纳森·斯威夫特的《格列弗游记》当中就记载了这样的故事！

这是一场由于吃鸡蛋引发的战争，战争开始是由于以下的原因：我们大家都认为，吃鸡蛋前，原始的方法是打破鸡蛋较大的一端。可是当今皇帝的祖父小时候吃鸡蛋，一次按古法打鸡蛋时碰巧将一个手指弄破了，因此他的父亲，当时的皇帝，就下了一道敕令，命令全体臣民吃鸡蛋时打破鸡蛋较小的一端，违令者重罚。老百姓们对这项命令极为反感。历史告诉我们，由此曾发生过六次叛乱，其中一个皇帝送了命，另一个丢了王位…关于这一争端，曾出版过几百本大部著作，不过大端派的书一直是受禁的，法律也规定该派的任何人不得做官。

  当然上述只是一个段子，吃鸡蛋的问题不会影响那么大，作者更多的是为了影射现实中因为很小的事情爆发大冲突的现象，比如天主教和新教之间的争斗！在IT世界，同样存在类似的问题。我们都知道数据以字节形势存储，但是同样的一段内存区域存储相同的数据也是有两个选择的，因为内存地址有高有低之分，这就很像是吃鸡蛋的问题了。下图展示了2种选择，第一种是将高位数据存放在低地址，低位数据存放在高地址，这比较符合人们读数据从左到右的习惯，我们把这种方式叫大端法（bigendion）；还有一种方式是将低位数据存放在低地址，高位数据存放在高地址，我们把这种方式叫小端法（littendtion）。

  有童鞋一定会说，出现2种选择，一定很麻烦的，为什么不能统一呢？小端法和大端法确实都存在，例如在网络设备中就按照大端法的方式去识别，而在很多pc机器当中却是按照小端法去识别，这就给我们编程增加了麻烦。作为程序员知道原理肯定是可以解决的！
按照正常逻辑，我们心中应该产生2个问题：第一个问题是我们使用的电脑是大端还是小端法？第二个问题是如何避免多平台多主机间交互没有问题？

  先来说第一个问题，这个很好验证的！我们只需要验证一下内存地址中低位存放的是低位数据还是高位数据就可以了！这个对于c程序员比较擅长，可以借助c语言的union特性来判断。

#include <stdio.h>

int main()
{
	union {
		short a;
		char buf[sizeof(short)];
	} s;
	s.a = 0x0102;
	//printf("buf[0]=%d,buf[1]=%d\n",s.buf[0],s.buf[1]);
	if(s.buf[0] == 0x01) {
		printf("The system is bigendion\n");
	} else {
		printf("The system is littlendion\n");
	}
	return 0;
}

  因为union联合体内的两个元素共用相同的首地址，这样a和buf可以认为在同一块内存区域上。如果a（258）是0x0102，那么就要看buf[0]和buf[1]内存放的是什么数据？如果buf[0]是01就代表低位地址存放高位数据，这是大端，反之就是小端了！本机测试效果如下：

localhost:test yk$ gcc bigend.c -o bigend
localhost:test yk$ ./bigend 
The system is littlendion

  c语言作为更面向底层的语言，处理的肯定是更多的细节，如果是更为偏向应用层的语言，或许不知道这么多也没问题。在go语言中，大端法和小端法的处理仍然需要知道。go语言为我们提供了转码用的"encoding/binary"包，提供了将数字转换为byte数组的方式，可以参看如下示例：

func IntToHex(num int64) []byte {
	buff := new(bytes.Buffer)
	err := binary.Write(buff, binary.BigEndian, num)
	if err != nil {
		log.Panic(err)
	}

	return buff.Bytes()
}

  IntToHex函数可以按照大端法的形势将数据转化为byte数组的形势，这样跨平台的时候统一按照大端法解析就可以了！说到这里是不是发现，我们前面提出的第二个问题也解决了！整理一下思路就是数据传输时按照统一的编码格式进行编码，接收方再按照相同的方式去解码就不会出现问题了。
如果使用c语言或go语言这种偏向底层的语言编写网络程序，尤其是跨平台的情况下，一定要懂得大端和小端的原理，否则可能要吃大亏！

---