文件头（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 Dictionary<string, byte[]> Signatures = 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 是否结构合法）。但它足够快、足够轻，是上传校验、批量扫描、安全拦截的合理起点。
