Я подумал, что нужно отправить «text / xml», но потом я прочитал, что нужно отправить «application / xml». Это имеет значение? Может кто-нибудь объяснить разницу?
Я подумал, что нужно отправить «text / xml», но потом я прочитал, что нужно отправить «application / xml». Это имеет значение? Может кто-нибудь объяснить разницу?
Ответы:
Разница между текстом / XML и приложением / XML является символом по умолчанию , кодирующий если кодировка параметр опущен:
Text / xml и application / xml ведут себя по-разному, если параметр charset не указан явно. Если кодировка по умолчанию (например, US-ASCII) для text / xml по какой-то причине неудобна (например, плохие веб-серверы), application / xml предоставляет альтернативу (см. «Дополнительные параметры» регистрации application / xml в Разделе 3.2).
Для текста / xml :
В соответствии с [RFC2046], если объект text / xml получен с опущенным параметром charset, процессоры MIME и процессоры XML ДОЛЖНЫ использовать значение кодировки по умолчанию "us-ascii" [ASCII]. В случаях, когда объект XML MIME передается через HTTP, значением кодировки по умолчанию остается «us-ascii».
Для application / xml :
Если получена сущность application / xml, в которой параметр charset опущен, информация о кодировке не предоставляется заголовком Content-Type MIME. Соответствующие процессоры XML ДОЛЖНЫ следовать требованиям раздела 4.3.3 [XML], которые непосредственно касаются этой непредвиденной ситуации. Однако процессорам MIME, которые не являются процессорами XML, НЕ СЛЕДУЕТ использовать кодировку по умолчанию, если параметр charset не указан в объекте application / xml.
Таким образом, если параметр charset опущен, кодировка символов text / xml будет US-ASCII, а с application / xml кодировка символов может быть указана в самом документе.
Сейчас в Интернете есть эмпирическое правило: «Будьте строги с выходными данными, но терпимыми к входным». Это означает, что при передаче данных через Интернет необходимо максимально соответствовать стандартам. Но встроите некоторые механизмы, чтобы не замечать ошибки или угадывать при получении и интерпретации данных через Интернет.
Так что в вашем случае просто выбрать один из двух типов (я рекомендую приложение / XML ) и убедитесь в том , чтобы указать используемые кодировку символов правильно (я рекомендую использовать соответствующую кодировку по умолчанию перестраховаться, поэтому в случае применения / XML использования UTF-8 или UTF-16).
Как показывает опыт, самый безопасный способ обеспечить правильную обработку вашего документа всеми веб-серверами, прокси-серверами и клиентскими браузерами, вероятно, заключается в следующем:
С точки зрения спецификации RFC 3023 , которую некоторые браузеры не могут реализовать должным образом, основное различие в типах контента заключается в том, как клиенты должны обрабатывать кодировку символов, а именно:
Для application / xml, application / xml-dtd, application / xml-external-parsed-entity или любого из подтипов application / xml, например application / atom + xml, application / rss + xml или application / rdf + xml. , кодировка символов определяется в таком порядке:
Для text / xml, text / xml-external-parsed-entity или подтипа, такого как text / foo + xml, атрибут кодировки объявления XML в документе игнорируется, а кодировка символов следующая:
Большинство парсеров не реализуют спецификацию; они игнорируют HTTP Context-Type и просто используют кодировку в документе. При таком большом количестве плохо оформленных документов это вряд ли изменится в ближайшее время.
оба в порядке.
text / xxx означает, что в случае, если программа не понимает xxx, имеет смысл показать файл пользователю как обычный текст. application / xxx означает, что это бессмысленно показывать.
Обратите внимание, что эти типы содержимого были изначально определены для вложений электронной почты, прежде чем они позже стали использоваться в веб-мире.
text / xml предназначен для документов, которые будут иметь смысл для человека, если будут представлены в виде текста без дальнейшей обработки, application / xml - для всего остального
Каждый объект XML подходит для использования с типом мультимедиа application / xml без изменений. Но при этом не используется тот факт, что во многих случаях XML можно рассматривать как простой текст. Пользовательские агенты MIME (и пользовательские веб-агенты), которые не имеют явной поддержки application / xml, будут рассматривать его как application / octet-stream, например, предлагая сохранить его в файл.
Чтобы указать, что объект XML должен обрабатываться по умолчанию как обычный текст, используйте тип мультимедиа text / xml. Это ограничивает кодировку, используемую в объекте XML, до тех, которые совместимы с требованиями для типов текстовых носителей, как описано в [RFC-2045] и [RFC-2046], например, UTF-8, но не UTF-16 (за исключением HTTP).
text/htmlсуществует уже очень давно, и менять его было уже поздно.
В других ответах здесь рассматривается общий вопрос о том, что является правильным Content-Typeдля ответа XML, и делается вывод (как и в случае с В чем разница между text / xml и application / xml для ответа веб-службы ), что оба text/xmlи application/xmlявляются допустимыми. Однако ни один из них не указывает, существуют ли какие-либо правила, специфичные для карт сайта .
Ответ: нет. Спецификация карты сайта https://www.sitemaps.org , и с помощью site:поиска в Google вы можете убедиться, что она нигде не содержит слов или фраз mime , mimetype , content-type , application / xml или text / xml . Другими словами, в нем ничего не говорится о том, что Content-Typeследует использовать для обслуживания карт сайта.
В отсутствие каких-либо комментариев в спецификации карты сайта, непосредственно затрагивающих этот вопрос, мы можем с уверенностью предположить, что применяются те же правила, что и при выборе Content-Typeлюбого другого XML-документа, т. Е. Что это может быть либо text/xmlили application/xml.
text/htmlи предпочтительным типом MIME XHTMLapplication/xhtml+xml.