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