在处理二进制数据时，字节序是一个绕不开的话题。网络协议通常规定使用大端序（Big-Endian）传输多字节数值，而常见的x86、x64架构机器内部使用小端序（Little-Endian）。当两端的字节序不一致时，如果不做转换，接收方解析出的数值就会完全错乱。Ruby 为此提供了 pack 和 unpack 这对方法，其中 n、N、v、V 四个指令专门用于指定字节序的整数转换，是网络编程和二进制文件解析中非常实用的工具。
一、什么是网络字节序，为什么需要转换
字节序指的是多字节数据在内存中的存放顺序。以32位整数 0x12345678 为例，大端序会把最高字节 0x12 放在最低地址处，也就是 12 34 56 78 的顺序；小端序则正好相反，存放为 78 56 34 12。大端序符合人类的阅读习惯，也被称为网络字节序，因为 TCP/IP 协议族规定所有协议头部中的多字节字段都使用大端序传输。
问题在于，程序运行所在的 CPU 架构决定了本地字节序。x86 架构是小端序，而早期的 PowerPC、如今的多数 ARM 设备（以小端模式运行）情况各异。如果你的程序直接把本机内存中的整数字节发送到网络，对方按大端序解析，数值就会出错。例如本机小端序下的 1（四字节为 01 00 00 00）被网络对端按大端序解读，就变成了 16777216，完全不是预期的值。
因此在发送前需要将主机字节序转换为网络字节序，接收后再转换回来。C 语言提供了 htons、htonl 等函数完成这件事，而 Ruby 中对应的方案就是 Array#pack 与 String#unpack 配合 n、N、v、V 指令，无需关心本机到底是什么字节序，指令本身就规定了输出或输入的字节顺序。
二、n、N、v、V 四个指令的含义与基本用法
这四个指令都是处理无符号整数的，区别在于字长和字节序。n 表示16位大端序无符号整数（network order，对应 C 语言的 uint16_t 网络序），N 表示32位大端序无符号整数（uint32_t 网络序），v 表示16位小端序无符号整数（VAX order），V 表示32位小端序无符号整数。可以用一句话帮助记忆：大写的是32位，小写的是16位；n 和 N 是大端序（网络序），v 和 V 是小端序。
pack 是把数组打包成二进制字符串，unpack 则是把二进制字符串解包成数组。看一个直观的例子：
# 打包：整数 -> 字节串
puts [1].pack("n").unpack("H4") # => "0001" 大端序16位
puts [1].pack("v").unpack("H4") # => "0100" 小端序16位
puts [1].pack("N").unpack("H8") # => "00000001" 大端序32位
puts [1].pack("V").unpack("H8") # => "01000000" 小端序32位
# 解包：字节串 -> 整数
puts "\x00\x01".unpack("n") # => [1]
puts "\x00\x01".unpack("v") # => [256]
# 端到端转换示例
data = [8080].pack("n") # 发送前打包为大端序
port = data.unpack("n").first # 接收后解包 => 8080
可以看到，同一份字节 \x00\x01 用 n 解出来是 1，用 v 解出来是 256，字节序的影响一目了然。还要注意一点：n 和 v 得到的是1字节对齐的2字节结果，而 C 指令（如 pack("S")）的结果取决于本机字节序，代码在不同机器上可能表现不同。所以凡是涉及网络传输或跨平台文件格式的场景，都应该显式使用 n、N、v、V，而不是依赖本机字节序的指令。
另外一个细节是返回值类型。n、v 返回 Integer（16位范围 0 到 65535），N、V 返回 0 到 4294967295 范围的 Integer。这四个指令本身不处理符号位，如果协议中定义的是有符号整数，需要解包后自行换算，比如 32 位有符号值可以用 unpack("l>") 或手动计算 v >= 0x80000000 ? v - 0x100000000 : v。
三、实际应用场景与综合示例
1. 解析网络协议头部
以一个简化版的自定义协议为例：头部包含2字节大端序的消息类型、4字节大端序的消息长度，随后是消息体。用 unpack 的组合格式串可以一次性解析：
def parse_packet(data)
type, length, body = data.unpack("nNa*")
{ type: type, length: length, body: body }
end
# 构造响应：类型2，长度5，消息体 "hello"
resp = [2, 5, "hello"].pack("nNa*")
puts resp.unpack("nNa*")
# => [2, 5, "hello"]
格式串 "nNa*" 表示依次取出一个16位大端整数、一个32位大端整数和剩余全部字节，这比逐字节切片再拼接要简洁得多，也避免了手工移位的错误。
2. 读写二进制文件格式
许多二进制文件格式（例如 BMP 位图的文件头、各种游戏资源格式）明确规定了字节序。BMP 文件头前两个字节是签名 "BM"，随后的文件长度字段是小端序32位整数，正好可以用 v、V 指令解析：
header = File.binread("test.bmp")[0, 14]
sig, filesize, _r1, _r2, offset = header.unpack("a2Vv2V")
puts "签名: #{sig}, 文件大小: #{filesize}, 像素数据偏移: #{offset}"
这里 a2 取2个原始字节作为字符串，V 读取小端序32位整数，v2 一次读取两个16位保留字段。使用 binread 很重要，它保证以二进制模式读取，避免 Windows 上换行符被自动转换破坏数据。
3. 生成测试数据与固定长度的数值编码
在构造测试报文或实现简单序列化时，pack 同样好用。例如把一个时间戳和序号编码成固定8字节的数据：
ts = Time.now.to_i
seq = 12345
frame = [ts, seq].pack("Nv") # 4字节时间戳 + 2字节序号
puts frame.bytesize # => 6
由于 pack 输出的字节数完全由格式串决定，生成的报文长度是可预期的，这对实现定长协议、填充协议字段非常友好。需要注意 pack 时如果整数超出指令的表示范围，Ruby 会抛出 RangeError，因此打包前最好对数值范围做校验。
四、常见坑点与相关指令对比
第一个坑是混淆大小写。n 和 N 只差一个字母，一个16位一个32位，混用后解包值看似正常却数量级不对，排查起来很隐蔽。建议在代码中用常量或注释标明格式串的含义，例如 HEADER_FMT = "nN"，提高可读性。
第二个坑是忽略了本机字节序指令的存在。s、S、l、L 等指令按本机字节序处理数据，在 x86 机器上测试通过，换到大端机器上结果就变了。而 n、N、v、V 的行为在任何平台上都一致，这正是它们存在的意义。另外，Ruby 还支持带方向的写法：s>、l> 表示大端序，s<、l< 表示小端序，q>、Q> 支持64位整数，功能上与 n、N、v、V 有重叠但覆盖范围更广，需要64位数值时必须用 Q> 或 Q<。
最后提一个实用技巧：配合 H 指令可以快速查看二进制数据的十六进制形式，data.unpack1("H*") 是调试二进制报文的常用手段；而 [n].pack("H*") 的反向操作 hex.unpack("a2"*8) 等组合也能完成灵活的字节处理。掌握 pack/unpack 的思维模型——格式串描述内存布局，数据在数组和字节串之间按布局流动——之后，处理任何二进制格式都会变得得心应手。
Ruby pack unpack网络字节序字节序转换修改时间：2026-08-31 13:17:08