Кратко

  • RFC 2070 отделил внешнюю байтовую кодировку конкретного ресурса HTML от фиксированного абстрактного набора символов документа UCS; параметр charset в HTTP или MIME называл отображение для декодирования.
  • Числовые ссылки разрешались в фиксированном наборе документа, поэтому сохраняли идентичность символа независимо от внешней кодировки разметки.
  • Успешное декодирование было свидетельством лишь одного этапа. Разбор SGML, обработка языка и двунаправленного текста, наличие шрифта, вывод глифа и понимание читателя оставались разными состояниями.

Возьмём кириллическую прописную И. Один ресурс может нести её буквально в поддерживаемой кодировке, другой — записать как И. Третий может хранить саму ссылку в многобайтовом представлении UCS. Октеты различаются, но при правильном декодере и допустимой разметке все три пути приводят к одному номеру символа в документе HTML.

Именно здесь RFC 2070 провёл решающую границу. Байты принадлежали конкретному ресурсу, номер — абстрактному документу. Если смешать эти уровни, простая смена транспортной кодировки на сервере сможет изменить смысл числовой ссылки. RFC закрепил назначение и оставил изменчивость на входе декодера.

SGML нуждался в мире символов до синтаксического разбора

HTML всё ещё определялся как приложение SGML. Набор символов документа SGML был не перечнем допустимых в файле байтов, а репертуаром вместе с номерами, которыми тип документа и его экземпляры обозначали символы. DTD, разметка и текстовые данные интерпретировались в одном нумерованном пространстве.

Основа HTML 2.0 в RFC 1866 включала Latin-1, совмещала его позиции с ISO 10646 и указывала на будущий расширенный репертуар. RFC 2070 завершил переход для профиля интернационализации HTML 2.x, выбрав Universal Character Set из ISO 10646:1993 с поправками. На момент публикации RFC описывал его как совпадающий позиция за позицией с Unicode 1.1.

Расширение репертуара не делало любое целое число допустимым. Декларация SGML оставляла позиции 128–159 неиспользованными, поэтому ’ оставалась незаконной в этой модели, даже если поздняя программа показывала на её месте типографский знак. Выражение «страница Unicode» могло скрывать два разных утверждения: какие абстрактные символы умеет называть HTML и в какой внешней кодировке записан конкретный ресурс. RFC зафиксировал первое, не требуя единственного байтового представления второго.

charset выбирал вход, а не менял пункт назначения

Внешняя кодировка приходила из контекста передачи или хранения. В HTTP параметр charset поля ответа Content-Type задавал кодировку; в электронной почте ту же роль исполнял параметр MIME со своими правилами по умолчанию. RFC отмечал, что для FTP и распределённых файловых систем тогда не существовало равноценного стандартизированного сигнала.

Термин MIME мог вводить в заблуждение. charset означал не просто репертуар, а способ отображения последовательностей октетов в последовательности символов; разные октеты могли давать один результат. RFC 2045 требовал полностью определить это отображение для именованного MIME-charset, но не гарантировал возможность закодировать обратно каждый абстрактный символ.

Эталонная цепочка выглядела так: ресурс → декодер → диспетчер сущностей → анализатор SGML → приложение → отображение. Декодер переводил внешнее представление в набор документа; следующие этапы работали с символами, а вывод мог вновь преобразовать их в форму устройства. Реализация не обязана была иметь буквальные модули с такими названиями. Наблюдаемое поведение должно было сохранять границу. Это контракт, а не опись внутренностей браузеров 1997 года.

Числовая ссылка была стабильна именно после декодирования

RFC 2070 называл инвариантность числовых ссылок важнейшим следствием модели. Они разрешались относительно фиксированного набора документа и потому обозначали одни символы при любой внешней кодировке.

Порядок существенен. Получатель сначала должен правильно превратить байты в знаки разметки &, #, цифры и ;. Лишь затем SGML распознаёт ссылку и разрешает номер. Ссылка не исправляет поток, который уже декодирован неверно; стабильность появляется после правильного пересечения границы.

Обратный путь тоже не обещает тождества байтов. RFC предупреждал, что даже неизменённое исходное значение формы при отправке может вернуться в других, столь же допустимых октетах. Составные последовательности и предварительно составленные символы могли по-разному представлять эквивалентный текст. Копирование, сохранение и отправка создавали новые события кодирования, а не побайтовую копию источника.

У метки кодировки была иерархия доказательств

RFC 2070 честно описывал развёртывание 1997 года: серверы часто не указывали подходящий charset, а некоторые браузеры неверно обрабатывали Content-Type с таким параметром. Это историческое наблюдение, не оценка современной доли браузеров.

Первым считался charset, полученный от источника документа; затем раннее объявление META HTTP-EQUIV; после него — рекомендательный атрибут CHARSET ссылки. У META была проблема начальной загрузки: его можно прочитать лишь после того, как предыдущие байты уже декодированы достаточно хорошо для поиска элемента. Поэтому RFC называл приём ненадёжным и практически применимым только к кодировкам, подходящим образом сохраняющим ASCII-значения в начале.

Иерархия разделяла авторитетность и доступность. Близкая подсказка могла появиться раньше, не получая авторитета метаданных ответа. Но и авторитетная метка оставалась заявлением: она не доказывала, что тело соблюдает отображение или что декодер реализован верно.

Правильно декодированный символ мог не появиться на экране

UCS расширил множество обозначаемых HTML символов, но не создавал шрифтов. RFC предвидел ситуацию, когда система разбирает символ, но не умеет его показать, и не предписывал единственного запасного поведения. Квадрат отсутствующего глифа или шестнадцатеричный номер были политикой представления, а не другой идентичностью.

Язык и направление добавляли состояния. LANG мог влиять на выбор глифа, кавычки, переносы, лигатуры, интервалы и речь. DIR, BDO и двунаправленный алгоритм Unicode меняли визуальный порядок, необходимый для чтения. Они действовали над уже определёнными символами, не переопределяя внешние байты.

Следовательно, различались ошибки сигнала кодировки, неверный результат декодера, отказ или неверная структура после разбора, отсутствие шрифта либо плохая обработка языка и направления. Скриншот не показывает, какой уровень первым дал сбой. Правильный хеш байтов не доказывает успех последующих этапов.

Граница пережила смену институционального владельца

Когда спецификации HTML перешли к W3C, RFC 2854 объявил устаревшими RFC 2070 и ранние документы IETF по HTML. Это факт управления и истории документов, а не исчезновение границы декодера. Более поздняя регистрация text/html по-прежнему описывала charset как кодировку представления документа HTML в байтах, а HTML 4.01 повторял, что одного набора символов документа недостаточно для интерпретации переданной последовательности.

Позднейшее различение Lu Heng между минимальной начальной спецификацией, локальными будущими решениями и добровольным принятием даёт полезную ретроспективу. Фиксированное пространство номеров было малым общим инвариантом. Поддержка декодеров, обработка ошибок, шрифты и представление оставались локальными решениями реализации. Публикация нормы не исполняет код.

Практический вывод RFC 2070 сохранился: доставленные байты ещё не образуют документ, а разрешённый номер ещё не образует глиф. Для каждого перехода нужно своё свидетельство; ни один слой не расширяет свои полномочия квитанцией предыдущего.

Источники