MIME 类型的约定、标准或限制？答案

【问题标题】：MIME-type conventions, standards or limitations?MIME 类型的约定、标准或限制？
【发布时间】：2011-03-13 10:12:32
【问题描述】：

鉴于目前无法由任何已知应用程序处理的新的专有文件格式，我假设您可以发明一个新的 MIME 类型值，如下所示：

Content-Type: application/my-arbitrary-format

假设这是要走的路，是否有任何限制（格式、语法、长度、保留字或其他）、标准（IETF、ISO、W3C 、IEEE 等），还是约定（如斜线type/format）？

请注意，我不想使用已知的 MIME 类型值，因为浏览器和/或操作系统不应该假设什么可以打开或不能打开文件。

【问题讨论】：

标签： standards mime mime-types conventions

【解决方案1】：

要正确执行此操作，您可以向 IANA 注册您的新类型。 http://www.iana.org/assignments/media-types/

【讨论】：

有没有办法发明应用程序特定的 MIME 类型来避免注册过程？例如，如果我正在开发一个需要自定义 JSON 风格的 RESTful API (application/my-app-special1+json)。
@LeaHayes，基本上你可以发送任何你想要的东西。至于为什么要创建类似于 JSON 而不是 JSON 的东西，我不确定...
我希望有一个可以使用的通用约定。我想定义一个 JSON 模式，用于为自定义模块加载器传输 JavaScript、CSS 和依赖项。我想使用自定义 MIME 来识别返回的 JSON 数据将被自动解释（而 application/json 将被纯粹视为数据）。这样，模块加载器可以通过 API 使用，并且 API 的使用者（可能使用我的 JavaScript 库）将理解响应的性质......这只是我正在玩弄的一个想法。干杯！
@LeaHayes，Content-Type 应该标识返回数据的类型，而不是用它做什么。这就是约定。当然，您可以更改此设置，但通常如果您返回 JSON，则应按原样发送。当然，在使用中也有很多例外。 XHTML 就是其中之一，因为它只是 XML，但使用 application/xhtml+xml。
@Lea：您可能希望使用前缀x- 来表示非标准值，请参阅此问题stackoverflow.com/questions/2086374/…

【解决方案2】：

This 页面给出了命名 MIME 类型的约定。这是关于自定义 MIME 类型的部分：

使用 x. 作为实验性 MIME 类型的子类型的前缀。请注意，x- 前缀也适用于此目的，但不鼓励使用 x. 以促进与其他前缀的对称性。

使用vnd. 作为商业产品一部分的供应商特定 MIME 类型的子类型的前缀。 vnd. 前缀后应跟供应商名称和子类型，并用句点分隔（例如 application/vnd.mozilla.xul+xml)。

使用 prs. 作为不属于商业产品的个人/虚荣 MIME 类型的子类型的前缀。

【讨论】：

原链接完全失效了，好像丢失了好几年了。
关于媒体类型的维基百科页面具有或多或少相同的信息：en.wikipedia.org/wiki/Media_type#Registration_trees
据我所知，此 wiki 的 x. 含义，如果您是供应商，但您的格式尚未公开但面向 b2b，您可以使用 x. 而不是 vnd。