相同的服务器，相同的文件，不同的 MIME 类型答案

【问题标题】：Same server, same file, different mime types相同的服务器，相同的文件，不同的 MIME 类型
【发布时间】：2016-10-18 02:57:59
【问题描述】：

同一应用程序在两个不同的服务器 (dev/prod) 上运行。据我所知，服务器运行的几乎所有东西（CF、Java、IIS 等）的版本都相同。

在开发过程中，我上传了一个特定的 Word 文档，ColdFusion 将其标识为 application/msword，在 prod 上将其标识为 application/x-tika-msoffice。

我正在尝试诊断原因。我的解决方法是在我的上传文件中允许application/x-tika-msoffice mime 类型，但仍然会导致它有所不同。如果我需要检查一些特定的服务器设置，请告诉我，但我能想到的一切似乎在 prod 和 dev 之间都是一样的。

【问题讨论】：

IIS 中 .doc 的 MIME 类型在 dev 和 prod 中是否匹配？
是的。他们都说 application/msword
Adobe 的 bugbase 中有几个类似的条目至少可以追溯到 2014 年。文件是 .doc 还是 .docx？有没有接触过 OpenOffice？
我无法说明文件是如何生成的，但仅基于我将假设的 MIME 类型。我已向给我文件的人发送了查看请求。当我在 Windows 中检查文件时，它会显示应用程序/msword。
我与拥有该文件的用户进行了核对，他说他保存为 97-03 文件并且使用的是 Microsoft Word。

标签： coldfusion mime-types

【解决方案1】：

MIME 类型由浏览器发送，因此这可能解释了您所看到的差异。也许在开发中您安装了 Office，而在生产服务器上您希望没有。

您永远不应使用 MIME 类型来确定是否应出于此原因上传文件 -- 而应始终使用文件扩展名。这种 mime 类型很容易被欺骗，因此依赖它进行验证毫无意义。

CF10+ 允许您在cffile 标签的accept 属性中指定文件扩展名列表。它还添加了strict 属性并将其默认为true，它执行服务器端MIME 类型检查（基本上与运行fileGetMimeType() 相同，但即使使用strict=true，您仍然不能依赖此文件检查，扩展名更多重要（两者都做）。

【讨论】：

我不明白你的第一部分。我正在使用同一台机器上传文件（相同的浏览器），ColdFusion 通过读取临时文件获取 MIME 类型服务器端。因此，除非浏览器在传输过程中编辑 MIME 类型，然后将其作为元数据添加到服务器上的临时文件中，否则我不确定这怎么可能。您是说该文件固有地具有 mime 类型，但浏览器获取该文件并在发送到服务器时覆盖该文件？这听起来很疯狂。文件扩展名如何比 MIME 类型更不易欺骗。我正在使用accept 属性进行此检查。
阅读 FileUpload 文档，您的陈述似乎是正确的，这让我更加困惑。同一台计算机、同一文件和我的浏览器发送两种不同的 mime 类型？
假设doc文件已经在服务器上，你从fileGetMimeType(path, false)和fileGetMimeType(path, true)得到什么结果？