未知文件类型 MIME? ？

小开

最佳答案

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

RFC 2046 在4.5.1节中说明:

“ octet-stream”子类型用于表明一个物体包含任意二进制数据。

小开

我更喜欢 application/unknown，但结果肯定是一样的 application/octet-stream

小开

RFC 资源:

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

此外，RFC-2046没有明确定义未知类型，但 RFC-7231有。

简短的回答:

不要为未知数据发送 MIME 类型。
更明确地说: 根本不要使用 Content-Type 头。

参考文献:

RFC-7231 < br/> 超文本传输协议(HTTP/1.1) : 语义和内容 < br/> 3.1.1.5. 内容类型

生成包含有效载荷体的消息的发送方应该
在该消息中生成 Content-Type 标头字段，除非
封闭表示的预定媒体类型对于
发件人。

这一部分清楚地告诉你，如果你不确定，就不要写。它还告诉接收方可以假定类型是 application/octet-stream，但问题是它也可能是别的东西。

那有什么不同？

RFC-2046 < br/> < a href = “ https://www.rfc-edit or.org/rfc/rfc2046 # section-4.5.1”rel = “ noReferrer”> 4.5.1. Octet-Stream Subtype

实现的建议操作，该实现接收
“ application/octet-stream”实体只是提供放置数据
在文件中，撤消任何内容传输编码，或者
使用它作为用户指定进程的输入。

而且，如上所述:

RFC-7231 < br/> < a href = “ https://www.rfc-edit or.org/rfc/rfc7231 # section-3.1.1.5”rel = “ noReferrer”> 3.1.1.5. Content-Type

如果没有 Content-Type 头字段，则收件人可以假设媒体类型为“应用程序/八位流”
([ RFC2046]第4.5.1节)或检视资料以确定其类型。

结论:

如果你把它定义为“ application/octet-stream”，那么你就是在告诉别人你知道它是“ application/octet-stream”。

如果你不定义它，那么你就是在告诉你不知道它是什么，把决定留给接收者和接收者，然后检查它是否像鸭子一样走路。