文件头(Magic Number)是文件开头若干字节的固定二进制签名,由格式规范定义,真实反映文件内容;而扩展名可随意修改,无校验意义。

什么是文件头(Magic Number)?为什么不能只看扩展名
文件扩展名可以随意修改,毫无校验意义;而文件头是文件开头若干字节的固定二进制签名,由格式规范定义,真实反映文件内容。比如 .jpg 文件通常以 0xFF 0xD8 开头,.png 是 0x89 0x50 0x4E 0x47(即 ASCII 的 "\x89PNG")。C# 中读取文件前几个字节比对预设签名,才是验证“它真是个 PNG”的可靠方式。
用 FileStream + byte[] 读取前 16 字节做基础判断
大多数常见格式的 Magic Number 长度 ≤ 12 字节,读取前 16 字节足够覆盖。注意必须用二进制方式打开,避免编码干扰:
byte[] header = new byte[16];
using (var fs = new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.Read, 4096, FileOptions.SequentialScan))
{
_ = fs.Read(header, 0, header.Length); // 忽略返回值不安全,实际应检查
}- 务必设置
FileOptions.SequentialScan提升小读取性能 -
fs.Read()可能返回少于请求长度(如文件不足 16 字节),需用返回值判断实际读取长度 - 不要用
File.ReadAllBytes()—— 对大文件浪费内存且无必要
常见格式 Magic Number 映射表与匹配逻辑
硬编码比对易出错,建议封装为只读字典。注意:部分格式有多个合法签名(如 ZIP 和 DOCX/EPUB 共享 PK\x03\x04),需结合上下文或更多字节判断:
private static readonly DictionarySignatures = new() { ["jpg"] = new byte[] { 0xFF, 0xD8 }, ["png"] = new byte[] { 0x89, 0x50, 0x4E, 0x47 }, ["pdf"] = new byte[] { 0x25, 0x50, 0x44, 0x46 }, // "%PDF" ["zip"] = new byte[] { 0x50, 0x4B, 0x03, 0x04 }, // "PK\x03\x04" ["exe"] = new byte[] { 0x4D, 0x5A }, // "MZ" };
- 字节数组顺序必须严格匹配,
SequenceEqual()是安全比对方式 - PDF 的
%PDF是 ASCII,直接写十六进制更直观、无编码歧义 - ZIP 签名也匹配 DOCX/XLSX,若需区分,得继续读取中央目录偏移等字段
实际使用时容易忽略的边界情况
真实场景中,文件可能损坏、权限不足、路径为空,或签名位于非首字节(如某些嵌入式固件)。简单封装函数需主动防御:
- 先检查
File.Exists(path)和可读性,避免UnauthorizedAccessException - 读取长度取
Math.Min(16, (int)fs.Length),防止EndOfStreamException - 对空文件(
Length == 0)直接返回null或"unknown" - 不依赖
Path.GetExtension()做 fallback —— 那会回到“看扩展名”的老路
Magic Number 判断只是第一层过滤,无法替代完整解析(比如确认 PNG 是否结构合法)。但它足够快、足够轻,是上传校验、批量扫描、安全拦截的合理起点。









