YAML哑剧类型？

111

通过HTTP发送以YAML结构化的数据时，最适合使用的MIME类型是什么？

对于给定选择为什么最合适的解释将不胜感激。

例：

> GET /example.yaml

< Content-Type: ????
<
< --- # Favorite movies
< - Casablanca
< - North by Northwest
< - Notorious

可能的选择：

text/yaml
text/x-yaml
application/yaml
application/x-yaml

— 乔恩·克拉姆
source

64

Ruby on Rails application/x-yaml与text/yaml（source）一起使用。

我认为这只是一个约定问题，据我所知，没有任何技术原因。

— 文科·弗萨洛维奇（Vinko Vrsalovic）
source

78

这不是很真实。text/除非明确声明了另一个MIME类型（例如text/html; charset=utf-8），否则以ISO 开头的MIME类型将按照ISO-8859-1处理。application/除非明确声明了另一个MIME类型，否则以MIME开头的MIME类型将作为UTF-8处理。例如，text/x-yaml在text/x-yaml; charset=utf-8和期间不能使用UTF-8字符application/x-yaml。IIRC，这是在RFC 3023中定义的。–

— Ryan

2

@RyanParman您会混淆字符集和MIME类型。没错text/*，没有显式charset=参数的假定是ISO-8859-1，但其中的内容application/*不一定是文本。（您链接的RFC是关于XML的，不确定其相关性。）

— Thanatos 2015年

3

@RyanParman不正确。tools.ietf.org/html/rfc6838#section-4.2.1说：

If a "charset" parameter is specified, it SHOULD be a required parameter, eliminating the options of specifying a default value. If there is a strong reason for the parameter to be optional despite this advice, each subtype MAY specify its own default value, or alternatively, it MAY specify that there is no default value. Finally, the "UTF-8" charset [RFC3629] SHOULD be selected as the default.

。没有text/yamlnor的正式定义text/x-yaml，因此默认值为UTF-8。

— 2016年

7

包括编码处理在内的RFC 3023已在tools.ietf.org/html/rfc7303#section-3中于2014年作废。RFC 2046中媒体类型的默认规则US-ASCII（注：不是ISO-8859-1）已于2013年1月在tools.ietf.org/html/rfc6838#section-4.2.1中text/*作废。RFC 3023和RFC 7303均未提及任何有关据我所知。

Regardless of what approach is chosen, all new text/* registrations MUST clearly specify how the charset is determined; relying on the US-ASCII default defined in Section 4.1.2 of [RFC2046] is no longer permitted.

text/*

— 2016年

6

@RyanParman因此，您的结论可能在那时是正确的，但是您错误地引用了RFC 3023，而该规则来自RFC2046。但是，今天，UTF-8每种text/*媒体类型的默认设置都没有声明其IANA注册中的不同之处。

— 2016年

21

虽然另一个答案被接受，请参阅本为YAML提议的媒体类型的注册审查媒体类型IANA的邮件列表，其中本哈里斯，剑桥大学的信息服务，上线提出了 2015年7月代表YAML队的媒体类型的：

text/vnd.yaml

具有（建议）不推荐使用的别名：

text/yaml
text/x-yaml
application/x-yaml

那仍然是提议/待定的（线程不指示提议的状态），所以这个答案比其他答案更明确：-)

— dj
source

11

似乎该提案截至2018年1月

— 为止一无所获

15

我会说text / x-yaml：

应用程序上的文本，因为它易于阅读

x-yaml优于yaml，因为它尚未被纳入哑剧类型的注册列表中。

编辑：从RFC 3023（XML媒体类型）：

顶级媒体类型“文本”对MIME实体有一些限制，它们在[RFC2045]和[RFC2046]中进行了描述。特别是，不允许使用UTF-16系列，UCS-4和UTF-32（通过HTTP [RFC2616]使用类似于MIME的机制除外）。

有趣的...不确定是什么意思，但值得深思。

— 格雷格
source

1

它是人类可读的，但其意图是与应用程序进行通信...正在应用XML

— Vinko Vrsalovic

并根据文字。看来您必须同时拥有text / x-yaml和application / x-yaml ... rfc-editor.org/rfc/rfc3023.txt

— Vinko Vrsalovic

对于它的价值，这就是Django的DeliciousPie REST实现理解的。

— Michael Scheper

1

...但是JSON也不可读吗？我认为application/yaml就像我们可能说的application/json和那样更一致applicaiton/xml。

— 安东尼·鲁特里奇

7

不鼓励使用“ x-”媒体类型，请参阅RFC 4288，第3.4节。正确的做法是使用个人树，供应商树或实际尝试正确的媒体类型注册。

— 朱利安·雷施克（Julian Reschke）
source

这样就可以了，application/vnd.yaml或者text/vnd.yaml（文本看起来更好）

— 连线

也不完全正确。无需注册即可使用的唯一子类型树是x.。vnd.并prs.需要注册。参见tools.ietf.org/html/rfc6838#section-3.2和tools.ietf.org/html/rfc6838#section-3.3。

— 2016年

1

根据MIME类型列表，它是text/yaml，即使它不在官方IANA MIME列表中

— 教父
source

1

在Chrome application/yaml上将下载，同时text/yaml会显示。

— 朱利奥
source

这不能为问题提供答案。一旦您拥有足够的声誉，您就可以在任何帖子中发表评论；而是提供不需要问询者澄清的答案。- 评分

— YSF

1

@ ysf，IMO，您的评论过于古怪。帖子简短但准确，回答了OP的问题，解释了每个选项的“为什么”，并努力说明其限制（“ ...至少在Chrome上是这样”。）更不用说：没有其他人提供这个资讯。OP可能甚至没有考虑过不同的Content-Type可能导致不同的行为，这对他或她可能很有用。

— Dan H