在这种情况下，官方的HTTP规范总是很有帮助的。从RFC 2616
7.2.1（我的重点已添加）：
任何包含实体主体的HTTP / 1.1消息都应包括定义该主体媒体类型的Content-Type头字段。当且仅当Content-
Type字段未提供媒体类型时，接收方可以通过检查其内容和/或用于标识资源的URI的名称扩展来尝试猜测媒体类型。
如果媒体类型仍然未知，则接收者应将其视为类型“ application / octet-stream” 。
造成此问题的原因是，接受文件上传的服务器本身并不知道已上传的文件类型。为什么？因为它依赖于发送文件的HTTP消息来指定
Content-Type标头来确定确切的mime类型。浏览器可能未发送
Content-Type标题，并且服务器已
application/octet-stream按照上面的官方HTTP规范摘录进行了假设。上载文件的客户端也可能选择不确定其上载文件的mime类型，并发送
Content-Type:application/octet-stream标头本身。
现在，当我们将其与有关POST文件上传 文档 的PHP手册一起考虑时，我们将看到以下内容：
$_FILES['userfile']['type']文件的MIME类型（如果浏览器提供了此信息）。 一个例子是“ image /
gif”。但是，不会在PHP端检查此mime类型，因此不要将其值视为理所当然。
如您所见，即使
$_FILES['userfile']['type']已指定，它也仅对应于
Content-Type客户端发送的标头。此信息很容易被伪造，因此不应依赖。如果需要 确保 上传的文件是特定类型，则必须验证自己。
