我正在开发一个必须将 Excel 文件导入 MySQL 的 PHP 应用程序。所以我需要将excel文件转换为.csv格式。但是当我想使用它来获取它的类型时$_FILE['something']['type']
,我得到application/octet-stream
作为其哑剧类型;
我认为这里有问题。因为我将下面的列表收集为 .csv 文件 mime 类型:
text/comma-separated-values,
text/csv,
application/csv,
application/excel,
application/vnd.ms-excel,
application/vnd.msexcel
怎么了 ?
在这样的时期,官方 HTTP 规范总是很有帮助的。从RFC 2616 7.2.1 http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7(我的重点是补充):
任何包含实体主体的 HTTP/1.1 消息都应该包含定义该主体的媒体类型的 Content-Type 头字段。当且仅当 Content-Type 字段未给出媒体类型时,接收方可以尝试通过检查其内容和/或用于标识资源的 URI 的名称扩展来猜测媒体类型。如果媒体类型仍然未知,接收者应该将其视为“应用程序/八位字节流”类型.
您的问题的原因是接受文件上传的服务器本身不知道上传的文件类型。为什么?因为它依赖于发送文件的 HTTP 消息来指定Content-Type
标头以确定确切的 mime 类型。浏览器可能没有发送Content-Type
标头和服务器已假设application/octet-stream
根据上面的官方 HTTP 规范摘录。上传文件的客户端也可能选择不确定其上传文件的 MIME 类型并发送Content-Type: application/octet-stream
标头本身。
Now, when we consider this in conjunction with the PHP manual entry regarding POST file uploadsdocs http://www.php.net/manual/en/features.file-upload.post-method.php, we see the following:
$_FILES['userfile']['type']
文件的 MIME 类型(如果浏览器提供了此信息)。一个例子是“图像/gif”。然而,这种 mime 类型不会在 PHP 端进行检查,因此不要认为它的值是理所当然的。
正如你所看到的,即使$_FILES['userfile']['type']
被指定,它只对应于Content-Type
客户端发送的标头。此信息很容易被伪造,不应依赖。如果你需要sure上传的文件属于特定类型,您必须自行验证。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)