В чем разница между text / xml и application / xml для ответа веб-службы

Это более общий вопрос о разнице между text/xml и application/xml. Я довольно новичок в написании веб-сервисов (REST - Jersey). Я производил application/xml так как это то, что появляется в большинстве учебников / примеров кода, которые я использовал, чтобы узнать, но я недавно узнал о text/xml и было интересно, что отличается от этого, и когда вы будете использовать его над application/xml?

384
jersey rest xml

5 ответов

из RFC (3023), в разделе 3, типы носителей XML:

Если XML-документ -- то есть необработанный исходный XML-документ -- читаем случайные пользователи, текст / xml предпочтительнее приложение / xml. Агенты пользователей MIME (и агенты веб-пользователей), которые не имейте явную поддержку для text / xml будет рассматривать его как text/ plain, для например, путем отображения сущности XML MIME в виде обычного текста. Application / xml предпочтительнее, когда сущность XML MIME прочитать случайные пользователи.

(выделено мной)

357

Это старый вопрос, но тот, который часто посещают и четкие рекомендации, теперь доступны от 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".
56

по данным в этой статье application/xml является предпочтительным.

редактировать

Я сделал небольшое дополнение к статье.

автор утверждает, что кодировка, объявленная в инструкциях по обработке XML, как:

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

можно игнорировать, когда text/xml используется тип носителя.

они поддерживают тезис с определением text/* спецификация семейства типов MIME в RFC 2046, а конкретно следующий фрагмент:

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. ИМХО, лучше всего просто следовать семантике человеческой читаемости (нечитаемости) и всегда помнить, чтобы указать кодировку.

31

application/xml видит svn as бинарные тип а text/xml as текст файл, для которого может отображаться diff.

5

не для того, чтобы ответить на ваш вопрос, но для обеспечения простой жизни:

когда вы живете в экосистеме .NET framework -> посмотрите на https://referencesource.microsoft.com/#system.web/MimeMapping.cs линия ~430:

AddMapping(".xml", "text/xml");

, Так что вы всегда можете сделать

string mimeType = System.Web.MimeMapping.GetMimeMapping(string yourFileName)

чтобы получить ваш тип mimetype правильно

0