为什么我得到mime类型的.csv文件作为“应用程序/八位字节流”？ [英] Why am I getting mime-type of .csv file as "application/octet-stream"?

问题描述

我正在开发一个PHP应用程序，必须导入一个excel文件到MySQL。所以我需要将excel文件转换为.csv格式。但是当我想使用 $ _ FILE ['something'] ['type'] 得到它的类型时，我得到 application / octet- code>作为其MIME类型;

我认为这里有错误。因为我收集了下面的列表作为.csv文件mime类型：

  text /逗号分隔值，
 text / csv，
 application / csv，
 application / excel，
 application / vnd.ms-excel，
 application / vnd.msexcel 
 
解决方案
 
在这样的时候，官方的HTTP规范总是有帮助的。从 RFC 2616 7.2.1 （我强调的是）：
 
 
任何包含实体主体的HTTP / 1.1消息都应包含定义该主体的媒体类型的Content-Type头字段。当且仅当媒体类型不是由内容类型字段给出时，接收者可以尝试通过检查其内容和/或用于标识资源的URI的名称扩展来猜测媒体类型。 如果媒体类型仍然未知，收件人应将其视为application / octet-stream类型
。
 
 
您的问题的原因是接受文件上传的服务器本身不知道已上传的文件的类型。为什么？因为它依赖于发送文件的HTTP消息来指定 Content-Type 头来确定确切的mime类型。浏览器可能没有发送 Content-Type 头，并且服务器已假设 application / octet-stream 官方HTTP规范摘录上面。也有可能客户端上传文件选择不确定它上传的文件的MIME类型，并发送 Content-Type：application / octet-stream 头本身。 
 
 
 
现在，当我们考虑这与关于POST文件上传的PHP手动输入  docs   ，我们看到以下内容：
 
 
  $ _ FILES ['userfile'] ['type']  
 
 
 
 文件的mime类型，如果浏览器提供了这个信息。一个例子是image / gif。不过，这种mime类型在PHP端没有被检查，因此不会将其值作为理由。 
 
 
你可以看到，即使指定了 $ _ FILES ['userfile'] ['type'] ，它只对应于 Content- / code>头发由客户端。此信息可以很容易伪造，不应依赖。如果您需要确定上传的文件是特定类型的，您必须自己验证。
 
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
What's the matter ?
解决方案
In times like these, the official HTTP specification is always helpful. From RFC 2616 7.2.1 (my emphasis added):

  
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".
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.

Now, when we consider this in conjunction with the PHP manual entry regarding POST file uploadsdocs, we see the following:

  
$_FILES['userfile']['type']
  
  
The mime type of the file, if the browser provided this information. An example would be "image/gif". This mime type is however not checked on the PHP side and therefore don't take its value for granted.
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文件作为“应用程序/八位字节流”？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！