Markdown 的 MIME 类型是什么？答案

【问题标题】：What is the MIME type for Markdown?Markdown 的 MIME 类型是什么？
【发布时间】：2012-05-28 22:35:21
【问题描述】：

有谁知道 Markdown 是否存在 MIME 类型？我猜是text/plain，但有更具体的吗？

【问题讨论】：

【解决方案1】：

看来mime类型text/vnd.daringfireball.markdown应该是Markdown作者注册的，在此之前可以将Markdown mime类型指定为text/x-markdown。

【讨论】：

【解决方案2】：

没有官方标准类型，但text/markdown似乎是最常见的de facto类型。大多数浏览器和其他相当复杂的客户端可能会看到text/ 部分，并且无论如何默认为text/plain，所以没有太大区别。

但有一点需要注意：text/ hiearchy 下的所有类型在相关 RFC 标准中的字符类型默认为 ISO-8859-1。此后，世界上大部分地区都转向 UTF-8。因此，除非您确定不会使用任何有趣的字符（或生活在旧的 Windows 世界中），否则您可能希望按如下方式指定它：

text/markdown; charset=UTF-8

【讨论】：

如果邮件客户端支持这一点并使用 Daringfireball Markdown 作为它的基础，那就太棒了。不幸的是，他们没有。我什至不知道是否有人将其作为 RFC 草案提交给 IETF。我还研究了 Enriched Text MIME 类型，发现许多邮件客户端不再支持这种类型——现在支持 HTML 邮件。此外，Enriched Text format 从不支持超链接。
您所说的“有趣的角色”是指世界上绝大多数人每天用来交流的角色。
是的，完全正确。世界上有很多有趣的角色。我努力成为他们中的一员。
如果您自己实现此功能，则应使用text/markdown：x- 前缀已于 2012 年 6 月被 RFC 6648 (Best Current Practice 178) 弃用。
Stuart P. Bentley：太好了。万岁进步。 >8->

【解决方案3】：

tl;dr：`text/markdown` 自 2016 年 3 月起

2016年3月，text/markdown注册为RFC7763 at IETF。

以前应该是text/x-markdown。下面的文字描述了 2016 年 3 月之前的情况，当时 RFC7763 仍是草案。

Gruber’s definition上没有官方推荐，但是official mailing-list上的话题讨论得挺多的，最终选择了text/x-markdown。

这个结论是challenged later，已经得到确认，并且可以被 IMO 视为共识。

这是缺乏官方 mime 类型的唯一合乎逻辑的结论：text/ 将在几乎所有地方提供适当的默认值，x- 因为我们没有使用官方类型，markdown 而不是 gruber. 或无论如何，因为这种类型现在很常见。

不过，关于 Markdown 的不同“风味”，仍有unknowns。我想有人应该注册一个官方类型，据说是 easy，但我怀疑除了 John Gruber 之外还有人敢这样做，因为他最近 proved 他对 Markdown 的附件。

IETF 上有一个drafttext/markdown，但内容似乎根本没有描述 Markdown，所以在它变得更完整之前我不会使用它。

【讨论】：

【解决方案4】：

看起来 text/markdown 将成为标准。

【讨论】：

【解决方案5】：

根据2016年的RFC7763 “The text/markdown type”，一般的MIME类型是

text/markdown; charset=UTF-8

charset 参数是必需的，但不必是 UTF-8。

该 RFC 还指定了一个可选的 variant 参数，并且 Internet 号码分配机构维护registry of Markdown Variants 通过它可以指定 Markdown 的特定变体，例如，

text/markdown; charset=UTF-8; variant=Original
text/markdown; charset=UTF-8; variant=GFM
text/markdown; charset=UTF-8; variant=CommonMark

一些变体允许更多参数，如 RFC7764 “Guidance on Markdown”, 例如，您可以添加 extensions=-startnum 和 pandoc 变体来指定对方言的调整，虽然我不知道 pandoc 如何/是否会真正解释这一点。

RFC2046 “MIME Part Two” 从 1996 年开始设置US-ASCII为默认字符集，还说

“文本”的任何未来子类型的规范必须指定他们是否也会使用“charset”参数，并且可能也可能限制它的值。

然后RFC2616 “HTTP/1.1” 从 1999 年开始指定 ISO-8859-1 作为 text/* 传输的默认字符集 HTTP，随着网络成为主要的通信方式，这成为text/* 媒体类型的假定默认编码。

如果没有明确的字符集或注册的 mime-type-specific 默认值，text/* 被认为是 US-ASCII，除非所述文本通过 HTTP 传输，在这种情况下它是被认为是 ISO-8859-1。

RFC 6657 “Update to MIME regarding "charset" Parameter Handling in Textual Media Types” 试图澄清这种差异通过要求所有新媒体类型注册明确指定如何确定字符集，最好将其包含在有效负载中，因为 HTML 允许使用 <meta charset=UTF-8>.

text/markdown registration 将 charset 参数指定为“必需”。因此使用内容类型 text/markdown 技术上无效，此类内容的字符集可能合法地被解释为任何未定义、无效、US-ASCII、 ISO-8859-1 或 UTF-8，实际上它几乎总是如此。

【讨论】：