想象你管理着一座藏书馆，书架上的每个格子都有唯一编号。今天要上架一套四卷册的《汇编传奇》：卷一《寻址》、卷二《寄存器》、卷三《指令》、卷四《中断》。问题来了——编号最小的格子（低地址）应该放哪一卷？有人习惯把卷一放在最左边，依次往后排，这叫“大端序”；有人则把卷四先塞进最小的格子，卷三、卷二、卷一依次往右，“最低卷册占最小格”，这叫“小端序”。两种摆法都能把四卷书放下，只是阅读顺序不同。更麻烦的是，馆际借书时，对方按自己的习惯阅读，结果页码全乱。网络协议为此规定了统一的打包规格，而历史上还真出现过一位把书“拆成两半再交叉摆”的怪管理员——混合端序。本文就用这座藏书馆，带你彻底看懂字节序的原理、检测、转换与跨平台陷阱。

岗位关联

掌握字节序的来龙去脉，是 AI 从业者做网络服务、数据采集、模型文件解析的底层基本功，能帮你避免最隐蔽的跨平台数据错误。

目录
  1. 可视化演示
  2. 字节序基本概念：书卷从哪头放起
  3. 硬件架构采用：各家书架的布局偏好
  4. 混合端架构：那位拆书的怪管理员
  5. 数据存储原理：多字节整数的回家路
  6. 字节序检测方法：如何看出书架的摆法
  7. 工程转换策略：网络传输的统一打包
  8. 跨平台实践陷阱：交换数据时的翻车现场
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示字节序核心：大小端内存布局对比(0x12345678)、网络字节序转换（htonl/ntohl字节交换）、ARM CPSR E位动态切换大小端模式，交互切换三个核心维度。

本节配有交互动效（进入视口后自动加载，约 3KB）。

大端序与小端序内存布局 大端序(BE): 高位字节存低地址，0x12345678存储为12 34 56 78 小端序(LE): 低位字节存低地址，存储为78 56 34 12，x86采用 BE: addr[0]=MSB | LE: addr[0]=LSB 字节序决定多字节数据在内存中的排列顺序

字节序基本概念：书卷从哪头放起

想象你是一座藏书馆的管理员，要把四卷册《汇编传奇》上架：卷一《寻址》、卷二《寄存器》、卷三《指令》、卷四《中断》。书架格子的编号从 0x1000 开始递增，一个格子恰好放一卷。如果你把卷一放进编号最小的格子，然后卷二、卷三、卷四依次往右，这种“正序摆放”就是大端序（Big-Endian）；如果管理员先把卷四塞进最小的格子，卷三、卷二、卷一依次往右——“低卷占低格、倒序摆放”，这就是小端序（Little-Endian）。两种摆法都完整放下了一套书，但读者从左往右扫过书架时，读到的卷册顺序完全不同。

计算机内存里，“一套书”就是一个多字节整数。比如 int 类型的 0x12345678，可以看作四个独立的“卷册”：0x12、0x34、0x56、0x78。大端序把最高有效字节 0x12 放在最低地址；小端序则把最低有效字节 0x78 放在最低地址。地址递增的方向，就是书架从左到右的方向。

为了理解这四个字节如何组合成原值，可以把整数展开成按 256 递增的幂次：

回到书架：大端序是“卷一在低地址格”，小端序是“卷四在低地址格”。两种摆法都能完整还原出这四卷书，但对读者来说，从左到右读到的顺序截然相反。这正是字节序最核心、也最容易被忽略的地方——它不改变数值本身，只改变数值在内存中的“摆放姿势”。

0x12345678=0x12×2563+0x34×2562+0x56×2561+0x78×2560\displaystyle 0x12345678 = 0x12 \times 256^{3} + 0x34 \times 256^{2} + 0x56 \times 256^{1} + 0x78 \times 256^{0}
这个公式说明：一个 4 字节整数本质上是从最低字节开始，每向左移动一个字节，权重就乘以 256。大小端的差异，只是决定权重最大的字节放在地址的哪一头。
  1. 最高有效字节 0x12它是数值最左边、权重最大的字节，代表了“最高位”信息。
    0x12×25630x12 \times 256^{3}
  2. 次高字节 0x34它占据第二高的权重，紧随 0x12 之后。
    0x34×25620x34 \times 256^{2}
  3. 次低字节 0x56它的权重是 256 的一次方，也就是紧挨着最低位。
    0x56×25610x56 \times 256^{1}
  4. 最低字节 0x78它代表数值的最低位，权重为 256 的 0 次方，即 1。
    0x78×25600x78 \times 256^{0}

硬件架构采用：各家书架的布局偏好

不同的藏书馆，上架规矩各不相同。Intel x86 这座大馆从 8086 时代起就固执地使用小端序：它喜欢把“卷四”放在最小的格子。ARM 馆则灵活得多，允许管理员通过寄存器配置书架方向，既能小端也能大端。而在馆际通信的“运输队”那里，规则完全统一——所有包裹必须按大端序打包，这就是网络字节序（Network Byte Order）。

为什么 x86 坚持小端？因为计算机做算术时，加法从最低位开始，进位逐位向上传递。如果最低字节恰好紧挨着低地址，CPU 从低地址开始读数据时，可以立即处理低位，不需要先跳到高地址取高位。这就像管理员从“卷四”开始清点页数，不用每次先把整摞书翻一个面。ARM 的可配置性则让它既能迎合小端生态，也能在特定场景切换成大端，但代价是系统软件需要额外处理配置状态。

网络协议之所以统一采用大端，更多是历史原因：早期的协议设计者认为，大端的存储顺序符合人类从左到右书写数字的习惯，便于抓包时直接阅读。于是 TCP/IP 协议族规定：所有超过 1 字节的字段，先传输最高有效字节。这带来一个必须掌握的转换关系：

所以，当你的服务端代码拿到一个网络包时，不要假设整数可以“原样读”——必须先经过 htonl/ntohl 或专门的解析函数。这就像馆际借书时，运输队把所有书卷按统一规范重新排列后才装箱，收件方收到后再按自己的习惯摆回书架。

htonl(0x12345678)={0x12345678,大端主机0x78563412,小端主机\displaystyle \text{htonl}(0x12345678) =\begin{cases}0x12345678, & \text{大端主机} \\0x78563412, & \text{小端主机}\end{cases}
htonl 的意思是“主机序转网络序 long 型”。如果主机本来就是大端，转换函数直接返回原值；如果是小端，则把四个字节的顺序完全倒过来。
  1. 大端主机上的行为主机序与网络序一致，函数原样返回，不做任何调整。
    htonl(0x12345678)=0x12345678\text{htonl}(0x12345678) = 0x12345678
  2. 小端主机上的行为内存中存储的是 78 56 34 12，按网络序重新解释后得到 0x78563412。
    htonl(0x12345678)=0x78563412\text{htonl}(0x12345678) = 0x78563412
  3. 网络字节序的形状无论源主机是什么序，数据线上看到的字节流都是先高后低。
    wire bytes:12  34  56  78\text{wire bytes}: 12 \; 34 \; 56 \; 78

混合端架构：那位拆书的怪管理员

传说历史上曾有一座 PDP-11 藏书馆，那里的管理员发明了一套令人匪夷所思的摆法：他把四卷书先分成两对——前两卷一对、后两卷一对，每一对内部却按“卷四、卷三”这样的倒序摆放，然后再按正序放第二对。结果书架从左到右的卷册顺序变成了：卷三、卷二、卷四、卷一。读者按顺序找书时，完全不知道发生了什么。

这个“怪管理员”在计算机史上真实存在，就是 PDP-11 的混合端序（Middle-Endian）。PDP-11 是 16 位机器，它处理 32 位整数时，先把数据拆成两个 16 位“字”，字与字之间按大端排列（高字在前），但每个 16 位字内部却按小端排列（低字节在低地址）。这种“字间大端 + 字内小端”的混搭，让存储顺序变得非常诡异。

以 0x12345678 为例，它在 PDP-11 内存中的字节序列如下：

最终内存从低地址到高地址看到的就是 34 12 78 56。这种设计几乎完全违背直觉，因此在后来的体系结构中逐渐被淘汰。但它留下了一个重要教训：任何“大小端各取一半”的折中方案，都会让上层软件付出沉重的兼容代价。如今我们见到的“双端模式切换”（如 ARM 的 big-endian 配置）则完全不同——它不是混搭，而是整机统一切换，像随时能整体翻转书架方向的管理员。

PDP-11 存储(0x12345678)=34  12⏟高16位字  78  56⏟低16位字\displaystyle \text{PDP-11 存储}(0x12345678) = \underbrace{34 \; 12}_{\text{高16位字}} \; \underbrace{78 \; 56}_{\text{低16位字}}
  1. 按 16 位字拆分32 位整数从中间分成两半，高字是 0x1234，低字是 0x5678。
    高字=0x1234,低字=0x5678\text{高字} = 0x1234, \quad \text{低字} = 0x5678
  2. 字间大端排列高字 0x1234 放在低地址区域，低字 0x5678 放在高地址区域。
    高字→低地址,低字→高地址\text{高字} \rightarrow \text{低地址}, \quad \text{低字} \rightarrow \text{高地址}
  3. 字内小端排列每个 16 位字内部，最低字节又跑到低地址。0x1234 变成 34 12，0x5678 变成 78 56。
    高字内部:34  12低字内部:78  56\text{高字内部}: 34 \; 12 \qquad \text{低字内部}: 78 \; 56

数据存储原理：多字节整数的回家路

书放好后，读者要把四卷书拼成完整的故事。他沿着书架编号从 0x1000 到 0x1003 依次取出书卷，然后按每卷的“卷序标签”重新排列。内存中的情形完全一样：CPU 要从地址中取回一个多字节整数时，先按地址递增顺序读出每个字节，再根据字节序规则把它们拼接起来。

这个过程的核心是一个权重公式。设从低地址到高地址取出的四个字节分别是 b0、b1、b2、b3，那么无论大小端，还原出的整数都可以写成：

用这个公式看大端序：低地址放的是高权重字节，b3 才是 0x78；小端序则相反，b0 直接就是 0x78。小端序的另一个好处是，低地址字节在权重上天然对齐最低位，CPU 做加法进位时不需要先做复杂移位。这也解释了为什么 x86 从小端起步并一直延续至今。

数据的存储还和“边界对齐”有关：多字节整数通常要求起始地址能被自身大小整除，例如 4 字节整数对齐到 4 的倍数。对齐与字节序是两个独立维度——对齐决定“书从哪个格子开始放”，字节序决定“书卷按什么顺序放”。两者叠加，才构成了一个完整的内存模型。

x=∑k=03bk×256k\displaystyle x = \sum_{k=0}^{3} b_k \times 256^{k}
  1. 字节变量 b_kb_k 表示按地址从小到大的顺序，第 k 个字节的值。
    b0,b1,b2,b3b_0, b_1, b_2, b_3
  2. 权重 256^k每向高地址移动一个字节，它代表的数值权重乘以 256，因为一个字节最大表示 255，多一个字节意味着多乘 256。
    2560,2561,2562,2563256^{0}, 256^{1}, 256^{2}, 256^{3}
  3. 求和还原把每个字节乘上自己的权重再相加，就得到完整整数。
    x=b0+b1×256+b2×2562+b3×2563\displaystyle x = b_0 + b_1 \times 256 + b_2 \times 256^2 + b_3 \times 256^3

字节序检测方法：如何看出书架的摆法

新上任的管理员想知道前任的摆书规则：他只需要抽出第一本书的“卷一”，看它落在编号最小的格子还是最大的格子。程序检测字节序的思路如出一辙——构造一个很容易辨认出“最低字节”的整数，再看最低字节落在低地址还是高地址。

最经典的做法是用 C 语言的联合体（union）。让一个 int 和一个 char[4] 共享同一块内存，然后给 int 赋值为 1。整数 1 的四个字节中，只有最低位字节是 1，其余都是 0。这时看 char 数组的第一个元素 c[0]（对应低地址）是 1 还是 0，就能判断字节序：

除了联合体，也可以用指针强转观察首字节，原理相同。在真实工程里，检测通常只在程序启动时做一次，后续逻辑根据结果走两条分支；很多编译器还提供 __BYTE_ORDER__ 之类的宏，在编译期就能确定平台字节序，省去运行时代价。检测字节序就像翻开一本书的版权页，花一秒钟看清摆法，后面几百次读写都不会出错。

if c[0]=1⇒小端,if c[3]=1⇒大端\displaystyle \text{if } c[0] = 1 \Rightarrow \text{小端}, \qquad \text{if } c[3] = 1 \Rightarrow \text{大端}
  1. 联合体共享内存u.i 和 u.c 指向同一起始地址，写整数后再按字节读，等价于直接观察内存。
    u.i=1u.i = 1
  2. 整数 1 的形态32 位整数 1 的二进制只有最低位为 1，其余 31 位全为 0。
    x=0x00000001x = 0x00000001
  3. c[0] 的含义c[0] 是低地址处的字节。若它是 1，说明整数的低位放在低地址，即小端；若 c[0] 是 0，则低位必在高地址处，即大端。
    c[0]=内存低地址处的首个字节\text{c[0]} = \text{内存低地址处的首个字节}

工程转换策略：网络传输的统一打包

馆际借书时，运输队不允许直接把书架搬走，而是要求所有书卷按固定顺序装进标准箱。程序里的“标准箱”就是网络字节序：发送端调用转换函数把主机序变成大端，接收端再反向还原。这个“装箱-拆箱”过程在代码里就是一组转换函数。

对 32 位整数，转换的基本操作是按字节反转映射。设原始字节序列为 in[0] 到 in[3]，转换后的序列为 out，则：

工程上，C 语言用 htonl、htons 处理；Python 里用 socket.htonl 或 struct.pack('!I', value)。更稳妥的做法是在序列化格式里直接规定所有多字节字段的网络字节序，然后用带明确序标注的序列化函数读写。这里有个常见陷阱：千万不要把 C 结构体用 memcpy 直接拷进网络包，因为结构体除了字节序问题，还有内存对齐填充（padding）和不同编译器的字段布局差异。这就像把整套书连同书架一起搬上货车——对面仓库根本没地方放你的书架。

从这个角度看，字节序转换不是“炫技”，而是协议设计的一部分。好的跨平台代码会把“主机序 ↔ 网络序”的边界收敛到极少的几个函数里，让业务代码永远操作语义明确的数值，而不是裸字节。这样即使某天换到一台大端机器，需要改动的也只是那层转换封装。

out[i]=in[n−1−i],i=0,1,2,3\displaystyle \text{out}[i] = \text{in}[n-1-i], \qquad i = 0, 1, 2, 3
  1. 读取原序in[0] 是低地址处的原始字节，in[1] 是下一个字节，依此类推。
    in[0],in[1],in[2],in[3]\text{in}[0], \text{in}[1], \text{in}[2], \text{in}[3]
  2. 反转映射out[0] 取原序列最后一个字节，out[1] 取倒数第二个，恰好把整体顺序倒过来。
    out[0]=in[3],out[1]=in[2]\text{out}[0] = \text{in}[3], \quad \text{out}[1] = \text{in}[2]
  3. 完整还原交换结束后，out 是从大端视角看的小端字节，数值含义不变，只是排列方向变了。
    out=[in[3],in[2],in[1],in[0]]\text{out} = [\text{in}[3], \text{in}[2], \text{in}[1], \text{in}[0]]

跨平台实践陷阱：交换数据时的翻车现场

两台不同架构的机器第一次交换数据时，最容易发生的情况是：接收端把对方发来的字节流按自己的字节序解释，结果所有数值都“对不上号”。比如发送端小端发出 78 56 34 12，接收端大端强读成 0x78563412，与原始 0x12345678 差了十万八千里。更麻烦的是，这个问题在单机调试时完全不会出现——因为一台机器永远用自己的字节序读写自己写的数据，只有跨平台交换时才暴露。

要快速定位这类问题，最直接的手段是看原始字节流。用 hexdump 或抓包工具观察线上数据，再对照协议文档里规定的字节序，比在代码里逐行打印整数值有效得多。消息校验和（checksum）是最敏感的报警器：把数据按 16 位字累加再模 2^16，任何字节序错误都会让收发双方算出不同的校验和：

避免这类翻车，业内沉淀了几条规范习惯：二进制协议文档必须写明“所有多字节字段一律使用网络字节序”；代码里用固定宽度整数类型（uint32_t 等），避免 long 在不同平台长度不同；解析入口处先检查 magic 字段（如 0x1F8B），用一次失败的解析快速暴露字节序问题。这些做法就像馆际之间先签一份借阅协议，明确每本书的装箱顺序，再偏门的书架布局也不会影响后续合作。

checksum=∑i=0n−1wi(mod216)\displaystyle \text{checksum} = \sum_{i=0}^{n-1} w_i \pmod{2^{16}}
  1. 分字求和把数据流按 16 位切分，得到一系列字 w0, w1, ...。
    sum=w0+w1+⋯+wn−1\text{sum} = w_0 + w_1 + \cdots + w_{n-1}
  2. 取模 2^16将累加结果保留 16 位，丢掉溢出部分。
    sum mod 65536\text{sum mod } 65536
  3. 字节序不一致同一段数据按不同字节序解释，得到的 w_i 完全不同，校验和必然不匹配。
    checksum发≠checksum收\text{checksum}_{\text{发}} \neq \text{checksum}_{\text{收}}

AI 应用场景

异构设备上报数据解析

阶段：数据接入

解决的问题：AI 服务端往往要接收来自不同厂商、不同芯片架构的设备上报数据。传统做法直接用结构体指针强转解析，只要客户端是大端 ARM、服务端是小端 x86，所有多字节字段立刻错乱。通过规定网络字节序并在服务端统一解析，数据才能稳定进入 AI 管道。

具体案例：某智能交通项目，路侧摄像头（ARM 小端）上报帧数据包含车辆 ID、车速、经纬度，中心服务器（x86 小端）用 struct.unpack('!HHL', ...) 按大端解析，替换掉原先的裸指针强转后，跨设备数值不再出错。

模型文件安全加载

阶段：模型部署

解决的问题：ONNX、Caffe 等二进制模型文件头部包含 magic、版本号、图大小等字段，并有明确的字节序约定。解析器若忽略字节序，轻则版本号读取错误，重则整个模型加载失败。按规范解析头部是在各推理引擎里正确加载模型的前提。

具体案例：推理引擎加载 ONNX 文件时，先用大端解出 IR version 和 graph 的偏移量；在 Jetson（小端）与服务器（小端）间直接用同一份解析代码，验证文件头符合规范后，再交给图优化器。

边缘侧传感器协议适配

阶段：边缘推理

解决的问题：MCU 传感器（常为大端）与 ARM 网关（小端）通过 UART/SPI 通信时，传感器上报的原始帧不经过转换就会被错误解释，导致温度、距离等特征值直接喂给 AI 模型后产生幻觉数据。需要一层协议适配，把字节序转换收敛到网关入口。

具体案例：温湿度传感器以大写上报 32 位原始值，ARM 网关在入口处调用 ntohl 还原后再做缩放，模型最终拿到的特征序列始终是物理含义正确的浮点数。

Python 演示

python30 行
import socketimport struct  def detect_endian():    # 构造 1 的四字节小端表示, 取最低地址字节    low = (1).to_bytes(4, 'little')[0]    return 'little' if low == 1 else 'big'  def host_to_network(value):    # 将 32 位整数从主机序转为网络字节序    return socket.htonl(value)  def parse_packet_head(data):    # 前 8 字节按大端解析: 2 字节 magic + 2 字节 version + 4 字节 length    magic, version, length = struct.unpack('!HHL', data[:8])    return magic, version, length  if __name__ == '__main__':    print('本机字节序:', detect_endian())     x = 0x12345678    print('主机序 %#x 转网络序 -> %#x' % (x, host_to_network(x)))     packet = b'\x1f\x8b' + b'\x00\x01' + b'\x00\x00\x00\x7b'    m, v, l = parse_packet_head(packet)    print('magic=%#x version=%d length=%d' % (m, v, l))
目的：用纯 Python 完成“检测主机字节序 → 转换网络序 → 解析大端协议头”的最小闭环，演示工程中字节序处理的核心套路。
  1. low = (1).to_bytes(4, 'little')[0]把 1 按小端编码成 4 字节，再取低地址首字节；若为 1 说明低位字节就在低地址，即小端机。
  2. return 'little' if low == 1 else 'big'用三元表达式的紧凑写法输出检测结论。
  3. socket.htonl(value)将主机序整数转为网络序，小端机上相当于做一次四字节反转。
  4. struct.unpack('!HHL', data[:8])! 表示大端（网络序），依次解析 2 字节、2 字节、4 字节三个字段。
  5. packet = b'\x1f\x8b' + ...手工构造一段 8 字节协议头，模拟收到的二进制报文。
  6. print('magic=%#x version=%d length=%d' % ...)用格式化输出确认解析结果符合预期。

常见误区

误区网络字节序是大端，那我写代码时只要把所有整数在发送前都调一次 `htonl`，就绝对安全了。

正解htonl 只处理 32 位整数，htons 处理 16 位整数，8 位字节根本不需要转换。而且网络序只对协议规定“必须按大端传”的字段有意义；应用层自定义协议完全可以约定用小端。正确的做法是先查协议文档，确认每个字段的宽度和字节序，再选择对应转换函数。这就像寄书时，不是所有箱子都要拆开重排，只有协议规定的那几卷才需要。

为何常见：初学者看到“网络字节序 = 大端”这条最显眼的结论，容易把它推广成“所有数据都套用”，忽略了转换函数的适用范围。

误区小端转大端就是把整个数据块的所有字节顺序反过来，比如 8 字节的 double 也整体反转。

正解对固定宽度的单个整数，四字节反转确实等于小端转大端。但对结构体、字符串或混合字段，必须按字段类型分别转换，字符串内部字节顺序不变，数字字段按宽度各自反转。整体反转会把“字符串内容”和“数字编码”搅在一起，就像把四卷书连同包装标签一起倒放，标签顺序对了，书页却乱了。

为何常见：教科书里演示转换时总用单个 4 字节整数，让人误以为这是通用规则。

误区PDP-11 是几十年前的老古董，大端小端之外的字节序问题在实际工作中遇不到。

正解PDP-11 虽然退出了历史舞台，但它留下的教训直接塑造了今天的网络协议和文件格式规范。更现实的是，ARM 处理器至今仍支持大端模式，路由器、交换机等网络设备上常能遇到非小端环境。AI 从业者解析模型文件、处理嵌入式上报数据时，依然可能撞上“本以为统一却没统一”的字节序问题。

为何常见：现代开发环境几乎全是 x86/ARM 小端，日常工作看不到混合端，容易产生“它不存在”的错觉。

误区既然发送端和接收端字节序一致，那我直接把 C 结构体用 `memcpy` 拷进缓冲区发给对方，最省事。

正解结构体内存在填充字节（padding），不同编译器、不同对齐选项下的布局不一致；即使是机器字节序一致，双方结构体定义稍有差异，数据也会错位。正确做法是定义独立的序列化格式，逐字段写入并用显式序标注的函数编码。这就像寄书不能连书架一起搬，必须按标准箱重新打包。

为何常见：单机自测时结构体布局完全一致，跨平台后才发现问题，于是很多人误以为是字节序的锅，其实布局对齐才是主因。

面试题

Q1. 在一个大端序机器上，int x = 0x12345678 的起始地址为 0x1000。请问地址 0x1002 处存放的字节是什么？

单选题 · easy

  • A.0x12
  • B.0x34
  • C.0x56← 正确答案
  • D.0x78

答案：C。大端序按“高位字节放低地址”排列，地址 0x1000 到 0x1003 依次存放 12、34、56、78。所以 0x1002 是 0x56。这就像书架正序摆放时，第三个格子放的是第三卷书。

Q2. 主流 x86 处理器的字节序采用以下哪种？

单选题 · easy

  • A.大端序
  • B.小端序← 正确答案
  • C.混合端序
  • D.双端切换

答案：B。x86 从 8086 起一直使用小端序，低字节放在低地址。这与它从低位开始做加法的硬件传统有关，也是为什么 htonl 在 x86 上会做字节反转。

Q3. 用 union { int i; char c[4]; } u; u.i = 1; 检测字节序，若 u.c[0] == 1，说明当前机器是？

单选题 · mid

  • A.大端存储
  • B.小端存储← 正确答案
  • C.数据已损坏
  • D.结果不确定

答案：B。整数 1 的四个字节中只有最低位字节是 1。c[0] 对应低地址处的字节，若它是 1，说明最低字节就在低地址，这是典型的小端特征。就像翻开书发现“卷四”放在最小编号的格子里。

Q4. 网络字节序（Network Byte Order）规定使用哪一种字节序？

单选题 · mid

  • A.小端序
  • B.大端序← 正确答案
  • C.自动协商
  • D.可配置

答案：B。TCP/IP 协议族统一规定多字节字段为大端序，以便跨架构设备直接阅读抓包数据。因此发送前需要把主机序转成网络序，接收后再转回。

Q5. 关于 PDP-11 的混合端（middle-endian）字节序，下列说法正确的有哪些？

多选题 · hard

  • A.32 位数据字间大端← 正确答案
  • B.16 位字内部小端← 正确答案
  • C.该设计仍广泛使用
  • D.与双端切换相同

答案：AB。PDP-11 把 32 位整数按 16 位字拆分，字间大端、字内小端，导致内存序列像 "34 12 78 56" 一样错乱。这种设计早已被淘汰，与 ARM 的整机双端切换也完全不同。

Q6. 在 x86 小端机器上，htonl(0x12345678) 的返回值是？

单选题 · mid

  • A.0x78563412← 正确答案
  • B.0x12345678
  • C.0x34127856
  • D.0x00000001

答案：A。小端机上主机序是 78 56 34 12，htonl 将其转为网络大端序，得到 0x78563412。这相当于把整套书按运输规范重新排列后再装箱。

Q7. 以下哪些场景容易踩到字节序的坑？

多选题 · mid

  • A.跨平台网络通信← 正确答案
  • B.直接发送内存结构体← 正确答案
  • C.读取本地文本文件
  • D.同架构共享内存

答案：AB。跨平台通信和裸结构体发送最容易遇到字节序与对齐问题；单机读文本文件、同架构共享内存通常用同一套字节序，不会出现差异。

Q8. 设计跨平台二进制协议时，推荐的做法包括哪些？

多选题 · hard

  • A.规定字段用网络字节序← 正确答案
  • B.用序列化库统一处理← 正确答案
  • C.直接 memcpy 结构体发送
  • D.加 magic 并做字节序校验← 正确答案

答案：ABD。规范做法是明确统一字节序、用序列化库收敛边界、用 magic 和校验和尽早暴露错序。直接 memcpy 结构体会把填充对齐和编译器布局问题带进协议，属于反面教材。

Q9. 在 PDP-11 中端序机器上，0x12345678 从低地址到高地址的字节序列是？

单选题 · extreme

  • A.12 34 56 78
  • B.78 56 34 12
  • C.34 12 78 56← 正确答案
  • D.56 78 12 34

答案：C。先按 16 位字拆成 0x1234 和 0x5678，字间大端使高字在低地址；每个字内部小端，0x1234 变成 34 12，0x5678 变成 78 56。合并后即为 34 12 78 56。

Q10. 小端序在计算机设计中有什么实用优势？

单选题 · easy

  • A.更符合人阅读习惯
  • B.低位在低址进位方便← 正确答案
  • C.占用内存资源更少
  • D.网络传输速度更快

答案：B。小端序把最低字节放在低地址，CPU 做加法时从低地址取低位、进位自然向高地址扩展，省去移位成本。这也是 x86 长期坚持小端的重要原因。