Java EWS附件场景下如何检测被伪装为.xls的HTML文件

问题根因 #

你之前遇到的Tika识别失效问题，并非Tika本身无法识别HTML格式，而是流的特性导致的检测失效：

• 本地java.io.File场景下，Tika会基于文件的随机访问能力，完整读取文件头部的特征字节序列，准确匹配HTML的内容签名（比如<html、<!DOCTYPE html等标志性字节），因此能正常识别出真实的text/html类型。
• EWS-Java-API返回的FileAttachment.getContentStream()是基于远程网络拉取的原始传输流，本身不支持mark/reset流重置操作。Tika在做类型探测时需要读取流头部的特征字节，读取完成后需要将流指针重置回初始位置才能完成后续的匹配逻辑；一旦遇到不支持重置的流，Tika会直接兜底返回application/octet-stream，导致检测失效。
• FileAttachment.getContentType()返回的值完全来自邮件发送方在MIME头中自行声明的内容，遇到故意将HTML文件标记为Excel类型的场景，这个值没有任何参考价值。

可落地方案 #

Tika完全可以适用于这个场景，只需要解决原始网络流不可重复读、不可重置的问题即可，有两种经过验证的实现方式：

方案1：临时落盘复用原有可靠逻辑 #

将附件内容先写入系统临时目录的临时文件，完全复用你之前在本地文件场景下已经验证过的检测逻辑，行为和之前的测试完全一致，无兼容风险。
代码示例：

FileAttachment attachment = getFileAttachment();
// 创建和附件原名一致的临时文件，保留原有的.xls/.xlsx后缀，辅助Tika提升检测准确率
File tempFile = File.createTempFile("ews_attach_", attachment.getName());
// 将附件内容写入临时文件
try (InputStream ewsStream = attachment.getContentStream();
     OutputStream tempOut = new FileOutputStream(tempFile)) {
    ewsStream.transferTo(tempOut);
}
Tika tika = new Tika();
// 对临时文件做类型检测
String detectedMime = tika.detect(tempFile);
// 复用原有判定逻辑：后缀为Excel的文件，实际检测类型为HTML的即为异常文件
if (detectedMime.equalsIgnoreCase("text/html") 
    && attachment.getName().toLowerCase().matches(".*\\.(xls|xlsx)$")) {
    // 执行异常文件的后续处理逻辑
}
// 配置JVM退出时自动清理临时文件
tempFile.deleteOnExit();

方案2：内存流缓冲实现无落盘检测 #

如果不希望生成临时文件，可以先将附件内容全量读入字节数组，包装成支持mark/reset的ByteArrayInputStream后再传给Tika检测，检测过程完全在内存中完成。
代码示例：

FileAttachment attachment = getFileAttachment();
byte[] attachContent;
// 将原始网络流的内容全量读入字节数组
try (InputStream ewsStream = attachment.getContentStream()) {
    attachContent = ewsStream.readAllBytes();
}
Tika tika = new Tika();
// 检测时传入原始文件名，让Tika结合内容特征、扩展名做综合判断
String detectedMime = tika.detect(
    new ByteArrayInputStream(attachContent),
    attachment.getName()
);
if (detectedMime.equalsIgnoreCase("text/html") 
    && attachment.getName().toLowerCase().matches(".*\\.(xls|xlsx)$")) {
    // 执行异常文件的后续处理逻辑
}

关键注意事项 #

• 禁止直接将EWS返回的原始ContentStream传给Tika做检测：该网络流不支持重置，必然会导致Tika检测兜底返回application/octet-stream，这是之前检测失效的核心原因。
• 检测时建议同时传入附件的原始文件名作为参数：Tika的类型检测是多维度的，会结合内容魔数、文件扩展名、内置MIME规则做综合判断，比单独检测内容的准确率更高，也能完全匹配你原有判定逻辑的预期行为。
• 不要依赖FileAttachment.getContentType()的返回值判断真实文件类型：这个值是发送方自行声明的，对伪装文件没有可信度，仅可作为辅助参考。
• 对于体积超过10M的大附件，优先选择临时落盘的检测方案，避免大文件全量读入内存引发OOM问题。

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