用于 web 服务响应的 text/xml 与 application/xml 之间有什么区别答案

【问题标题】：What's the difference between text/xml vs application/xml for webservice response用于 web 服务响应的 text/xml 与 application/xml 之间有什么区别
【发布时间】：2011-06-17 11:17:09
【问题描述】：

这是一个关于text/xml 和application/xml 之间区别的一般性问题。我对编写 Web 服务（REST - Jersey）相当陌生。我一直在制作application/xml，因为它出现在我用来学习的大多数教程/代码示例中，但我最近发现了text/xml，并想知道它有什么不同，你什么时候使用它超过application/xml？

【问题讨论】：

如 DaveV 的回答和tools.ietf.org/html/rfc3023 的标题中所述，RFC 3023（由 Oded 的回答引用，目前已被接受）已过时。较新的 RFC 7303 实际上对这个问题给出了与 RFC 3023 过去截然不同的答案。因此，我认为如果您接受 DaveV 的答案，这将对未来的读者有所帮助，以便将最新信息保留在答案列表的顶部。
基于下面的 Dave V 和 Marián Černý 看来，如果您正在做一些新的事情，那么 application/xml 现在是首选。
text/ 是为人类设计的。 application/ 适用于计算机

标签： xml rest jersey

【解决方案1】：

来自 RFC (3023)，在第 3 节，XML 媒体类型下：

如果一个 XML 文档——即未处理的源 XML 文档 -- 对普通用户可读，text/xml优于应用程序/xml。不支持的 MIME 用户代理（和 Web 用户代理）明确支持 text/xml 会将其视为 text/plain，因为例如，通过将 XML MIME 实体显示为纯文本。当 XML MIME 实体 不可读 时，最好使用 Application/xml 普通用户。

（强调我的）

【讨论】：

@drachenstern - 我认为非描述性元素和属性更有可能（<a1 d="" g="">，例如 casual 用户无法阅读）。
@Mike 当然。一些 XML 文件基本上是一个记录列表，像这样：msdn.microsoft.com/en-us/library/ms762271%28v=vs.85%29.aspx 这更有可能被应用程序读取和处理。其他的基本上是带有标记的文本，例如 HTML 页面。为他们使用 text/xml 听起来更合适。
请举一个不可读与可读的例子。我们使用的文件大多可读，但确实有 base64 编码节点等。
@JoePhilllips - 你去。 base64 是人类无法读取的。如果整个文档可以在没有工具或查看手册的情况下被人阅读并理解（xgsf 标签是什么意思？），那么它是可读的。
@CommaToast 如果“text/xml”是接受者，Web 服务器可能会返回格式化和缩进的 XML，而 application/xml 可能会返回所有已删除的无关紧要的空格。例如，在 ASP.NET MVC 中，您可以为不同的 mimetype 指定不同的处理程序。

【解决方案2】：

这是一个老问题，但现在可以从RFC 7303 获得经常访问的明确建议，该问题已废弃 RFC3023。简而言之（第 9.2 节）：

The registration information for text/xml is in all respects the same
as that given for application/xml above (Section 9.1), except that
the "Type name" is "text".

【讨论】：

引用的段落提到了 IANA 注册信息，它（通过检查第 9.1 节）也处理编码，因此 application/xml 和 text/xml 之间的字符集处理应该没有任何差异.另外，我认为这部分摘要：“本规范标准化 ... application/xml ...同时将 text/xml ...定义为别名 ...”表示 application/xml 和 text/xml 是等价的并且没有对另一个的偏好。
@MariánČerný 一个是“标准”而另一个是“别名”这一事实是否基本上意味着application/xml 是默认使用的？在我看来，此时保留text/xml 的唯一原因是为了向后兼容，因为标准化正在application/xml 上进行。

【解决方案3】：

根据this articleapplication/xml是首选。

编辑

我对这篇文章做了一些跟进。

作者声称XML处理指令中声明的编码，如：

<?xml version="1.0" encoding="UTF-8"?>

当使用text/xml 媒体类型时可以忽略。

他们用RFC 2046中定义text/* MIME类型族规范来支持论文，具体如下：

4.1.2.  Charset Parameter

   A critical parameter that may be specified in the Content-Type field
   for "text/plain" data is the character set.  This is specified with a
   "charset" parameter, as in:

     Content-type: text/plain; charset=iso-8859-1

   Unlike some other parameter values, the values of the charset
   parameter are NOT case sensitive.  The default character set, which
   must be assumed in the absence of a charset parameter, is US-ASCII.

   The specification for any future subtypes of "text" must specify
   whether or not they will also utilize a "charset" parameter, and may
   possibly restrict its values as well.  For other subtypes of "text"
   than "text/plain", the semantics of the "charset" parameter should be
   defined to be identical to those specified here for "text/plain",
   i.e., the body consists entirely of characters in the given charset.
   In particular, definers of future "text" subtypes should pay close
   attention to the implications of multioctet character sets for their
   subtype definitions.

根据他们的说法，使用application/xml MIME 类型可以避免这样的困难。不管是真是假，我都不会避讳text/xml。恕我直言，最好遵循人类可读性（非可读性）的语义，并始终记住指定字符集。

【讨论】：

+1 链接。用你自己的话来说，文章得出的基本结论是什么？也许“文章指出文件编码被忽略，这意味着您不能在带有 text/xml 标头的文件中发送 utf-8 和二进制数据”也得到验证？
我同意@Shanimal，答案应该包括文章的要点，因为链接可能不会永远存在。它的消失将使答案几乎毫无用处。有人可以确认关于忽略有关编码的 XML 处理指令的声明吗？
根据原作者的说法，这已在规范Update: The situation has changed in the new HTTP/1.1 RFC: The default charset of ISO-8859-1 for text media types has been removed; the default is now whatever the media type definition says.的后续版本中得到修复
如果我使用 ajax 加载 XML 文件，它是 application/xml 类型的“文档”，但如果我使用输入表单元素，它是 text/xml 类型的“文件”，它不会处理正确使用我的代码。如何将其转换为其他格式？

【解决方案4】：

application/xml 被 svn 视为 binary 类型，而 text/xml 被视为可以显示差异的 text 文件。

【讨论】：