1. 文件头识别到底是什么时候用的1.1 我什么时候被这件事难住过最早被“根据16进制头文件识文件类型”这件事卡住是在接手一批没有扩展名的备份文件时。目录里躺着几十个 20MB 到 200MB 的.bin文件命名全是backup_20250101_001.bin这种客户只给了需求判断每个文件实际是什么格式然后导入对应系统。我一开始试过根据文件名猜结果猜错三个其中一个其实是 ZIP 压缩包被当成数据库备份导入直接把后续流程带崩了。后来用十六进制编辑器打开文件头看到50 4B 03 04马上对应到 ZIP 魔数再用文件尾特征一确认问题当场解决。另一个常见场景更现实网站上传接口只校验扩展名有人传了一个伪装成.jpg的可执行文件前端显示“上传成功”后端也存下来了。这类问题用文件系统看根本看不出异常必须把文件当二进制流打开看开头几个字节到底是不是图片魔数才能定性。所以“16进制头文件识文件类型”不是冷门知识而是排查问题、数据恢复、安全分析、导出归档时的一线刚需。说人话版本文件头识别就是不看扩展名直接打开二进制文件看前几个字节用固定字节特征判断真实格式。扩展名是“标签”文件头才是“身份证”。这篇文章会把常见格式的魔数整理成表再给你一套可以直接跑的 Python 脚本同时把偏移量、大小端、容器嵌套这些容易踩坑的地方一起说清楚。1.2 “魔数”为什么能当身份证文件格式设计者在定义格式时会在文件开头放一串固定字节用来告诉解析器“我是谁”。比如 JPEG 以FF D8 FF开头PNG 固定八字节89 50 4E 47 0D 0A 1A 0AZIP 固定50 4B 03 04RAR 开头是52 61 72 21也就是 ASCII 的Rar!。这串字节在业内常叫 magic number中文社区叫魔数。不同格式的魔数几乎是互斥的所以它能当第一道筛选条件而且完全不受文件名、扩展名、创建时间这些元数据影响。但要记住魔数不是万能的。它只是“开头第一句话”不是完整内容校验。真实世界里文件头可能被裁剪可能在开头塞了自定义前缀可能本身就是嵌套容器单靠前四个字节会出现误判。所以这篇文章不会只让你背魔数表还会讲怎么结合文件尾、内部特征字符串、容器内文件列表来做二次确认。整体思路是分级识别先看文件头再看结构最后再看内容特征。2. 先记下这20种最常见的16进制文件头2.1 出场率最高的魔数对照表我把日常工作中出现频率最高的文件头整理成了一张表。你不需要一次全部背下来但至少要知道“长什么样、去哪里查”。我把十六进制和 ASCII 对照一起列出方便你用hexdump或任意带 ASCII 栏的十六进制工具核对。文件类型典型文件头十六进制ASCII / 备注JPEGFF D8 FF常见FF D8 FF E0或FF D8 FF E1后跟应用段标识PNG89 50 4E 47 0D 0A 1A 0A第 2~4 字节是PNGGIF47 49 46 38GIF8第 6 字节判断版本 7a/9aBMP42 4DBM老格式也偶见BA、CI等WebP52 49 46 46 ?? ?? ?? ?? 57 45 42 50前四字节 RIFF偏移 8 处WEBPICO00 00 01 00光标格式为00 00 02 00PDF25 50 44 46 2D即%PDF-版本号紧跟其后ZIP50 4B 03 04即PK空的 ZIP 可能是50 4B 05 06RAR452 61 72 21 1A 07 00Rar!后跟版本信息RAR552 61 72 21 1A 07 01 00和 RAR4 前五字节一样第 6 字节不同7z37 7A BC AF 27 1C第 1~2 字节是7zgzip1F 8B 08压缩数据常见后 4 字节可能含 mtimebzip242 5A 68BZhxzFD 37 7A 58 5A 00第 2~6 字节是7zXZELF7F 45 4C 46.ELFLinux 可执行文件/共享库PE / DOS4D 5A即MZ常见于 Windows 可执行文件SQLite53 51 4C 69 74 65 20 66 6F 72 6D 61 74 20 33 00完整 ASCII 是SQLite format 3MP349 44 33ID3无 ID3 时常见裸帧同步FF FBFLV46 4C 56 01FLV后跟版本号WAV52 49 46 46 ?? ?? ?? ?? 57 41 56 45RIFF 容器偏移 8 处WAVEAVI52 49 46 46 ?? ?? ?? ?? 41 56 49 20RIFF 容器偏移 8 处AVI这张表是我自己整理过很多次之后沉淀下来的基础版本。实际使用中建议把“基础类型”和“子类型”分开记忆。比如RIFF本身只是一个容器具体是 WAV 还是 AVI要看第四到第七字节之后也就是偏移 8 处的子类型字符串。2.2 不能只盯偏移 0有些标志藏在文件中间很多人以为“文件头 文件开头第一个字节”但真实文件格式比这复杂。一个经典例子是 tar 归档它的前 257 字节是各个文件的头部信息只有偏移 257 处才出现ustar字符串用来标记这个格式是 POSIX tar。所以做识别的时候必须支持“偏移匹配”不能一律从偏移 0 开始。再看 Windows 的主引导记录文件最开始的 512 字节里有引导代码但55 AA这个标志出现在偏移 510 处。如果只读前两个字节永远识别不到它。还有一些日志导出格式、自定义协议数据会在开头放几字节时间戳或长度字段真正的格式标识藏在偏移 16 甚至偏移 1024 之后。这类情况继续用“前 4 字节等于什么”去套一定会漏。另外有的格式即使偏移是对的也可能因为头部被附加了额外内容而失配。比如 PDF 文件规范允许开头存在多行二进制注释有些工具生成的 PDF 会在%PDF-之前加 BOM 或垃圾字节。这时候要做的不是直接放弃而是“滑窗搜索”在文件头一定范围内查找%PDF-子串。后面第 4 节我会具体讲。2.3 ASCII 可读头与大小端判断用hexdump -C看一个文件头左边是十六进制右边是 ASCII 对照这是我最推荐的习惯。50 4B 03 04右边显示PK..52 61 72 21右边显示Rar!一眼就能认出来不用背。但注意不是所有魔数都是可读字符。PNG 的第一个字节89、ZIP 的03 04、7z 的BC AF 27 1C都是不可见字节纯 ASCII 栏看不出含义必须记十六进制值。大小端问题则是另一个坑。ZIP 头部后面的版本号、通用标志位、压缩方式是 little-endian 存储的。比如文件压缩方式位为00 00表示无压缩08 00表示 deflate但如果按大端读08 00会被理解成 2048整个解析逻辑就崩了。好在做文件类型识别时我们只比固定字节序列不用解析数值字段所以大小端对“魔数匹配”本身影响不大可一旦你想往下解析文件结构必须心里有这根弦。3. Python 实现一个文件头识别脚本3.1 读取前 32 字节识别脚本第一步很朴素读文件开头 N 个字节。为什么是 32 而不是 2 或 8因为大部分格式的魔数不超过 8 字节但我们需要为后续扩展留空间。比如 ZIP 的加密标志位于第 6、7 字节想判断它是不是加密压缩读 32 字节就能覆盖SQLite 完整魔数有 16 字节很多自定义格式需要看前 24 字节。综合下来第一轮读取 32 字节是比较合适的平衡点既不会把大文件加载进内存也能覆盖绝大多数特征。from pathlib import Path def read_head(file_path, n32): 读取文件前 n 字节权限不足或文件不存在时返回空字节串 try: with open(file_path, rb) as f: return f.read(n) except OSError as exc: print(f[skip] {file_path}: {exc}) return b读写二进制文件一定用rb模式不要用r文本模式否则文件内容会被尝试解码遇到非 UTF-8 字节直接报错。read(32)这种写法也保证了不会因为文件巨大而内存爆炸两千兆的文件也只读开头 32 字节这是做批量扫描时性能预算最友好的操作。3.2 魔数表怎么设计魔数表不要写成一长串 if-else维护起来太痛苦。我习惯用“名称 魔数字节串 偏移量”的元组列表对照起来非常清晰MAGIC_TABLE [ (JPEG, b\xFF\xD8\xFF, 0), (PNG, b\x89PNG\r\n\x1a\n, 0), (GIF, bGIF8, 0), (BMP, bBM, 0), (PDF, b%PDF-, 0), (ZIP, bPK\x03\x04, 0), (ZIP_EMPTY, bPK\x05\x06, 0), (RAR4, bRar!\x1a\x07\x00, 0), (RAR5, bRar!\x1a\x07\x01\x00, 0), (7Z, b7z\xbc\xaf\x27\x1c, 0), (GZIP, b\x1f\x8b\x08, 0), (BZIP2, bBZh, 0), (XZ, b\xfd7zXZ\x00, 0), (ELF, b\x7fELF, 0), (PE, bMZ, 0), (SQLITE, bSQLite format 3\x00, 0), ] def match_magic(head, magic, offset0): if offset len(magic) len(head): return False return head[offset:offset len(magic)] magic def classify_head(head): if not head: return EMPTY for name, magic, offset in MAGIC_TABLE: if match_magic(head, magic, offset): return name return UNKNOWN有一个必须处理的细节某些魔数存在包含关系。比如MZ既可能是 PE 可执行文件也可能是纯 DOS 可执行文件继续往下看第 0x3C 偏移处指向的 PE 头才能区分。再比如RIFF是通用容器光匹配到RIFF不能直接说它是 WAV。所以真正的分类函数里要比对子类型字符串或者把容器类格式放到后面的二次判断中处理。3.3 批量扫描目录并识别扩展名伪装批量扫描目录是文件头识别最常用的形式。直接上代码EXT_TO_TYPE { .jpg: JPEG, .jpeg: JPEG, .png: PNG, .gif: GIF, .bmp: BMP, .pdf: PDF, .zip: ZIP, .rar: RAR4, .7z: 7Z, } def scan_dir(root): result [] for p in Path(root).rglob(*): if not p.is_file(): continue head read_head(p, 32) detected classify_head(head) real_ext p.suffix.lower() expected EXT_TO_TYPE.get(real_ext, ) remark if expected and expected ! detected: remark MISMATCH elif detected UNKNOWN: remark UNKNOWN_TYPE result.append((str(p), detected, real_ext, remark)) return result这里输出的是一个列表你可以直接转 CSV。MISMATCH的意思是说扩展名预期是 JPEG但文件头识别出的类型不是 JPEG这种文件大概率被改了扩展名或者文件头本身损坏。要注意不匹配不代表一定是恶意文件也可能是业务系统自动重命名所以扫描脚本只要把“可疑”标出来不要自动改文件名。3.4 编码细节和异常处理写这个脚本时最容易翻车的是字节串和普通字符串混用。b\xFF\xD8\xFF是字节串\xFF\xD8\xFF是普通字符串两者不能互相比较。Python 里bPNG合法b{:c}这种格式化方式也别乱用。魔数表里全部统一写成bytes类型读取函数也用rb就不会有编码问题。空文件要单独处理head是b不要拿去和魔数比较直接返回EMPTY。权限不足时会抛PermissionError所以读取函数要把OSError捕获住。符号链接文件在Path.rglob里可能出现重复访问如果遇到循环链接要加try/except或在遍历时跳过符号链接。最后把所有异常都打印到日志而不是终端方便排错。4. 比文件头更可靠的辅助信息4.1 从文件尾和中间偏移找补充特征文件头能确定“开场白”文件尾能确定“结束语”两者结合准确率会高很多。常见文件尾特征如下PNG 的 IEND 块是49 45 4E 44 AE 42 60 82PDF 经常以%%EOF结尾ZIP 在文件末尾有50 4B 05 06的中央目录结束标记。读取文件尾部也要小心不能直接读最后 n 字节要先seek到文件尾部前面def read_tail(file_path, n64): try: with open(file_path, rb) as f: f.seek(0, 2) size f.tell() pos max(0, size - n) f.seek(pos) return f.read() except OSError as exc: print(f[skip] {file_path}: {exc}) return b def classify_with_tail(file_path): head read_head(file_path, 32) tail read_tail(file_path, 64) base classify_head(head) if base PNG and tail.rfind(b\x49\x45\x4E\x44\xAE\x42\x60\x82) ! -1: return PNG if base PDF and b%%EOF in tail: return PDF return base实际中文件头被截断但尾部完好的情况很常见。比如一个人用十六进制编辑器删掉了某个文件开头几个字节扩展名还是.png只读头会变成UNKNOWN但文件尾还留着 PNG 的 IEND 块结合中间是否有 IDAT 块就能大概率推断它原来是 PNG。当然这种推断要标注为“猜测”不能当成百分百结论。4.2 文本文件怎么识别文本文件没有固定魔数但同样有规律可循。第一看 BOMUTF-8 的 BOM 是EF BB BFUTF-16 LE 是FF FEUTF-16 BE 是FE FF。第二看首行关键字XML 声明以?xml开头HTML 常见!DOCTYPE html或htmlJSON 多数以{或[开头。第三看 shebangLinux 脚本第一行常有#!比如#!/bin/bash、#!/usr/bin/python3。def sniff_text(head): if head.startswith(b\xef\xbb\xbf): return UTF8_TEXT if head.startswith(b\xff\xfe): return UTF16LE_TEXT if head.startswith(b\xfe\xff): return UTF16BE_TEXT head_clean head.lstrip() if head_clean.startswith(b?xml): return XML if head_clean.startswith(b!DOCTYPE html) or head_clean.startswith(bhtml): return HTML if head.startswith(b#!): return SHELL_SCRIPT if head.startswith(b{) or head.startswith(b[): return JSON_LIKE return PLAIN_TEXT_CANDIDATE注意head.lstrip()对二进制数据也可以它会去掉开头所有空白字节因为这些空白在文本文件里通常不影响判断。但不要对 PDF、PNG 这类二进制格式做 lstrip否则容易把特征弄丢。4.3 嵌套容器要拆开看文件头识别最迷惑人的案例就是“头不对形”。一个扩展名是.docx的文件用十六进制打开后看到的其实是50 4B 03 04也就是 ZIP 头。为什么因为 Office Open XML 格式本质上就是 ZIP 容器内部再放 XML 和媒体文件。同理EPUB、JAR、APK 也都是 ZIP 容器。只看文件头只能判断它们是“ZIP”不能继续细分。这时需要打开容器看内部文件列表做一个“二次识别”import zipfile def detect_zip_subtype(file_path): try: with zipfile.ZipFile(file_path) as zf: names [n.lower() for n in zf.namelist()] except zipfile.BadZipFile: return BAD_ZIP if [content_types].xml in names: if any(n.startswith(word/) for n in names): return DOCX if any(n.startswith(xl/) for n in names): return XLSX if any(n.startswith(ppt/) for n in names): return PPTX return OOXML_ZIP if mimetype in names: return EPUB_OR_OEBPS if meta-inf/manifest.mf in names: return JAR_OR_APK return ZIP同理RIFF 容器内部由子类型字符串区分 WAV、AVI、WebPOLE2 容器内部则要看目录流的名字区分老版本 doc、xls、ppt。碰到这类格式仅靠“文件头识别”只是完成第一层真正准确的结论需要做容器解析。4.4 熵值看通道加密压缩的旁证文件头只能告诉你“外壳是什么”看不出内部数据的状态。一个正常的 ZIP 包和一个加密的 ZIP 包魔数一模一样。这时候有一个辅助指标信息熵。未压缩的文本熵通常比较低压缩或加密后的数据熵接近每字节 8 bit。import collections, math def entropy(data): if not data: return 0.0 counter collections.Counter(data) length len(data) ent 0.0 for count in counter.values(): p count / length ent - p * math.log2(p) return ent这只是一个旁证。比如一个文件头显示是 ZIP但内部所有文件名的熵值极低内容熵值极高说明它很可能是一个加密压缩包或者里面全被压缩过。如果熵值很高但没有任何压缩工具能正常解压那就要怀疑文件是不是被改成无意义随机数据了。不要把熵值当唯一结论只把它当成“要不要人工介入复查”的信号。5. 常见问题与排查技巧实录5.1 明明文件头正确为什么还是识别错我见过最多的误判有这几种第一文件头被截断。文件损坏或被不完整下载时可能只有前两个字节FF D8没有完整的FF D8 FF。我的做法是遇到这种“短匹配”输出JPEG_PARTIAL并继续检查文件尾避免直接下结论。第二魔数表顺序不对。我的表是有优先级顺序的PK\x03\x04必须排在PK前面否则看到 ZIP 头会被先匹配成PK。同样RAR4和RAR5前五字节一样要先匹配长的那个。第三容器冲突。前面说过RIFF、ZIP、OLE2都可能代表多种真实格式。如果只按第一层匹配满目录的 WAV 和 AVI 都会变成RIFF。解决办法是在classify函数里做“二级跳转”用子类型字符串精确区分。排查时第一件事是打印原始字节print(file_path, head.hex( ), head[:16])bytes.hex( )能把head转成带空格分隔的十六进制字符串方便对照文档。这条命令我在现场排查时几乎天天用比人脑记忆靠谱得多。5.2 大小端和版本号导致的魔数偏差我遇到过一个典型问题一个 RAR 文件开头是52 61 72 21 1A 07 01 00我想当然用 RAR4 的魔数去匹配结果死活匹配不上。后来查了文档才知道RAR5 在第 6 字节从00变成了01所以光记“Rar!”五个字节不够必须连版本位一起判断。大小端问题在 RIFF 容器里尤其明显。WAV 文件头第七到第十字节是文件大小以 little-endian 存储。比如52 49 46 46 24 08 00 00这里的24 08并不是十六进制数 0x2408而是 little-endian 的 0x0824等于 2084。如果你用大端去读解析出来的尺寸会完全错误。这类问题不是魔数本身错是后续解析逻辑错但很容易被误归结为“文件头对不上”。建议在代码里写清楚字节序必要时用struct.unpack(I, data[4:8])这种显式解包。5.3 伪装扩展名到底要不要自动改我的经验是不要自动改。就算魔数明确告诉你它是 PNG但扩展名是.jpg也最好不要写个循环把所有文件批量重命名成识别结果。原因有三点一是同名扩展名可能有多种合法子类型。.bin、.dat、.tar都是典型的“万能扩展名”内部可能是任何东西。改成.png只对了外壳可能影响后续业务。二是同一份文件可能同时属于多种格式。比如一个 EPUB 文件你既可以说它是 ZIP也可以说它是 EPUB还可以说它是 OOXML 容器不同系统需要的扩展名不同。三是自动改名具有不可逆性一旦改错原始扩展名就丢了。除非你能拷到新文件别动源文件。更好的做法是导出一个“建议名”字段比如photo_001.png但实际执行改名之前先出一份 dry-run 清单给人确认。批量操作脚本里--dry-run参数一定要保留。5.4 大批量文件的性能细节识别脚本本身很轻但文件数量大了之后容易遇到两类问题遍历慢和读文件慢。Path.rglob(*)很好用但会在深层目录里反复stat如果目录层级特别深性能急剧下降。更稳妥的是用os.scandir自己写迭代器或者先限制文件大小比如只处理 100MB 以内的文件超过直接跳过。读取文件只读前 32 字节和尾部 64 字节绝不调用read()把全部内容装进来。对于几十万个文件的目录串行扫描通常已经够用是不是用多进程需要看你的瓶颈在 I/O 还是 CPU。文件头匹配本身不消耗 CPU所以多进程收益不大反而增加上下文切换开销。我最后把结果直接写入 CSV 而不是 print 到终端否则几十万条输出会把终端卡死。6. 把这些整合成随手可用的脚本工具6.1 从函数到命令行工具当函数写完后下一步是做成命令行工具。用标准库argparse就能实现不需要引入额外依赖。核心用法是传入一个文件或目录可选--csv参数把结果输出到文件。import argparse import csv import sys from pathlib import Path def main(): parser argparse.ArgumentParser(description基于16进制文件头识别文件类型) parser.add_argument(path, help文件或目录路径) parser.add_argument(--csv, default, help输出到CSV文件) parser.add_argument(--dry-run, actionstore_true, help只输出不修改) args parser.parse_args() target Path(args.path) rows [] if target.is_dir(): rows scan_dir(target) elif target.is_file(): rows scan_one(target) else: print(路径不存在, filesys.stderr) return 1 if args.csv: with open(args.csv, w, newline, encodingutf-8) as f: writer csv.writer(f) writer.writerow([path, detected_type, ext, remark]) writer.writerows(rows) else: for row in rows: print(\t.join(row)) return 0 if __name__ __main__: sys.exit(main())你还可以加一个--hex参数在每个输出行附上文件前 16 字节的十六进制值这样即使识别结果不对也能立刻人工检查。命令行没有输出图片、表格这些花哨功能但胜在稳定、可脚本化、可定时跑。6.2 我的几个“后悔没早知道”的经验第一个经验是永远先看原始十六进制再下结论。有一次脚本报UNKNOWN我把文件头打印出来一看开头是89 50 4E 47分明是 PNG但脚本匹配失败。原因是文件被处理成了文本模式b\x89PNG被当作 Unicode 解码污染了。这类问题如果不上来看原始字节光看报错信息很难查到。第二个经验是魔数表要单独建模块不要和业务逻辑写在一起。文件格式在持续演进新版本可能调整头部结构把这些数据放在一个magic_table.py里改起来非常快。RAR5 出来后我只需要在表里加一条主逻辑一行不用动。第三个经验是先定“unknown”语义。我的脚本有三种未知状态EMPTY表示空文件UNKNOWN表示前缀匹配失败PARTIAL表示匹配到了部分魔数但长度不够完整。把这三者分开后排查效率大幅提升。之前混在一起看到UNKNOWN根本不知道是文件坏了还是格式真不认识。6.3 后面还能怎么扩展这套“文件头识别 容器拆包 文件尾校验 熵值旁证”的流程天然能延伸到更多方向。比如做安全审计时把扫描结果接入告警系统凡是扩展名与文件头不一致的文件全部进入高风险队列做数据恢复时扫描损坏磁盘导出的大块数据利用魔数定位文件起点再结合文件尾估算恢复边界做后端上传校验时服务端读前几个字节判断真实类型比只信任浏览器传的Content-Type可靠得多。还有一个方向是自定义格式识别。音频、视频、图片格式的规范在不断更新如果你有自己定义的封包格式完全可以在魔数表里加一行自定义魔数。只要你的格式规范里写了固定头部这套东西就能识别。踩过几次坑之后我现在的习惯是手边常备一个“打印文件头”的小脚本无论遇到什么问题先把hex(head)打出来再对照魔数表。识别脚本只是辅助真正下结论前一定要看原始字节。尤其是当你面对的是.bin和.dat那一堆无从下手的文件时能稳定输出 JPEG、PDF、ZIP 的魔数表会让你少很多头疼。