struct.unpack()解包异常主因有三：字节序不匹配（需显式用>、
struct.unpack() 解包时字节序不对导致数值异常
Python struct.unpack() 默认按本机字节序（通常是小端），但 C 程序导出的二进制数据可能固定为大端（如网络协议）或显式指定字节序。若不匹配，int、float 会读成完全错误的值，比如 0x01000000 在小端下被当成了 1，实际应是 16777216。
解决方法：在格式字符串开头显式加字节序符：
-
>表示大端（network byte order），对应 C 的htonl()输出 表示小端，明确声明避免依赖平台-
!等价于>，常用于网络数据 - 省略则用
=（本机序），不推荐用于跨平台解析
例如解析一个大端 uint32_t + float 的结构体：
data = b' ? '<br>result = struct.unpack('>If', data) # (1, 1.0)
处理含 padding 的 C struct 时字段对齐错位
C 编译器会对 struct 成员做默认对齐（如 4 字节对齐），而 struct.pack/unpack 默认不模拟这种对齐——它只按格式字符串逐字节解释。结果就是字段偏移错乱，尤其当结构体里混用 char、int、double 时。
正确做法：启用标准 C 对齐规则，用 @ 或 = 格式前缀 + 显式填充字段：
-
@启用 native size + native alignment（最贴近 GCC 默认行为） - 手动插入
x（空字节）或0s占位符补 padding，更可控 - 用
ctypes定义完整 struct 再用cast转换，适合复杂嵌套结构
示例（C 中 struct { char a; int b; }; 实际占 8 字节）：
# 正确：@ 模拟对齐<br>struct.unpack('@ci', b' ') # ('\x01', 2)<br># 错误：忽略 padding 直接 'ci' → 读到 ' ' 当作 int，值为 0
字符串字段解包后带多余 或乱码
C 风格字符串是 null-terminated 的 char[]，而 struct.unpack('10s', data) 返回的是固定长度 bytes，末尾可能全是 ，直接 decode 会失败或截断。
安全做法：
- 用
bytes.strip(b'\x00').decode('utf-8')清除尾部 null 并解码 - 若协议明确字符串长度（如固定 32 字节），优先用
struct.unpack('32s', data)[0]再处理 - 避免直接用
's'解包可变长字符串；这类字段应单独按 null 截断逻辑处理
注意：'s' 格式不检查 null 终止符，它只是按长度取字节——所以必须知道字段真实长度。
struct.calcsize() 返回值与 C sizeof(struct) 不一致
struct.calcsize(fmt) 只计算格式字符串定义的字节数，不自动考虑 C 编译器的对齐填充。比如 struct.calcsize('ci') 是 5（1+4），但 GCC 下 sizeof(struct {char;c;int i;}) 往往是 8。
关键点：
- 要匹配 C 的
sizeof，必须让 Python 的 format 字符串包含 padding，或用@前缀 -
struct.calcsize('@ci')在多数 x86_64 系统返回 8，和 C 一致 - 跨平台时，不要硬编码 size，始终用
calcsize()动态算，且 format 必须与 C 端 struct 布局严格一致
真正麻烦的是 packed struct（__attribute__((packed))）——此时必须用 = 前缀并手动控制每个字段，否则对齐规则会破坏布局。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
