二进制文件解析工具

十六进制编辑器里，进制解析一个PNG文件的文件开头永远是 89 50 4E 47 0D 0A 1A 0A。这八个字节不是工具随便定的——它专门设计来检测传输过程中的换行符转换和编码错误。搞二进制解析，进制解析第一件事就是文件扔掉“文件是整体”的思维。文件是工具一串字节，结构靠偏移量和长度定义，进制解析跟搭积木一样。文件

我最早接触这类工具是工具改游戏存档。那会儿用十六进制编辑器手动搜数值，进制解析改金币数量。文件后来发现存档有校验和，工具改一个字节整个文件就废了。进制解析于是文件被迫去读文件格式文档，写脚本自动重算CRC32。工具那个过程让我明白：解析二进制不是“读文件”，是“按规则拆文件”。

偏移量是唯一的地图

文本文件靠换行符分隔，二进制文件靠偏移量定位。比如一个自定义格式的头部：前4字节是魔数，接着2字节是版本号，再4字节是数据区长度。你打开文件，先读前4字节判断类型，对了再往下走。错了？直接报错退出，别浪费时间。

Python的 struct 模块就是干这个的。struct.unpack('<I', data[0:4]) 把4字节小端序转成整数。偏移量必须手动算，offset += 4 这种代码写多了会烦，但比用高级库封装后出问题找不到原因强。我见过有人用现成的解析库读一个变长记录格式，库把长度字段解析错了，他查了两天。手动解析虽然笨，但每一步都看得见。

字节序和数据类型是两大坑

小端序和大端序搞反，读出来的数字能差出几个数量级。x86机器上写的文件通常是小端序，但网络协议和某些嵌入式格式用大端序。有个技巧：如果读出来的数值大得离谱，先怀疑字节序。

数据类型也有陷阱。C语言里的 int 在不同平台可能是2字节或4字节，写格式文档的人经常不标注。我见过一个老式字体文件，字段定义写“short”，实际是2字节有符号，但文档没提符号位。结果字重值超过32767就变成负数，渲染出来完全不对。

浮点数更麻烦。IEEE 754 单精度和双精度混用，读错位置就是天文数字或零。有个音频处理项目，WAV文件的采样率字段被当成整数读，实际是浮点，整段音频变速播放。这种bug不靠逐字节对照根本发现不了。

写解析器比用解析器学得多

现成的库很多：construct、kaitai、binwalk。它们能省时间，但遇到非标准格式就抓瞎。我习惯先用十六进制编辑器手动拆一遍，把每个字段的偏移、长度、含义记在纸上。然后写一个最简解析函数，只输出关键字段。跑通了再考虑封装成类或加错误处理。

一个实用技巧：解析时打印每个字段的原始字节和解析值。比如 print(f"offset { hex(off)}: { data[off:off+4].hex()} -> { val}")。这样出错时一眼就能看出是偏移错了还是解码错了。别嫌输出多，调试二进制问题，日志比断点好用。

还有，别相信文件头里的长度字段。有些文件被截断或填充过，长度字段和实际文件大小对不上。解析时用 min(声明长度, 实际剩余长度) 做保护，不然越界读取轻则报错，重则读到垃圾数据还继续跑。

工具是手的延伸

十六进制编辑器用 010 Editor 或 HxD，带模板功能的那种。模板能高亮字段，但别依赖它——模板写错了你根本不知道。自己写个 Python 脚本，用 mmap 映射大文件，按需读取，比一次性加载快得多。解析几百MB的数据库文件时，内存映射是唯一选择。

最后说个观察：二进制解析的难点不在编程，在找到准确的格式文档。很多私有格式没有公开文档，只能靠逆向。这时候工具链就重要了——binwalk 找嵌入文件，radare2 反汇编，hexdump 看模式。但最可靠的还是人眼加耐心。一个字段一个字段试，试到数据合理为止。这活儿没什么捷径，但搞通一个格式的成就感，比调通十个API都大。

很赞哦!（714）