Summary

  • RFC 2376 зарегистрировала text/xml и application/xml, но отсутствие charset включало разные правила: US-ASCII для первого даже при BOM или XML-декларации и собственное определение XML для второго.
  • Запись реестра, полученный заголовок, октеты, правило декодера и прикладной смысл были разными доказательствами. RFC 7303 позже выровняла оба типа и убрала старое неявное значение.

Самоописывающийся документ внутри чужого договора

XML создавался для переноса структуры между разными машинами и программами. Внутренняя декларация могла назвать кодировку, а метка порядка байтов помогала распознать важные представления до чтения содержания.

Но через HTTP, почту или WebDAV документ шёл в оболочке MIME. В Content-Type тоже мог находиться charset. Получатель видел несколько возможных ответов на один вопрос: какие символы представлены этими октетами.

RFC 2376 вышла в июле 1998 года как Informational, а не Internet Standard. Она ввела text/xml и application/xml, отказавшись от неточного использования типов SGML. Общие имена были нужны; проблема заключалась в приоритете источников.

Выбор отображения изменил иерархию

Любая XML-сущность подходила для application/xml. Агент без поддержки XML мог предложить сохранить её как непрозрачный файл. text/xml сообщал, что показ как обычного текста допустим по умолчанию.

Вместе с удобством пришли старые правила верхнего типа MIME text. При явном charset RFC 2376 отдавала ему власть для обоих типов. Внутреннее объявление не всегда побеждало.

При пропуске параметра пути расходились. Для application/xml заголовок не сообщал кодировку. XML-процессор мог проверить BOM, начальный рисунок байтов и декларацию; MIME-агент без знания XML не должен был гадать.

Для text/xml пропуск означал US-ASCII. Правило действовало и через HTTP, даже если тело было UTF-8 или UTF-16 и прямо заявляло это. Пустое место не сохраняло неопределённость, а включало унаследованную команду.

Пример заставлял увидеть поражение документа

RFC показала тело с UTF-16 BOM и encoding="utf-16", снабжённое лишь типом text/xml. Нормативный итог оставался US-ASCII. Верить документу означало нарушить договор доставки.

Под application/xml те же признаки вновь имели силу. При отсутствии charset BOM определял UTF-16; без BOM помогали начальные байты и внутренняя декларация. Одно слово снаружи меняло допустимое доказательство.

Это затрагивало хранение и посредников. Шлюз мог перекодировать тело и обновить только внешний charset. Архив мог отбросить заголовок, который управлял чтением. Отделив байты от контекста, система теряла объяснение полученного текста.

Самоописание не назначает собственный ранг

XML 1.0 признаёт, что при внешней информации приоритет должен задать протокол доставки. Это разумно: транспорт может преобразовать представление без ведома документа.

Но вопрос становится вопросом контроля. Какой слой может отменить другой? Пропуск означает неизвестность или значение по умолчанию? RFC 2376 частично заимствовала ответ из истории MIME.

RFC 3023 заменила её в 2001 году и сохранила US-ASCII по умолчанию для text/xml. Она подробнее объяснила пользу внешнего charset при перекодировании посредниками. Затем практика и правила текстовых типов продолжили меняться.

Исправление удалило безмолвное решение

RFC 6657 потребовала, чтобы новые текстовые типы явно описывали charset. В 2014 году RFC 7303 выровняла text/xml с application/xml: выбор верхнего типа text перестал сам определять кодировку.

Современный порядок сначала учитывает BOM, затем явный MIME charset при отсутствии BOM, а без обоих — правила XML. application/xml остаётся рекомендуемым, чтобы избежать исторической путаницы.

Суффикс +xml разделил синтаксис и назначение. Специальный тип может разрешить общим XML-инструментам разбор, сохранив точное имя документа. Построение дерева не доказывает понимания словаря или безопасности действия.

Реестр не доказывает исполнение

Нынешний реестр IANA связывает application/xml и соседние типы с RFC 7303. Он подтверждает координацию имени, но не фактический заголовок, неизменность октетов, выбор парсера или прикладной результат.

Слои реальности Lu Heng разделяют зарегистрированный тип, захваченный заголовок, байты, BOM, декларацию, результат декодирования, дерево и действие. Running-Code Primacy требует наблюдать реальный объект и реальный процессор. Minimum Initial Specification позволяет сохранить заслугу RFC 2376: она открыла узкий общий путь; преемники убрали скрытую власть значения по умолчанию, а не саму координацию.