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

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

如果一个 XML 文档（即未经处理的源 XML 文档）可供普通用户阅读，则 text/xml 比 application/xml 更可取。不明确支持 text/xml 的 MIME 用户代理（和 Web 用户代理）会将其视为 text/plain，例如，通过将 XML MIME 实体显示为纯文本。当临时用户无法读取 XML MIME 实体时，最好使用 Application/xml。

（强调我的）

---

这是一个老问题，但现在可以从 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".

---

根据this article application/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。恕我直言，最好遵循人类可读性（非可读性）的语义，并始终记住指定字符集。

---

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

---