我正在开发一个必须将 excel 文件导入 MySQL 的 PHP 应用程序.所以我需要将 excel 文件转换为 .csv 格式.但是,当我想使用 $_FILE['something']['type']
获取其类型时,我将 application/octet-stream
作为其 mime-type;
我认为这里有问题.因为我将下面的列表收集为 .csv 文件 mime 类型:
I'm working on a PHP application that must import an excel file into MySQL. So I need to convert the excel file to .csv format. But when I want to get its type using $_FILE['something']['type']
, I get application/octet-stream
as its mime-type;
I think there is something wrong here. Because I gathered the list below as a .csv file mime-type:
text/comma-separated-values,
text/csv,
application/csv,
application/excel,
application/vnd.ms-excel,
application/vnd.msexcel
怎么了?
在这种情况下,官方的 HTTP 规范总是很有帮助的.来自 RFC 2616 7.2.1(我的重点已添加):
In times like these, the official HTTP specification is always helpful. From RFC 2616 7.2.1 (my emphasis added):
任何包含实体主体的 HTTP/1.1 消息都应该包含定义该主体的媒体类型的 Content-Type 标头字段.当且仅当媒体类型不是由 Content-Type 字段给出时,接收者可以尝试通过检查其内容和/或用于识别资源的 URI 的名称扩展来猜测媒体类型.如果媒体类型仍然未知,接收方应将其视为类型application/octet-stream".
Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body. If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource. If the media type remains unknown, the recipient SHOULD treat it as type "application/octet-stream".
问题的原因是接受文件上传的服务器本身不知道上传的文件类型.为什么?因为它依赖于发送文件的 HTTP 消息来指定 Content-Type
标头来确定确切的 MIME 类型.浏览器可能没有发送 Content-Type
标头,并且服务器已根据上面的官方 HTTP 规范摘录假定 application/octet-stream
.上传文件的客户端也可能选择不确定它上传的文件的 MIME 类型,并发送 Content-Type: application/octet-stream
标头本身.
The cause of your issue is that the server accepting the file upload does not itself know what type of file has been uploaded. Why? Because it relies on the the HTTP message which sent the file to specify a Content-Type
header to determine the exact mime-type. The browser has likely not sent a Content-Type
header and the server has assumed application/octet-stream
as per the official HTTP specification excerpt above. It's also possible that the client uploading the file opted not to determine the mime type of the file it was uploading and sent the Content-Type: application/octet-stream
header itself.
现在,当我们结合 关于 POST 的 PHP 手册条目来考虑这一点时文件上传docs,我们看到以下内容:
Now, when we consider this in conjunction with the PHP manual entry regarding POST file uploadsdocs, we see the following:
$_FILES['userfile']['type']
文件的 mime 类型,如果浏览器提供了此信息.一个例子是image/gif".然而,这种 mime 类型并没有在 PHP 端进行检查,因此不要认为它的价值是理所当然的.
所以可以看到,即使指定了$_FILES['userfile']['type']
,也只对应发送的Content-Type
头由客户.这些信息很容易被伪造,不应依赖.如果您需要确定上传的文件属于特定类型,则必须自己验证.
So as you can see, even if $_FILES['userfile']['type']
is specified, it only corresponds to the Content-Type
header sent by the client. This information can easily be faked and should not be relied upon. If you need to be sure that the uploaded file is of a specific type, you'll have to verify that yourself.
这篇关于为什么我将 mime 类型的 .csv 文件作为“application/octet-stream"?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持跟版网!