Кратко

  • RFC 2044 закрепил самосинхронизирующуюся схему: стартовый байт сообщает длину, продолжения начинаются с 10, а ASCII 00–7F остаётся побайтно неизменным.
  • Упорядочение по байтам не стало культурной сортировкой, а отсутствие раздела по угрозам не было доказательством безопасности; эти границы уточнили RFC 3629 и RFC 5198.

Контракт, который мог исполнить парсер

Таблицу форматов в RFC 2044 удобно читать как конечный автомат. Значение из семи бит проходит одним байтом. Более крупная кодовая позиция получает ведущий байт с префиксом, задающим длину, а последующие байты несут префикс 10. Стартовый байт нельзя спутать с продолжением. Более того, байт ASCII не возникает внутри многобайтовой последовательности.

Из этих ограничений следовали практические свойства. ASCII-текст не требовал перекодирования. Инструмент, ищущий ASCII-разделитель, не находил его посреди другого символа. Потеряв позицию, сканер мог снова обнаружить границу. Для инфраструктуры середины 1990-х это было не эстетикой формата, а миграционной стратегией.

RFC 1521 показывает среду MIME, где метка набора символов уже была частью соглашения о сообщении. RFC 1641 описывал более раннее применение Unicode в MIME. RFC 2044 зарегистрировал имя UTF-8 и предложил вариант, который меньше конфликтовал с уже работающей ASCII-базой. Сохранение старых инвариантов снижало цену добровольного внедрения.

Числовой порядок не является языком

Документ отмечал ещё одно аккуратное свойство: лексикографическое сравнение байтов сохраняет числовой порядок UCS-4. Но тут же оговаривал, что этот порядок культурно непригоден. Алфавитная сортировка, правила регистра, сочетания знаков и ожидания читателей относятся к другому уровню. Кодирование может обеспечить устойчивую последовательность чисел; оно не может вывести из неё французский, арабский, японский или русский порядок словаря.

Это различие полезно и сейчас. База данных способна честно сортировать UTF-8 по байтам и одновременно выдавать неприемлемый для пользователя список. Ошибка лежит не в повреждённых байтах, а в подмене collation транспортным порядком.

Историческая грамматика и современная UTF-8

RFC 2044 описывал от одного до шести байтов и широкий диапазон UCS-4. Это не сегодняшняя допустимая UTF-8. RFC 2279 стал следующей спецификацией, а RFC 3629 ограничил кодирование четырьмя байтами и максимумом U+10FFFF. Он запретил суррогатные значения и избыточные представления, при которых одну кодовую позицию можно было бы записать более длинной последовательностью.

Именно здесь становится видна цена неодинаковой строгости. Если фильтр безопасности и прикладной декодер принимают разные формы, одна и та же логическая строка может пройти проверку под одним байтовым видом и интерпретироваться под другим. RFC 2044 говорил лишь, что вопросы безопасности не обсуждаются. Это обозначение области документа, а не сертификат безопасности.

Кодирование, допустимость, эквивалентность

Операторам полезно держать три проверки отдельно. Кодирование отвечает за границы байтов. Допустимость отвечает за разрешённые последовательности и кодовые позиции. Текстовая эквивалентность отвечает за случаи, когда визуально или семантически одинаковый текст представлен разными последовательностями. RFC 5198 рекомендует NFC для сетевых протоколов, которым нужна предсказуемая текстовая форма. Нормализация не возникает автоматически из корректного UTF-8.

Реестр IANA сохраняет каноническое имя UTF-8 и MIBenum 106, но ссылается сегодня на RFC 3629. Это компактная история эволюции стандарта: стабильное имя пережило пересмотр допустимого множества. Поэтому ссылка на RFC 2044 объясняет происхождение механизма, но реализация должна сверяться с действующей спецификацией.

Почему узкая спецификация победила

RFC 2044 оставил за пределами транспортного формата то, что формат не мог решить: значение, отображение, локальную сортировку и политику идентичности. Такая скромность была силой. Совместимость с ASCII дала ранним системам выгоду без одномоментной замены, а локально распознаваемые границы дали библиотекам простой исполнимый договор.

Однако массовое внедрение создало зависимость. Формат стал входным условием файлов, API, баз данных и языков программирования. Надпись «UTF-8 supported» теперь почти ничего не говорит о качестве реализации. Существенны другие вопросы: отклоняются ли избыточные формы и суррогаты, совпадают ли правила проверки на всех слоях, где выполняется нормализация и не используется ли порядок байтов вместо языковой сортировки?

Источники