Magic Number 是文件开头若干字节的固定值，用于可靠识别文件类型；如 JPEG 为 0xFF 0xD8，PNG 为 0x89 0x50 0x4E 0x47，GIF 为 0x47 0x49 0x46，需用二进制模式读取并以 unsigned char 比对。
什么是图片文件的 Magic Number
Magic Number 是文件开头几个字节的固定值，操作系统和工具靠它快速判断文件类型，比扩展名可靠得多。比如 JPEG 文件通常以 0xFF 0xD8 开头，PNG 是 0x89 0x50 0x4E 0x47（即 ASCII 的 \x89PNG），GIF 是 0x47 0x49 0x46（GIF）。C++ 本身不内置识别逻辑，得自己读取、比对、分支处理。
用 std::ifstream 安全读取前 16 字节
不能直接读整个文件，更不能依赖 std::string 或文本模式——二进制文件可能含 \x00，会截断。必须用二进制模式打开，并限制读取长度。
常见错误：用 operator>> 或 getline() 读取，结果读不到 0x00 后的内容；或没检查 failbit 就继续比对。
- 用
std::ifstream file(path, std::ios::binary)打开 - 调用
file.read(buffer, size)，再立刻检查file.gcount() >= N，不能只看good() - 缓冲区建议至少 16 字节（覆盖 PNG/GIF/JPEG/WEBP/BMP 常见头）
- 别用
char数组存魔数——有符号性可能导致0xFF被解释为 -1，比对失败；改用unsigned char或std::uint8_t
常见图片格式 Magic Number 对照与比对写法
硬编码比对最直接，但要注意字节序（所有图片头都是大端，无需转换）和长度匹配。以下是最实用的几组：
立即学习“C++免费学习笔记（深入）”；
// 示例：判断是否为 PNG
if (buf[0] == 0x89 && buf[1] == 0x50 && buf[2] == 0x4E && buf[3] == 0x47) {
return "PNG";
}
// JPEG：支持 SOI（0xFFD8）即可，不依赖后续 marker
if (buf[0] == 0xFF && buf[1] == 0xD8) {
return "JPEG";
}
// GIF：前 3 字节是 "GIF"，第 4–6 字节是版本（"89a" 或 "87a"），但只需前 3 字节就足够区分
if (buf[0] == 0x47 && buf[1] == 0x49 && buf[2] == 0x46) {
return "GIF";
}
// WEBP：RIFF 头 + "WEBP"，位置在 8–12 字节（RIFF header 固定 8 字节）
if (buf[0] == 0x52 && buf[1] == 0x49 && buf[2] == 0x46 && buf[3] == 0x46 &&
buf[8] == 0x57 && buf[9] == 0x45 && buf[10] == 0x42 && buf[11] == 0x50) {
return "WEBP";
}
注意：BMP 头前两字节是 0x42 0x4D（"BM"），但很多工具会误判 ZIP（也是 0x50 0x4B）或 PDF（0x25 0x50 0x44 0x46），所以实际中建议只用于辅助判断，不作为唯一依据。
为什么不能只靠 Magic Number 确定格式
Magic Number 只是初步筛查，不是万能钥匙。真实场景中容易踩坑：
- 某些格式（如 TIFF）有多种字节序（II / MM），头两个字节可能是
0x49 0x49或0x4D 0x4D，单靠前两字节无法区分方向 - 加密或打包过的图片（如游戏资源包里的 .tex）可能加壳，原始 Magic Number 被覆盖
- 损坏文件可能凑巧匹配某个 Magic Number，但后续解析失败
- WebP 和 AVIF 都基于 RIFF，仅靠前 4 字节无法区分，必须继续读 chunk
真正健壮的识别，得结合 Magic Number + 格式规范校验（比如 PNG 的 IHDR chunk 位置、JPEG 的 APP0 marker 是否存在），但那已超出“快速识别”范畴——你只要头几个字节就能筛掉 90% 的非图文件，这就够了。
