对于web服务响应，text / xml和application / xml有什么区别
这是关于text/xml和application/xml之间区别的一个普遍问题。 编写webservices（REST – Jersey）相当新颖。 我一直在生产application/xml因为它是什么在大多数教程/代码示例，我一直在使用学习，但我最近发现了关于text/xml ，并想知道什么是不同的关于它，你什么时候会使用它在application/xml ？
从RFC（ 3023 ）的第3节，XML Media Types：
如果一个XML文档（即未处理的源XML文档）可以被临时用户读取 ，那么text / xml优于application / xml。 没有明确支持text / xml的MIME用户代理（和Web用户代理）会将其视为text / plain，例如通过将XML MIME实体显示为纯文本。 当临时用户无法读取 XML MIME实体时， Application / xml更可取。
（重点是我的）
这是一个古老的问题，但是经常访问并且清晰的build议现在可以从RFC7303中得到 ，它已经废弃了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".
根据这篇文章， application / xml是首选。
编辑
我对这篇文章做了一些跟进。
作者声称在XML处理指令中声明的编码，如：
<?xml version="1.0" encoding="UTF-8"?>
当使用text/xml媒体types时可以忽略。
他们支持在RFC 2046中定义text/* MIMEtypes系列规范的论文，具体如下片段：
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", ie, 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 MIMEtypes可以避免这样的困难。 无论是否真实，我不会尽量避免使用text/xml 。 恕我直言，最好只是遵循人类可读性（非可读性）的语义，并始终记得指定字符集。
application/xml被svn视为二进制types，而text/xml作为可以显示diff的文本文件。
