未知的文件类型MIME？

Answers:

184

您可以使用application/octet-stream未知类型。

RFC 2046在第4.5.1节中规定：

“八位字节流”子类型用于指示主体包含任意二进制数据。

— 邦贝
source
3
实际上，根据RFC，您不应发送带有未知数据的任何类型信息。RFC-2046仅定义已知类型，但RFC-7231告诉您如何处理未知类型。
— Sampo Sarrala-codidact.org
@SampoSarrala我对RFC-7231的阅读有些不同：“如果没有Content-Type头字段，则接收者可以假定媒体类型为“ application / octet-stream”（[RFC2046]，第4.5.1节），或者检查数据以确定其类型。” 我的解释是，如果我们不希望客户玩带有内容检查的猜谜游戏，我们应该不发送Content-Type，也可以安全地发送应用程序/八位字节流作为默认值。
— 2015年
1
@Jpnh是的，是的。Content-Type标头在未知时不应出现。也可以发送应用程序/八位字节流，它基本上告诉客户端“ 您现在不想显示它，而是继续将这些字节保存到文件中 ”。这使Web客户端提供保存文件。选项1 ==对该文件一无所知。选项2 ==无法使用mime描述文件内容，或仅将其保存到磁盘。实际上，任何一种选择都是正确的。我应该选择更好的措词以避免混淆。
— Sampo Sarrala-codidact.org 2015年
4
“任意二进制数据”不是“未知”。通过使用application / octet-stream，您可以告诉浏览器内容类型是已知的，不是文本也不是图像，而是任意的二进制数据，因此应将其下载到文件中并可以执行。除了出错以外，这是一个安全漏洞，尤其是考虑到几乎看不见的现代下载管理器。正确的答案是没有内容类型标题。如果您不知道文件的类型，浏览器可能会知道，因此请猜测，尤其是当它知道使用的上下文（图像，文档，脚本等）时
— FF_Dev
@FF_Dev我确定那是胡扯。“任意二进制数据”并不意味着“可执行”；浏览器（或下载管理器）没有理由假定application/octet-stream文件是可执行文件。即使浏览器在有意下载可执行文件的情况下，也不会在用户未要求的情况下“可能执行”该文件。仅下载可执行文件并不意味着我希望它立即执行。如果确实有一个浏览器可以application/octet-stream在下载时自动执行文件，请告诉我们该浏览器以及如何重现该行为。现在我不相信你。
— Mark Amery
38

RFC资源：

我们应该使用RFC-7231（HTTP / 1.1语义和内容）作为参考，而不是RFC-2046（媒体类型），因为问题显然是关于HTTP Content-Type。

同样，RFC-2046并未明确定义未知类型，而RFC-7231却明确定义了未知类型。

简短答案：

不要为未知数据发送MIME类型。
更清楚地说：根本不要使用Content-Type标头。

参考文献：

RFC-7231
超文本传输​​协议（HTTP / 1.1）：语义和内容
3.1.1.5。内容类型

产生包含有效载荷主体的消息的发送者应该
在该消息中生成Content-Type头字段，除非 发送者
不知道所表示的预期媒体类型
。

该部分清楚地告诉您，如果您不确定它，则将其省略。它还告诉接收者可以假定类型为应用程序/八位字节流，但事实也可能是其他类型。

那有什么不同呢？

RFC-2046
4.5.1。八位字节流子类型

对于接收
“应用程序/八位字节流”实体的实现，建议采取的措施是简单地提供将数据
放入文件中，而无需进行任何Content-Transfer-Encoding编码，或者可以将
其用作用户指定的输入处理。

并且，如上所述。

RFC-7231
3.1.1.5。内容类型

如果没有Content-Type头域，则接收者可以假定媒体类型为“ application / octet-stream”
（[RFC2046]，第4.5.1节），或者检查数据以确定其类型。

结论：

如果将其定义为“ application / octet-stream”，则表示您知道它是“ application / octet-stream”。

如果您没有定义它，那么您是在告诉您您不知道它是什么，然后将决定留给接收者，然后接收者可以检查它是否走得像鸭子和...

— 桑波·萨拉拉（sampo Sarrala）-codidact.org
source
1
这个答案是正确的，因为它是唯一的真理。另外，默认情况下使用“应用程序/八位字节流”会使大多数浏览器触发下载，考虑到几乎看不见的现代下载管理器，这是一个安全漏洞。
— FF_Dev '16
1
这对于HTTP是正确的，但问题通常是关于MIME，而不是关于HTTP。例如，在电子邮件中，规则完全不同。另请参见在建议的副本stackoverflow.com/questions/12539058/…上的
— 三点
由于相同的原因，我进行了上调，但是我同意FF_Dev。除非意图是“应用程序/八位字节流”并触发下载，否则需要“应用程序/未知”。如果未设置“ Content-Disposition”，但浏览器不尝试下载文件，那将是很好的选择，但是有太多网站在不设置文件名的情况下随意下载文件。特别是银行。
— justdan23 '19
14

我更喜欢application/unknown，但结果肯定与application/octet-stream

— 拉达
source
17
是否有允许使用应用程序/未知而不是应用程序/八位字节流的标准？
— 亨德里克·布鲁默曼
3
谢谢！应用程序/未知程序运行良好，八位字节流导致我的示例png文件中的chrome错误！
— fnkr
10
为什么将.png文件用作application/octet-stream或application/unknown？他们发明的理由是image/png。
— Aidiakapi 2014年
10
@ jenson-button-event与重新发明轮子无关。MIME类型指定您的意图。如果您知道要发送的内容应该是png图片，请传递该信息。如果字节意外地表示一个jpeg，则您的应用程序可以警告您这不是有效的png，并且您在其他位置存在错误。此外，并非所有应用程序都像浏览器一样强大和容错。它们旨在解决程序员的错误，但这远不是唯一的目的。浏览器不是唯一使用MIME类型的应用程序。
— Aidiakapi'1
2
你的参考是什么？未知类型不提供有关文件内容或状态的任何信息，或者即使它是二进制或基于文本的，对于生产代码来说也太模糊了，对于小型项目可能还可以，因为如果文件mimetype没有操作系统中的处理程序，它实际上是一个可下载的二进制文件，未知类型是Windows操作系统中的已知句柄，您可以分配一个操作（例如，使用记事本打开未知文件）。虽然坏习惯，你可以使用未知类型联合此跳过任何执行：/
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.