Java获取文件MIME类型：无扩展名时probeContentType/Tika识别异常

问题背景 #

• 对JDK原生Files.probeContentType(path)方法的初始认知：可在不依赖文件扩展名的前提下识别文件MIME类型
• 实际测试现象：
  • 手动移除Nature.jpg文件的扩展名后，方法返回值为null
  • 仅当文件携带正确扩展名时，才会返回正确的image/jpeg类型
  • 初始预期：无论文件是否带有扩展名，方法都能识别出image/jpeg类型
• 补充测试（Apache Tika v2.4）：
  测试代码：

  Tika tika = new Tika();
  String myType = tika.detect(filePath);
  

  测试现象：文件无扩展名时，方法返回application/octet-stream，未识别出实际的JPEG图片格式。

原因说明 #

1. 对Files.probeContentType的认知偏差 #

该方法的官方API文档从未承诺会通过读取文件内容（魔数/文件头特征）实现无扩展名的类型识别，它的默认实现完全依赖当前运行平台的内置类型检测规则：

• Windows平台默认通过注册表的扩展名-MIME映射表匹配类型，全程不读取文件内容，无扩展名时自然返回null
• macOS平台默认依赖UTI（统一类型标识符）体系做匹配，优先级最高的判断依据同样是文件扩展名
• Linux平台下默认调用系统原生的文件类型检测工具（如GNOME的gio），仅在部分配置完整的场景下会读取文件头，缺少对应MIME规则时无扩展名文件同样识别失败

如果需要JDK原生实现基于内容的类型检测，需要自行实现FileTypeDetector的SPI接口，写入自定义的文件头匹配逻辑，没有开箱即用的无扩展名识别能力。

2. Tika识别失败的核心原因 #

调用的tika.detect(filePath)方法默认优先匹配文件名扩展名，无扩展名时才会触发内容探测逻辑。出现返回application/octet-stream的问题，几乎都是因为依赖引入不全：
Tika核心包（tika-core）仅包含最基础的检测框架逻辑，覆盖全类型的文件头魔数匹配规则都封装在tika-parsers-standard-package模块中。如果项目中只引入了tika-core依赖，没有引入完整的解析器包，内容探测阶段就会因为匹配不到任何特征规则，直接回退到通用二进制流类型application/octet-stream。

修复方案 #

针对Tika的识别问题，只需要在项目中引入和当前Tika版本匹配的标准解析器依赖即可，以Maven为例：

<dependency>
    <groupId>org.apache.tika</groupId>
    <artifactId>tika-parsers-standard-package</artifactId>
    <version>2.4.0</version>
</dependency>

依赖引入完成后，即使文件没有扩展名，Tika也会读取文件开头的固定魔数（JPEG格式文件开头固定为FF D8 FF字节标识），正确识别出image/jpeg类型。如果不想引入完整解析器包带来的冗余依赖，也可以直接调用tika.detect(InputStream stream)重载方法传入文件输入流，强制触发基于内容的检测，但前提还是需要项目中包含对应文件类型的魔数匹配规则。

内容的提问来源于stack exchange，提问作者Ashar