跳转到主内容
极星编程网:以代码为星,赴技术山海!

C#获取文件MIME类型 C#如何根据文件扩展名或内容得到MIME Type

推荐使用 MimeTypes.Core 等第三方库实现跨平台 MIME 类型推断,它支持扩展名查表与文件头 magic bytes 双重检测,兼顾准确性与性能,避免 Windows API 依赖和内置 MediaTypeNames 的覆盖不足问题。 用
System.Net.Mime.MediaTypeNames
查扩展名映射(简单但不准确) .NET 内置的
MediaTypeNames
类只提供少量常见扩展名到 MIME 的静态映射,比如
MediaTypeNames.Image.Jpeg
对应
"image/jpeg"
,但它 不支持动态查扩展名 ,也没有内置函数把
".png"
转成
"image/png"
。 实际项目中直接靠它做判断会漏掉大量格式(如
".webp"
、
".avif"
、
".md"
),甚至返回空或错误值。它更适合写死已知类型,而非通用检测。 如果只是快速原型且只处理
.jpg
/
.pdf
/
.txt
这类经典后缀,可手动建个字典:
var extToMime = new Dictionary { [".jpg"] = "image/jpeg", [".jpeg"] = "image/jpeg", [".png"] = "image/png", [".pdf"] = "application/pdf", [".txt"] = "text/plain" }; string mime = extToMime.GetValueOrDefault(Path.GetExtension(filePath).ToLowerInvariant(), "application/octet-stream");
用 Windows API
FindMimeFromData
(仅 Windows,需 P/Invoke) 这是 Windows 系统级的 MIME 推断函数,会读取文件头(前 256 字节)分析内容,比纯扩展名可靠得多,比如能区分
.bin
和
.exe
,也能识别无扩展名或扩展名被篡改的文件。 但注意:
FindMimeFromData
已标记为 deprecated,且在 .NET Core/.NET 5+ 中默认不可用,需手动 P/Invoke,并依赖
urlmon.dll
—— 这意味着它 不能跨平台 ,Linux/macOS 下直接抛
DllNotFoundException
。 使用要点: 传入的 buffer 长度建议 ≥ 256 字节;小于 256 可能误判(如某些 XML 文件需看到
) 第三个参数
pszUrl
可传
null
,但若传了带扩展名的 URL,系统会优先按扩展名 fallback,削弱内容检测效果 返回的 MIME 字符串末尾可能带空格或换行,记得
.Trim()
用第三方库
MailKit
或
MimeTypes
(推荐跨平台方案)
MimeTypes
(NuGet 包
Humanizr.MimeTypes
或更轻量的
MimeTypes.Core
)是目前最省心的选择:纯 C# 实现、无平台依赖、支持 1000+ 扩展名 + 常见 magic bytes 检测。 示例(以
MimeTypes.Core
为例): C知道 CSDN推出的一款AI技术问答工具 下载
var mime = MimeTypes.GetMimeType("document.pdf"); // → "application/pdf" mime = MimeTypes.GetMimeType("unknown", File.ReadAllBytes(filePath)); // 读内容推断
它内部做了两层 fallback:先查扩展名,再读文件头比对签名(magic number)。比如
.jpg
文件即使被改成
.dat
,只要开头是
FF D8 FF
,仍能返回
"image/jpeg"
。 注意点: 不要对大文件全量读取再传入 —— 它的
GetMimeType(string filename)
重载会自动打开文件并只读前几百字节 若自己传 byte[],务必限制长度(通常 ≤ 1024 字节足够),否则影响性能 某些边缘格式(如新版
.heic
)可能未覆盖,可手动注册补充 自研 magic bytes 检测(适合定制化或规避依赖) 如果项目禁止引入第三方包,又需要比扩展名更准的结果,可以手写一个轻量 content-based 检测器。核心是维护一个
(byte[], offset, mime)
列表,按匹配优先级排序。 例如判断 PNG:
if (bytes.Length >= 8 && bytes[0] == 0x89 && bytes[1] == 0x50 && bytes[2] == 0x4E && bytes[3] == 0x47 && bytes[4] == 0x0D && bytes[5] == 0x0A && bytes[6] == 0x1A && bytes[7] == 0x0A) { return "image/png"; }
常见陷阱: UTF-8 BOM(
EF BB BF
)和 ASCII 文本容易混淆,
text/plain
应放在最后 fallback,否则会盖掉
text/html
或
application/json
ZIP 系列(
.jar
、
.docx
、
.xlsx
)共享同一 magic(
50 4B 03 04
),得靠扩展名二次判断 部分格式头部有可变字段(如 PDF 的
%PDF-
版本号位置不固定),要用
IndexOf
而非固定 offset 真正可靠的 MIME 判断永远需要权衡:扩展名快但假,内容检测准但慢且有盲区。生产环境建议用
MimeTypes.Core
这类成熟小库,它把 magic bytes 覆盖率、fallback 逻辑和边界 case 都收口了,比自己拼凑更稳。

相关文章