fread读二进制头需手动处理字节序与对齐，应使用uint8_t数组读原始字节，按需拼接字段，并检查gcount()；跨平台慎用文本模式，验证魔数、偏移与字段逻辑缺一不可。
用 fread 读二进制头必须自己控制字节序和对齐
二进制头不是“格式识别出来就能用”，而是你得先知道它可能含什么字段、多长、怎么排。比如常见 PE 文件头前 2 字节是 0x5A4D（小端下对应字符串 "MZ"），但如果你直接用 int16_t 去读，就可能因平台默认对齐或符号扩展出错。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 一律用
uint8_t数组读原始字节，避免类型隐式转换干扰 - 手动拼字段：比如取第 6–7 字节当 uint16 小端数，写成
(buf[6] | (buf[7] - 别依赖
struct直接fread进去——编译器可能加 padding，不同平台结果不一致 - 头长度不确定时，先读固定最小长度（如 32 字节），再根据已知 signature 判断是否需继续读
Hex 查看器不是“显示十六进制”，而是按块映射内存+实时解码
你看到的左侧地址列、中间十六进制区、右侧 ASCII 区，本质是同一段 uint8_t* 数据的三种视图。关键不在“怎么显示”，而在“怎么加载和跳转”。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 文件不能全载入内存：用
mmap（Linux/macOS）或CreateFileMapping（Windows）做只读映射，支持 GB 级文件秒开 - 滚动时不是重绘整屏，而是计算当前偏移
offset = base_addr + row * 16，再从映射区取 16 字节 - ASCII 栏要过滤控制字符：
isprint(buf[i]) ? buf[i] : '.'，否则乱码或终端异常 - 搜索功能必须用
memmem或手写 KMP——不能转成字符串再strstr，二进制里有 \0
判断未知格式靠 signature + 魔数 + 偏移验证，不是猜文件扩展名
扩展名可伪造，.bin 可能是 ELF，.dat 可能是 PNG。真正可靠的只有魔数（magic number）和结构内自描述字段。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
常见错误现象：
- 读到
0x89504E47（PNG 魔数）却当成普通数据跳过 - PE 文件头中
e_lfanew字段指向的 NT 头偏移超出文件大小，没校验就直接访问导致崩溃 - 把 FAT32 的 BPB（BIOS Parameter Block）中扇区大小字段（2 字节）误当 4 字节解析
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 预置常见魔数表，用
memcmp比对开头若干字节，优先匹配长魔数（如 8 字节的 ELF"\x7fELF"） - 所有偏移类字段（如 PE 的
e_lfanew、PDF 的startxref）必须做边界检查：if (offset - 遇到疑似结构体字段，先查规范文档确认该字段是否允许为 0 或保留值，别一见非零就认为“有效”
std::ifstream 二进制模式读取易踩的三个坑
很多人以为设了 std::ios::binary 就万事大吉，其实 C++ 流在底层仍可能做缓冲、换行转换（极少见）、或 gcount() 返回值不可靠。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 不用
operator>>读原始字节——它会跳过空白、截断 \0；改用read(reinterpret_cast<char>(buf), size)</char> - 每次
read()后立刻检查gcount()，它返回实际读字节数，可能小于请求值（如文件末尾） - 不要混合使用
seekg()和read()后不检查failbit：若 seek 超出范围，后续 read 不报错但gcount()为 0，容易静默失败 - 跨平台时注意：Windows 下文本模式会把 \r\n → \n，即使开了 binary，某些旧编译器 stdio 层仍有残留行为，坚持用
FILE*或系统 API 更可控
真正的难点从来不在“怎么读出来”，而在于“读出来之后信不信它”。同一个字节序列，在不同上下文里可能是长度、标志位、偏移、校验和，甚至就是纯数据。没文档时，唯一靠谱的方式是交叉验证：魔数对上了，关键偏移可访问，结构内字段逻辑自洽——缺一不可。
