在RFC(3023)的第3节中，XML媒体类型:

如果是XML文档，即未处理的源XML文档 ——普通用户可读，text/xml更可取 应用程序/ xml。MIME用户代理(和web用户代理)不这样做 有明确的支持文本/xml将它视为文本/纯，为 例如，通过将XML MIME实体显示为纯文本。 当xml MIME实体不可读时，Application/xml更可取 普通用户。

(强调我的)

根据本文，应用程序/xml是首选。

EDIT

我跟进了一下那篇文章。

作者声称在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。以我之见，最好遵循人类可读性(非可读性)的语义，并始终记得指定字符集。

这是一个老问题，但它经常被提及，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".

Application /xml在SVN中是二进制类型，而text/xml是文本文件，可以显示diff。

Web浏览器将文本/纯文本显示为明文，而大多数浏览器将应用程序/xml解析为数据树，并突出显示语法，甚至进一步应用使用XSLT声明的转换。当检测到错误时，一些浏览器会切断将application/xml作为数据树呈现，但无论语法错误如何，都会完整地显示text/xml。