Big-endian 和Little-endian ，你也许听说过这两个概念，可能也大概知道是什么意思，但未必清楚更深入的细节。这不奇怪，因为不直接和内存打交道的程序员不会对Endian有多少实践层面的理解，而即使写过相关的程序，因为抽象泄露的魔咒，也说不清底层原理。本文试图解释big-endian和little-endian的由来，在执行层面的原理，以及主流高级语言中如何处理Endian相关问题。
在继续之前，先解释前文提及的概念「抽象泄露」。计算机科学本身可以理解为有关抽象的学问，C语言尽管今天看来相当底层，但也是建立在CPU指令上的抽象，人们用C写的程序，实际上是被编译器转写到机器指令执行。这也意味着，机器指令层面的一些概念，并不能在C语言的模型里体现，即C语言程序的某些问题无法用C语言本身的模型解释，必须依赖更底层的原理。此种情况下，C语言的抽象显得不完备了，这就是抽象泄露。
典型的抽象泄露例子就是a=a+1语句中，如果变量a不是一个原子(atomic)变量，那么多线程环境中这个语句可能会造成数据不一致。这个问题很难用C语言本身的逻辑理解，我们只知道机器会给a的值加上1（C语言甚至不考虑有符号整数的溢出情况！），但具体CPU是如何计算的，我们不知道。只有当我们知道这个表达式在汇编层面是通过读取内存、执行加法，再写回内存之后能理解数据竞争的起因。这也是我认为编程初学者可以从汇编入门的原因——尽管汇编也有抽象泄露（如预测执行），但总归是比C的模型完备多了，对人也不难理解，C系语言的执行模型实在有点两头不占（另一头是函数式模型）的意思。
回到正题。来解释big-endian和little-endian的区别。
什么是Big-endian和Little-endian
考虑如下一段C程序。
#include <stdio.h>
#include <stdint.h>
uint8_t u8s[4] = { 0x12, 0x34, 0x56, 0x78 };
uint32_t conv(void) { return *((uint32_t*)u8s); }
int main(void) { printf("%x\n", conv()); }程序把一个4字节数组当作4字节整数读取，输出的内容会是多少呢？按照通常思路，uint32_t占内存中4字节的空间，4个uint8_t也是占4字节空间，那么这个指针强转的结果自然也是16进制的12345678。但实际上，在你的电脑上通常结果是78563412。是的，不是12345678，不是87654321，也不是1e6a2c48。而且这不是什么随机行为，而是基于某种逻辑的固定倒转。
简单来说，对该程序输出78563412的CPU，就是Little-endian的；而输出12345678，则是Big-endian的。
这两块内存不都是4字节吗，为什么会有这个区别？一个不精确但通俗的解释是：CPU对聚合类型（数组、结构体）和基本类型的变量有不同的处理方式。
u8s[0] u8s[1] u8s[2] u8s[3] 0x12 0x34 0x56 0x78
以上是u8s这个数组的内存布局，从低地址到高地址排列。对于Big-endian的CPU，从内存读取一个int类型也按照这个顺序。但对Little-endian来说，就要反过来了。
int[3] int[2] int[1] int[0] 0x12 0x34 0x56 0x78
顺序是倒过来的。把以上程序的4字节调整为8字节或2字节，也会得到类似的效果。但注意，这只针对各种内置类型有效，struct {int l; int r;}和int[2]有一样的顺序。
Endian名称的由来
中文技术资料基本把Endian统一译作「字节序」。在英文语境里，Endian倒是个有典故的词，它来自《格列佛游记》第一卷第四章：
我下面就要告诉你的是，这两大强国过去三十六个月以来一直在苦战。战争开始是由于以下的原因：我们大家都认为，吃鸡蛋前，原始的方法是打破鸡蛋较大的一端。可是当今皇帝的祖父小时候吃鸡蛋，一次按古法打鸡蛋时碰巧将一个手指弄破了，因此他的父亲，当时的皇帝，就下了一道敕令，命全体臣民吃鸡蛋时打破鸡蛋较小的一端，违者重罚。人民对此法极为反感。历史告诉我们，由此曾发生过六次叛乱，其中一个皇帝送了命，另一个丢了王位。这些内乱常常是由不来夫斯库国的君王们煽动起来的。骚乱平息后，流亡的人总是逃到那个帝国去寻求避难。据估计，先后几次有一万一千人情愿受死也不肯去打破鸡蛋较小的一端。
所以你吃鸡蛋时先打哪边？
代码中的字节序
C/C++
由于C和C++支持对变量取地址和任意指针类型的互转，我们很容易在C或C++中遇到字节序问题。结合上面使用C语言的例子，要在C语言里检测当前CPU是little-endian还是big-endian也可以用类似的做法：
bool is_little_endian(void) {
uint32_t test = 0x12345678U;
return ((uint8_t*)&test)[0] == 0x78;
}在Little-endian平台上，编译器会聪明地把这个函数优化成return 1。但这对我们来说并不够，因为我们可能需要在不同字节序的机器上编译不同的代码，运行时判断显然不够。好在，主流编译器都有宏用来判断：
#ifdef __GNUC__
#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
#define LITTLE_ENDIAN 1
#else
#define LITTLE_ENDIAN 0
#elif _MSC_VER || __INTEL_COMPILER
#define LITTLE_ENDIAN 1
#endClang会伪装自己是GCC，二者都支持通过__BYTE_ORDER__宏判断字节序。实际上，除了__ORDER_LITTLE_ENDIAN__和__ORDER_BIG_ENDIAN__外，实际上GCC中还有一种可能取值是__ORDER_PDP_ENDIAN__。PDP是Unix诞生时的CPU架构，其对16位整数采用Little-endian，而对32位整数使用一种奇怪的字节序，即把0x12345678表示为0x34, 0x12, 0x78, 0x56。技术上，现在已不需要考虑这种字节序。
对于Intel编译器(ICC)和Visual Studio (MSVC)，它们只存在于little-endian平台上，所以发现编译器是它们就可以放心地确认字节序。早期版本的Windows NT支持过PowerPC和MIPS这类以big-endian为主的架构，但即使是这些版本的Windows，也是运行little-endian模式的。
如果要在所有平台上以big-endian字节序读取整数，请使用位运算：
uint32_t read32be(uint8_t input[]) {
return ((uint32_t)input[0] << 24) |
((uint32_t)input[1] << 16) |
((uint32_t)input[2] << 8) |
(uint32_t)input[3];
}以Little-endian方式读取，请将数组下标倒过来。
Rust
Rust中，可使用target_endian指令在编译期判断字节序：
#[cfg(target_endian = "little")]
// Code for little endian
#[cfg(target_endian = "big")]
// Code for big endian要以某种字节序读取数据，可使用byteorder
Java
尽管主流CPU都是little-endian，但Java大概因为靠近网络字节序（见下文）的原因，统一使用big-endian。通过java.nio.ByteOrder类的nativeOrder方法，Java程序可以得知当前系统硬件上使用哪种字节序：BIG_ENDIAN或者LITTLE_ENDIAN。
DataInputStream采用Big-endian，如果要以Little-endian方式读取数据，可采用同前面C语言相似的位拼接做法。
JavaScript
JavaScript这样的脚本语言通常不太会考虑字节序问题，因为我们无法对一个对象取地址，或者查看它的内存布局。但现代JavaScript依然提供了和字节流打交道的API，这里涉及到三个概念：TypedArray、ArrayBuffer和DataView。
简单来说，TypedArray表示某种固定类型作为元素的数组（可以是8种整数和2种浮点其中之一），ArrayBuffer表示无类型的一串字节，DataView是在前者之上读写的适配器：
let array = new Uint32Array(1)
array[0] = 0x12345678
let view = new DataView(array.buffer)
view.getUint8(0) // => 120 (0x78)
view.getUint8(3) // => 18 (0x12)
view.setUint32(0, 0x12345678, true) // set data as little-endian
view.setUint32(0, 0x12345678, false) // set data as big-endian
view.getUint8(0) // => 18 (0x12)在JavaScript中，对TypedArray元素的赋值，字节序由CPU的字节序决定，所以在little-endian机器上自然得到little-endian布局的ArrayBuffer。但DataView的set方法有第三个参数表示是否使用little-endian顺序写入，要注意的是，这个参数的默认值是false，也就是big-endian，这意味着在大多数平台上setUint32及其他类似函数的行为，同一般赋值是相反的。
Ruby
Ruby也同理，大部分情况下用不着和二进制表示直接打交道。但Ruby中数组类型有将对象转换为二进制字节的pack方法，字符串类型有把字节串解析回对象的unpack方法。这两个方法利用字符串参数指定要读取的类型，除了类型和长度外，不同记号还代表着不同字节序：
[100].pack 'L' # => 32-bit int in native endian
[100].pack 'V' # => 32-bit int in little-endian
[100].pack 'N' # => 32-bit int in big-endian
# double (1.1) in native endian
"\x9A\x99\x99\x99\x99\x99\xF1?".unpack 'D'
# double (1.1) in little endian
"\x9A\x99\x99\x99\x99\x99\xF1?".unpack 'E'
# double (1.1) in big endian
"\x9A\x99\x99\x99\x99\x99\xF1?".reverse.unpack 'G'自然可以用同样的方法测试当前系统字节序：
def is_little_endian?
[1].pack('L') == [1].pack('V')
end不同硬件架构的字节序
x86
主流的32位和64位x86都是little-endian字节序。64位x86指令集有时又被称作amd64，因为它最早是AMD发明的。曾经的Intel提出过支持两种字节序切换的IA-64架构作为x86的64位继承者，后来因为不向前兼容而陨落在历史之中。
x86一直是little-endian，这意味着从最早最简单的ADD指令，到今天复杂的AVX512或者AMX，只要指令的某个操作数是内存地址，那指令就一定会按照低位在前高位在后的逻辑读取数据。
ARM
ARM在指令集层面对没有对字节序作强制要求，也就是说，一块ARM CPU可能是little-endian，可能是big-endian，也可能二者皆支持。可以从目标Triple区分：以aarch64_be、arm64_be或armeb开头的，即为big-endian，其他不带be或者eb缩写的，则是little-endian。
为了和x86兼容，主流ARM基本都是little-endian模式。
RISC-V
RISC-V是little-endian，尽管有说法曰作者更喜欢big-endian，但因为主流的ARM和x86都是little-endian，因此也选择了little-endian。
POWER
POWER诞生在90年代，那时候RISC工作站还不是个历史概念，各大厂商都在制造自家的RISC CPU和UNIX分支，x86还是穷小子，所以大家依然倾向于big-endian。不过为了便于移植x86 PC程序，Windows NT支持的PowerPC 610还的确支持过little-endian模式，然而PowerPC和Windows的合作并没有持续几代，这个开关也被移除，直到POWER 7。
但POWER 7的little-endian支持并不完整，例如硬件虚拟化就没法支持little-endian模式。从POWER 8开始，POWER CPU开始完整支持little-endian字节序。也就是说，POWER 8及以上的CPU支持两种字节序，由一个特权寄存器控制。甚至理论上，POWER CPU可以在运行时切换字节序。（但显然没人愿意这么做）
在POWER支持little-endian前，Linux已经支持32位和64位的big-endian POWER CPU。而在little-endian加入以后，因为两种字节序的程序几乎没法相互兼容，所以它们在Triple上被看作两种不同的架构：ppc64指big-endian，而little-endian常用ppc64le或ppc64el表示。
长远来看，同样是出于兼容目的，Linux将逐渐去除对64位POWER big-endian模式的支持，little-endian才是未来。不过这个故事仅限于Linux和BSD等开源社区，传统的AIX依然只会支持big-endian模式，且在可见的未来还没有改变的迹象。
一些应用场景的字节序
Unicode
UTF-16和UTF-32这两种格式都会采用多个字节表示单个码点（通俗点说就是字符，尽管并不准确），这就引出little-endian和big-endian两种格式。在多数编辑器或处理字符编码的程序里，UTF-16 LE和UTF-16 BE被看作两种编码。但根据Unicode标准 ，使用UTF-16和UTF-32的文件都需要在开头用2字节标记文件是big-endian还是little-endian：0xFE 0xFF表示big-endian，0xFF 0xFE表示little-endian。
对于一个内容为「Test」的文件，以下是三种编码的字节内容：
feff 0054 0065 0073 0074 (UTF-16 BE)
fffe 5400 6500 7300 7400 (UTF-16 LE)
6554 7473 (UTF-8)开头的这两个字节被称作BOM（Byte-order mark），显然UTF-8因为基本单位是字节，所以并不需要BOM。但一些Windows程序依然会给UTF-8文件加上0xEF 0xBB 0xBF作为BOM以标记这个文件使用UTF-8。
网络字节序
根据RFC 1700 ，socket通信中的数据都使用big-endian格式传输，因此使用socket的C API时，需要用htonl/htons/ntohl/ntohs系列函数将数据在big-endian和原生字节序之间作转换，比如要绑定的端口号。一些上层库可能已经封装了这个行为，但这一点仍需牢记在心。
WebAssembly
WebAssembly采用little-endian，但这指的是内存读写指令采用的字节序，WebAssembly字节码中的整数都用LEB128格式表示。
字节序不是什么
数组在内存中永远是从前向后排的，和字节序无关
C/C++中的结构体也永远是从前向后排的，其他高级语言可能会重排对象的内存布局，但这同样和字节序无关
整数或浮点数在CPU寄存器中使用何种字节顺序或位顺序，和字节序无关，实际上这对程序员也不可见，概念上我们都完全可以认为寄存器都是从前向后，类似big-endian般排列
字节序只和数据从内存被加载到寄存器这一过程有关，且单位是字节而不是位
意义何在
字节序是一个习惯远比实际好处重要的领域。如果一定要为两种字节序列出一些好处的话：
Big-endian更加直观，读取一个4字节整数和4字节数组采用同样的顺序，由于网络通信使用big-endian，因此big-endian的程序在处理网络数据时还能省去字节反转的开销
Little-endian环境下，长度不同的数据能够保证低位重合，也就是说32位的0x1234用16位指令去读取依然是0x1234，这节省了类型强制转换时的开销
但站在今天的角度，这些优缺点都无伤大雅。最重要的原因，不过是x86活下来成了主流，因此little-endian碰巧也成了主流，一如Windows和C语言。计算机领域各个层次都充满了抽象，如果有什么东西能穿越潮起潮落流传至今，原因几乎就是兼容性而已。