为什么我将 mime 类型的 .csv 文件作为“application/octet-stream"?

Why am I getting mime-type of .csv file as quot;application/octet-streamquot;?(为什么我将 mime 类型的 .csv 文件作为“application/octet-stream?)
本文介绍了为什么我将 mime 类型的 .csv 文件作为“application/octet-stream"?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在开发一个必须将 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"?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持编程学习网!

本站部分内容来源互联网,如果有图片或者内容侵犯您的权益请联系我们删除!

相关文档推荐

Convert JSON integers and floats to strings(将JSON整数和浮点数转换为字符串)
in php how do I use preg replace to turn a url into a tinyurl(在php中,如何使用preg替换将URL转换为TinyURL)
all day appointment for ics calendar file wont work(ICS日历文件的全天约会不起作用)
trim function is giving unexpected values php(Trim函数提供了意外的值php)
Basic PDO connection to MySQL(到MySQL的基本PDO连接)
PHP number_format returns 1.00(Php number_Format返回1.00)