Кратко

  • RFC 1922 требовала, чтобы каждая строка ISO-2022-CN с китайскими знаками содержала собственное обозначение набора и возвращалась командой SI в ASCII до CRLF. Видимая строка не зависела от скрытого состояния выше окна.
  • Обозначение, SI/SO и односимвольные SS2/SS3 задавали семибитную грамматику. Правильная грамматика не доказывала доставку, наличие глифа, личность отправителя или понимание читателя.
  • charset-edition и charset-extension фиксировали год таблицы и частные дополнения. Они делали несовпадение наблюдаемым, но не создавали нужную таблицу у получателя и не подтверждали внедрение.

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

Поставщики расширяли стандартные китайские наборы собственными знаками. Без метки получатель видел ошибку, но не знал, относится ли байт к иной редакции, локальной таблице или повреждённому потоку. charset-extension позволял указать зарегистрированное расширение либо частное имя с x-.

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

Похожую границу проводил charset-edition. Год сообщал, на какую редакцию стандарта рассчитывал отправитель. Понимающий клиент выбирал соответствующую таблицу. Старый клиент игнорировал неизвестный параметр и мог применить прежнюю редакцию, допустив несколько локальных ошибок. Год сужал диагностику, а не удостоверял изображение.

Каждая строка закрывала собственное состояние

RFC 1922 вышла в марте 1996 года со статусом Informational. ISO-2022-CN начинал в ASCII. Escape-последовательность назначала набор регистру; SO включал китайский двухбайтовый набор, SI возвращал ASCII. Новое назначение тому же регистру отменяло предыдущее.

Главное требование повторялось на границе строки. Если строка содержала китайские знаки, она сама несла нужное назначение. Перед CRLF следовало выполнить SI. Поэтому каждая строка начиналась и заканчивалась в известном состоянии.

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

Односимвольный сдвиг не менял будущее

SS2 и SS3 применяли дополнительный набор только к следующим двум байтам—одному китайскому знаку. Затем продолжалось прежнее состояние SI/SO. Нельзя было считать такой сдвиг постоянным: иначе одна корректная вставка меняла бы значение всех последующих байтов.

ISO-2022-CN-EXT добавлял зарегистрированные наборы и плоскости. Грамматика предусматривала финальные знаки для будущих назначений ISO, но запрещала использовать их до настоящего назначения. Зарезервированное место ещё не давало поставщику права объявить своё значение общим.

Для проверки поэтому нужны конкретные назначение, регистр, длительность и точка возврата. Флаг «китайский режим» слишком груб, чтобы повторить решение декодера.

Семь бит защищали только один участок пути

ISO-2022-CN и ISO-2022-CN-EXT укладывались в семь бит. Им обычно не требовался Content-Transfer-Encoding лишь ради сохранения старшего бита. Но правильная MIME-метка, законное состояние и поддерживаемый набор всё равно оставались отдельными условиями.

CN-GB и CN-Big5 были восьмибитными. На семибитном маршруте их следовало упаковать в Base64 или Quoted-Printable. Передача исходных восьми бит имела основание только после реального согласования 8BITMIME в SMTP. Старый агент мог обрезать старший бит, закончить пересылку и доставить нечитаемый результат.

Charset называл предполагаемое толкование, кодирование переноса защищало представление, 8BITMIME согласовывал транспортную способность. Ни одна из этих квитанций не подтверждала автора, таблицу, шрифт или то, что увидел человек.

Два байта и две колонки нельзя было путать

Escape-последовательности занимали байты, но не экранные колонки. Китайский знак обычно занимал два байта и две колонки. RFC запрещала разрывать пару границей строки и советовала ограничивать видимую ширину примерно 75 колонками, оставляя место для символа > при цитировании ответа.

Это правило признавало обычную жизнь письма. Оно должно выдержать не только SMTP, но и прокрутку, вырезку, цитату и повторное отображение. Локальное восстановление и запас ширины защищали от предсказуемых преобразований самого почтового процесса.

Корректная цепочка байтов могла дать иной знак

Соответствие Big5 и CNS 11643 зависело от таблиц преобразования и решений реализации. Поэтому законный поток мог выглядеть иначе при другой редакции, расширении или гарнитуре. Кодировка могла указывать на традицию начертания, но не на гражданство, местонахождение или полномочия отправителя.

Основной документ — RFC 1922. RFC 1468 и RFC 1557 дают соседний контекст японской и корейской семибитной почты. RFC 1521 описывает MIME той эпохи, RFC 1652 — согласование 8BITMIME, а RFC 2046 — более позднее уточнение типов MIME. RFC 3629 фиксирует последующую стандартизацию UTF-8.

Эти документы не считают установки. RFC 1922 рекомендовала как минимум отправлять и принимать ISO-2022-CN и принимать как можно больше описанных форматов. Она не доказывает соответствие конкретного продукта или автоматический и без потерь переход к UTF-8. В разделе Security Considerations сказано, что безопасность не обсуждалась.

Running-Code Primacy полезна как более поздняя аналитическая дисциплина: документ и зарегистрированное имя координируют, а рабочие парсеры, ретрансляторы, таблицы и шрифты создают результат. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption помогает отделить малое детерминированное ядро—назначение, сдвиг, диапазон байтов, возврат—от локального выбора наборов и миграции. Это не свидетельство замысла авторов RFC.

RFC 1922 не обещала уничтожить расхождения. Она дала им имена и ограничила состояние текущей строкой, чтобы ошибка не могла незаметно присвоить себе всё будущее текста.