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


495

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


Как отмечено в ответе DaveV и в заголовке по адресу tools.ietf.org/html/rfc3023 , RFC 3023 (цитируемый ответом Одеда, принятый в настоящее время) устарел. Более новый RFC 7303 фактически дает значительно иной ответ на этот вопрос, чем раньше RFC 3023. Поэтому я думаю, что для будущих читателей будет полезно, если вы примете ответ DaveV, так что самая актуальная информация будет храниться в верхней части списка ответов.
Марк Амери

На основании приведенных ниже Дейва V и Мариана Черны кажется, что application / xml предпочтительнее, если вы делали что-то новое.
Sql Surfer

text/предназначен для людей. application/предназначен для компьютеров
Ян Бойд

Ответы:


108

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

6
В цитируемом параграфе упоминается информация о регистрации в IANA, которая (проверяя раздел 9.1) касается также кодирования, поэтому не должно быть никаких различий в обработке набора символов между application/xmlи text/xml. Кроме того, я считаю эту часть реферата: «Эта спецификация стандартизирует ... приложение / XML ... при определении текста / XML ... в качестве псевдонима ...» означает , что application/xmlи text/xmlявляются эквивалентными и нет предпочтения один о другом.
Мариан Черны

427

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

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

(акцент мой)


6
@drachenstern - я думаю, что неописательные элементы и атрибуты более вероятны ( <a1 d="" g="">например, нечитаемы обычными пользователями).
Одд

3
@ Майк Конечно. Некоторые XML-файлы в основном представляют собой список записей, например: msdn.microsoft.com/en-us/library/ms762271%28v=vs.85%29.aspx С большей вероятностью он будет прочитан и обработан приложением. Другие в основном текст с разметкой, как HTML-страница. Использование text / xml для них звучит более уместно.
biziclop

5
Пожалуйста, приведите пример нечитаемого против читаемого. Мы используем файлы, которые в основном читаются, но имеют узлы в кодировке base64 и т. Д.
Джо Филлипс

5
@JoePhilllips - Ну вот. base64 не читается людьми. Если весь документ может быть прочитан и понятен человеку без инструментов или без просмотра руководства (что xgsfозначает этот тег?), То он читабелен.
Одед

8
@CommaToast Веб-сервер может вернуть отформатированный и с отступом XML, если «text / xml» - это «Принять», тогда как application / xml может вернуть все незначительные пробелы, удаленные. Например, в ASP.NET MVC вы можете указать разные обработчики для разных типов MIME.
Новатерата

33

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


1
+1 за ссылку. Как, по вашим словам, к какому основному выводу пришли статьи? Может быть, "в статье говорится, что кодировка файла игнорируется, что означает, что вы не можете отправлять utf-8 и двоичные данные в файл с заголовком text / xml", также это проверено?
Shanimal

Я согласен с @Shanimal, ответ должен включать суть статьи, так как ссылка не может длиться вечно. Его исчезновение сделает ответ почти бесполезным. Может ли кто-нибудь подтвердить утверждение об игнорировании инструкций по обработке XML, касающихся кодирования?
toniedzwiedz

1
Согласно первоначальному автору, это было исправлено в более поздних версиях спецификацийUpdate: The situation has changed in the new HTTP/1.1 RFC: The default charset of ISO-8859-1 for text media types has been removed; the default is now whatever the media type definition says.
TheNorthWes

Если я загружаю XML-файл с помощью ajax, это «документ» типа, application/xmlно если я использую элемент формы ввода, это «файл» типа, text/xmlкоторый неправильно обрабатывается моим кодом. Как я могу преобразовать это в другой формат?
Адвокат дьявола

5

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.