【问题标题】:YAML 媒体类型?
【发布时间】:2010-09-24 19:57:46
【问题描述】:

在通过 HTTP 发送使用 YAML 结构化的数据时,最合适的媒体类型(正式名称为 MIME 类型)是什么?为什么?

我看不到已注册的application typetext type

例子:

> GET /example.yaml

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

可能的选择:

  • 文本/x-yaml
  • 文本/yaml
  • 文本/yml
  • 应用程序/x-yaml
  • 应用程序/x-yml
  • 应用程序/yaml
  • 应用程序/yml

【问题讨论】:

    标签: http mime mime-types yaml


    【解决方案1】:

    Ruby on Rails 使用 application/x-yamltext/yaml (source) 的替代品。

    我认为这只是惯例问题,据我所知,没有技术上的原因。

    【讨论】:

    • 这不是完全正确的。以text/ 开头的 MIME 类型将作为 ISO-8859-1 处理,除非明确声明了另一个 MIME 类型(例如 text/html; charset=utf-8)。以 application/ 开头的 MIME 类型将作为 UTF-8 处理,除非显式声明了另一个 MIME 类型。例如,text/x-yaml 不能使用 UTF-8 字符,而 text/x-yaml; charset=utf-8application/x-yaml 可以。 IIRC,这在 RFC 3023 中定义。
    • @RyanParman 你有点混淆了字符集和 MIME 类型。 text/* 是对的,没有明确的 charset= 参数被假定为 ISO-8859-1,但 application/* 中的内容不一定是文本。 (您链接的 RFC 是关于 XML,不确定它是如何相关的。)
    • @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/yamltext/x-yaml都没有正式的定义,所以默认是UTF-8。
    • RFC 3023,包括编码处理已在 2014 年被 tools.ietf.org/html/rfc7303#section-3 淘汰。 RFC 2046 中 text/* 媒体类型默认为 US-ASCII(注意:不是 ISO-8859-1)的规则已在 2013 年 1 月被 tools.ietf.org/html/rfc6838#section-4.2.1 中的 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. 废弃。RFC 3023 和 RFC 7303 都没有说任何通用的内容text/*AFAIK。
    • @RyanParman 所以你当时的结论可能是正确的,但是你错误地引用了 RFC 3023,而规则来自 RFC 2046。然而,今天,UTF-8 是每个 text/* 媒体类型的默认值在其 IANA 注册中没有说明不同之处。
    【解决方案2】:

    我会说text/x-yaml:

    text 优于 application,因为它是人类可读的

    x-yaml 超过 yaml,因为它尚未被注册的 mime 类型列表接受。

    编辑:来自 RFC 3023(XML 媒体类型):

    顶级媒体类型“文本”具有 对 MIME 实体的一些限制 它们在 [RFC2045] 中有描述 和 [RFC2046]。特别是, UTF-16 系列、UCS-4 和 UTF-32 是 不允许(超过 HTTP[RFC2616],它使用类似 MIME 机制)。

    有趣...不完全确定这意味着什么,但值得深思。

    【讨论】:

    • 它是人类可读的,但它的目的是与应用程序通信...... XML 正在应用程序中
    • 还有文字下方。看来你必须同时拥有 text/x-yaml 和 application/x-yaml...rfc-editor.org/rfc/rfc3023.txt
    • 对于它的价值,这就是 Django 的 TastyPie REST 实现所理解的。
    • ...但 JSON 不是人类可读的吗?我认为说application/yaml 会更一致,就像我们可能说application/jsonapplicaiton/xml 一样。
    【解决方案3】:

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

    【讨论】:

    【解决方案4】:

    尽管接受了另一个答案,但请参阅 IANA 邮件列表上的这个 Proposed media type registration for YAML 线程,以审查剑桥大学信息服务部的 Ben Harris 在 2015 年 7 月代表提出的媒体类型YAML 团队的媒体类型:

    text/vnd.yaml
    

    带有(建议的)不推荐使用的别名:

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

    这仍然是提议/待定(线程不指示提议的状态)所以这个答案并不比其他答案更确定:-)

    【讨论】:

    • 截至 2018 年 1 月,该提案似乎一无所获,我联系作者的尝试也没有得到答复
    【解决方案5】:

    根据MIME Types list,它是text/yaml,尽管它不是官方的IANA MIME list

    【讨论】:

      【解决方案6】:

      在 Chrome 上application/yaml 将下载,而text/yaml 将显示。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2020-06-30
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2014-10-15
        • 2014-09-11
        相关资源
        最近更新 更多