对于webservice响应,text/xml与application/xml之间有什么区别

Mik*_*ike 465 xml rest jersey

这是更多的区别一般问题text/xmlapplication/xml.我很擅长编写webservices(REST - Jersey).我一直在制作,application/xml因为它出现在我一直用来学习的大多数教程/代码示例中,但我最近发现text/xml并且想知道它有什么不同以及何时使用它application/xml

Ode*_*ded 415

来自RFC(3023),第3节,XML媒体类型:

如果临时用户可以读取 XML文档(即未处理的源XML文档),则text/xml优于application/xml.没有明确支持text/xml的MIME用户代理(和Web用户代理)会将其视为text/plain,例如,将XML MIME实体显示为纯文本. 当 临时用户无法读取 XML MIME实体时,最好使用Application/xml.

(强调我的)

  • 我猜这是"人",他们的意思是"电脑书呆子".:) (181认同)
  • @drachenstern - 我认为非描述性元素和属性更可能(`<a1 d =""g ="">`,例如_casual_用户无法读取). (6认同)
  • @CommaToast如果"text/xml"是Accept,则Web服务器可能会返回格式化和缩进的XML,而application/xml可能会返回所有无效的空格.例如,在ASP.NET MVC中,您可以为不同的mimetypes指定不同的处理程序. (6认同)
  • 请举例说明不可读和可读.我们使用大多数可读但具有base64编码节点的文件等. (5认同)
  • @JoePhilllips - 你走了.base64不是人类可读的.如果可以在没有工具或查看手册("xgsf`标签是什么意思?")的情况下阅读整个文档并使其对人有意义,那么它是可读的. (4认同)
  • @Mike当然.一些XML文件基本上是一个记录列表,如下所示:http://msdn.microsoft.com/en-us/library/ms762271%28v=vs.85%29.aspx这更有可能被读取和处理一个应用程序.其他的基本上是带有标记的文本,就像HTML页面一样.使用text/xml听起来更合适. (3认同)
  • 这个答案解释了text/xml与application/xml背后的*intent*,但它没有解释*两者之间的技术差异*.使用"application/xml"而不是"text/xml"时实际发生了什么变化? (3认同)

小智 92

这是一个古老的问题,但现在可以从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".
Run Code Online (Sandbox Code Playgroud)

  • @MariánČerný 一个是“标准”而另一个是“别名”这一事实难道不会基本上意味着“application/xml”是默认使用的吗?在我看来,此时保留“text/xml”的唯一原因是为了向后兼容,因为标准化是在“application/xml”上进行的。 (5认同)
  • 引用的段落提到了IANA注册信息,该信息(通过检查9.1节)也处理编码,因此在“ application / xml”和“ text / xml”之间的字符集处理上不应再有任何区别。另外,我认为摘要的这一部分:“此规范标准化了... application / xml ...,同时将text / xml ...定义为别名...”,表示`application / xml`和`text / xml`是等效的,彼此之间没有偏好。 (4认同)

har*_*ang 31

根据这篇文章, application/xml是首选.


编辑

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

作者声称在XML处理指令中声明的编码,如:

<?xml version="1.0" encoding="UTF-8"?>
Run Code Online (Sandbox Code Playgroud)

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

他们text/*RFC 2046中定义了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.
Run Code Online (Sandbox Code Playgroud)

根据他们的说法,使用application/xmlMIME类型时可以避免这种困难.无论是否真实,我都不会避免text/xml.恕我直言,最好只是遵循人类可读性(不可读性)的语义,并始终记住指定字符集.

  • +1 为链接。用您自己的话说,文章得出的基本结论是什么?也许“文章指出文件编码被忽略,这意味着您不能在带有 text/xml 标头的文件中发送 utf-8 和二进制数据”这是否也得到验证? (2认同)

Mic*_*cki 5

application/xml通过看到svn作为二进制型,而text/xml作为文本为可显示的差异文件.