HTML怎么做文件类型检测_HTML文件MIME类型检测方法【攻略】

HTML 中 files[0].type 不可靠，因其仅基于文件扩展名猜测 MIME 类型；必须通过 FileReader 读取文件头（magic bytes）前端预筛，并由服务端二次校验原始内容。

一个常见的误解是，HTML 本身就能搞定文件类型检测。实际上，input[type="file"] 提供的 files[0].type 属性，不过是浏览器根据文件扩展名“猜”出来的 MIME 类型。这东西，本质上不可信，也绝不能替代基于文件真实内容的检测。

为什么不能只用 files[0].type

这个字段的来源很简单：浏览器读取文件后缀（比如 .jpg），然后去查一张内置的映射表。它压根不会去读文件头。这意味着，用户只要改个后缀名，就能轻松绕过。比如，把 shell.php 改成 shell.jpg，files[0].type 就会变成 image/jpeg，可文件里装的却是 PHP 代码。如果服务端只校验这个字段，那无异于为上传漏洞敞开了大门。

• 无论是 Chrome、Safari 还是 Firefox，它们都不会解析文件内容，.type 纯粹是一个基于客户端的推测值。
• 当文件没有后缀、后缀为空，或者使用了双后缀（如 photo.jpg.php）时，这个字段常常会返回空字符串或者 text/plain。
• 更麻烦的是，不同操作系统下的行为还不一致。比如，Windows 系统可能会把一个 CSV 文件报告为 application/vnd.ms-excel，而 Mac 系统则可能报 text/csv 或 text/plain。

前端用 FileReader.readAsArrayBuffer() 读 magic bytes

那么，前端有没有可靠的办法呢？答案是肯定的。在不发送请求的前提下，唯一可靠的方式就是直接读取文件开头的几个字节，也就是所谓的“magic number”（文件头签名），并与已知的签名进行比对。

• 通常，读取前 12 个字节就足够了：JPEG（以 0xFF 0xD8 开头）、PNG（0x89 0x50 0x4E 0x47）、GIF（0x47 0x49 0x46）、WebP（以“RIFF...WEBP”开头）等常见格式都能判断出来。
• 这里有个关键点：必须使用 readAsArrayBuffer() 方法，而不能用 readAsText()，因为后者会触发编码转换，破坏原始的二进制数据。
• 为了性能考虑，可以用 file.slice(0, 12) 只截取文件头部，这样既能避免大文件阻塞主线程，也能减少内存占用。

function detectMimeType(file) {
  return new Promise(resolve => {
    const reader = new FileReader();
    reader.onload = () => {
      const buf = new Uint8Array(reader.result);
      if (buf[0] === 0xff && buf[1] === 0xd8) resolve('image/jpeg');
      else if (buf[0] === 0x89 && buf[1] === 0x50 && buf[2] === 0x4e && buf[3] === 0x47) resolve('image/png');
      else if (buf[0] === 0x47 && buf[1] === 0x49 && buf[2] === 0x46) resolve('image/gif');
      else 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) resolve('image/webp');
      else resolve('application/octet-stream');
    };
    reader.readAsArrayBuffer(file.slice(0, 12));
  });
}

服务端必须做二次校验，且优先依赖内容探测

前端预筛固然重要，但服务端的二次校验才是最终防线，而且必须优先依赖对文件内容的探测。不同技术栈都有成熟的方案：Node.js 可以用 file-type 库，PHP 用 finfo_file() 函数，Python 则可以结合 mimetypes.guess_type() 和 python-magic 库。核心原则是：必须传入原始的文件内容（或临时文件路径）进行分析，绝不能只看 $_FILES['f']['type'] 或者文件后缀。

立即学习“前端免费学习笔记（深入）”；

• 其实，Linux/macOS 系统下的 file -i 命令，底层原理和前端检测一模一样，都是通过读取 /usr/share/misc/magic 这类文件来匹配 magic bytes。
• 需要警惕的是，PHP 中的 $_FILES['f']['type'] 完全来自 HTTP 请求头里的 Content-Type，这个值可以被 Burp Suite 等工具轻易篡改。
• 所以，即使前端已经做了 magic bytes 校验，服务端也必须重新做一遍。因为文件可能在传输过程中损坏，或者前端的检测逻辑被绕过。

accept 属性只是 UI 提示，不是安全机制

最后，必须澄清一个误区： 里的 accept 属性，仅仅是一个用户体验优化项。它只影响文件选择器弹窗里默认显示哪些类型的文件，而不会限制用户的实际选择（用户依然可以点击“所有文件”来强行选择任何类型）。它既不会阻止用户选择一个 .exe 文件，也不会改变 files[0].type 的值。

• 不同浏览器的行为也有差异：Chrome 在 macOS 上对 accept=".pdf" 可能会过滤掉非 PDF 文件图标，但在 Windows 下基本无效。
• 移动端的 Safari 浏览器甚至会忽略大部分 accept 值，仅支持 image/*、video/*、audio/* 这类通配符。
• 结论很明确：永远不要把 accept 属性当作任何形式的校验依据。它的作用仅限于改善用户体验，降低用户误操作的概率。

总而言之，一套真正可靠的文件类型检测方案，永远需要两层防护：前端进行快速预筛（基于 magic bytes），服务端进行权威判定（基于内容探测）。任何只依赖单侧、仅看后缀名或 HTTP 头的方案，在生产环境中都等同于门户大开，毫无防御可言。