Кратко

  • RFC 1468 описал узкий семибитный профиль: текст начинался в ASCII, четыре escape-последовательности выбирали ASCII, JIS X 0201 Roman или одну из двух версий JIS X 0208, а строка с двухбайтовыми символами должна была покинуть это состояние до CRLF.
  • MIME-метка ISO-2022-JP указывала ожидаемое правило чтения, но не доказывала правильность тела, сохранность переключателей при ретрансляции, совпадение декодированных символов, выбранных глифов или увиденного человеком текста.

У сообщения был заголовок с именем кодировки. У каждого байта — ещё и невидимая предыстория.

RFC 1468 вышел в июне 1993 года и зафиксировал способ представления японского текста, возникший в JUNET и уже применявшийся в японских IP-сообществах. Все значения оставались семибитными, однако поток переключался между несколькими наборами. Сеть могла переносить его, не умея отображать японский; конечная программа должна была воспроизвести ту же последовательность состояний.

Такой подход часто описывают как этап до Unicode. Это верно хронологически, но недостаточно технически. Документ показывает, как совместимость строится не только из допустимых значений, но и из ограниченной памяти, контрольных точек и запрета посреднику подменять объект собственной интерпретацией.

Четыре переключателя внутри текста

Исходное состояние — ASCII. ESC $ B выбирает JIS X 0208-1983, ESC $ @ — редакцию 1978 года. После любого из них один символ кодируется двумя байтами. ESC ( B возвращает ASCII, а ESC ( J включает JIS X 0201 Roman.

Эти последовательности не сопровождают отдельные символы как внешние ярлыки. Они меняют чтение всех следующих значений до нового переключения. Пара байтов представляет японский символ только пока действует JIS X 0208. После возврата в ASCII те же значения имеют другую роль. Декодеру необходимо помнить последний допустимый designator.

Однобайтовые состояния тоже различны. JIS X 0201 Roman заменяет в двух позициях обратную косую черту и тильду на знак иены и надчёркивание. Конкретный шрифт может скрыть разницу, но не отменить её. Набор Kana из JIS X 0201 в профиль не входит. Суффикс JP не давал права использовать любое локальное японское представление.

Формальная грамматика исключает ESC, SI и SO из обычных однобайтовых символов. Управление остаётся управлением, данные — данными. Публичное имя приносит пользу, когда за ним стоит достаточно маленькая и однозначная машина.

Конец строки ограничивал память

Если строка содержит символы JIS X 0208, до CRLF она обязана переключиться в ASCII или JIS X 0201 Roman. Следующая строка начинается в выбранном перед границей однобайтовом состоянии. Весь текст завершается в ASCII.

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

Это не полная самосинхронизация. Возврат к JIS X 0201 Roman сохраняет два отличия от ASCII; реакция на оборванный escape остаётся решением реализации. Но двухбайтовое состояние не должно безмолвно пересекать строку. CRLF становится не только разметкой, но и пределом действия интерпретации.

Так работает минимальная общая спецификация: она не заставляет все узлы понимать содержание, а задаёт достаточно точные входы и выходы, чтобы независимые конечные системы могли договориться.

Семибитный путь не гарантировал смысл

RFC приводит MIME-запись Content-Type: text/plain; charset=iso-2022-jp. Представление уже семибитное, поэтому дополнительное Content-Transfer-Encoding не требуется только ради прохождения старого почтового тракта.

Однако файл можно разрушить, оставив его семибитным. Достаточно удалить ESC, заменить designator, разрезать пару или пересобрать окончания строк. Диапазон значений останется допустимым, а история состояний изменится. Транспортная ширина и семантическая целостность — разные свойства.

Документ предупреждал, что Base64 или quoted-printable сделают сообщение нечитаемым для тогдашних программ JUNET. Это свидетельство о развёрнутом коде 1993 года, а не вечный запрет MIME. Корректно снятая обратимая оболочка может сохранить исходные байты. Но если действующий клиент не умеет снять её перед внутренним декодированием, бумажная обратимость не становится оперативной совместимостью.

Позднейший RFC 2046 назвал параметр charset критическим для MIME-текста и сохранил правила строк. Метка выбирает определение, которому должен соответствовать body. Она не удостоверяет прохождение каждого преобразования.

Посредник не мог исправлять то, чего не различал

RFC 1468 признавал: некоторые системы не показывали разницы между ESC ( B и ESC ( J, а также между ESC $ @ и ESC $ B. Тем не менее при передаче другому узлу escape-последовательности нельзя было менять.

Локальное визуальное равенство не создаёт переносимой идентичности. Другой шрифт может показать иену вместо обратной черты. Будущий конвертер может различать редакции JIS X 0208. Архиву может быть важно доказать, что пришло, а не только воспроизвести привычную картинку. Нечувствительность одного реле не даёт ему полномочий удалять различие для всех следующих участников.

Точная копия сохраняет и причинную цепочку. При неожиданном глифе можно отдельно проверить источник, реле, декодер и отображение. «Полезная» нормализация записывает решение посредника в объект и стирает место расхождения. Внешне аккуратная копия может оказаться более слабым доказательством.

Сохранность байтов не подтверждает автора и не делает утверждение истинным. Это более узкая обязанность: не превращать собственное прочтение в необратимое редактирование чужого сообщения.

У строки было три длины

RFC советовал пользователям держать видимую строку примерно в пределах 75–80 колонок, оставляя место для знака цитирования. В его модели символ JIS X 0208 занимает два байта и две колонки, а escape занимает байты, но не колонки. При переносе нельзя разрывать двухбайтовый символ.

Следовательно, смещение в байтах, позиция символа и экранная колонка — разные координаты. В ASCII-фрагменте они могут выглядеть синхронными, после designator расходятся. Разрез по восьмидесятому байту не равен переносу по восьмидесятой колонке. Удаление «невидимых» управляющих значений до проверки может удалить именно правило чтения видимого текста.

Хеш тела фиксирует представление, но не выбранный шрифт. Снимок экрана фиксирует конкретный рендер, но не восстанавливает ввод. Надёжная экспертиза связывает оба объекта, не объявляя один заменой другого.

Реестр координировал значение имени

RFC 2978 позже определил charset как метод преобразования последовательности октетов в символы, включая сложные переключения ISO 2022. Связанная с именем спецификация должна полностью задавать отображение без скрытого внешнего профиля.

Нынешний реестр Character Sets IANA хранит ISO-2022-JP под номером 39, ссылаясь на RFC 1468 и RFC 2237; ISO-2022-JP-2 записан отдельно под номером 40. Реестр стабилизирует словарь. Он не исполняет конверсию, не сертифицирует библиотеку и не измеряет современное применение.

Метаданные RFC Editor относят RFC 1468 к Informational, а не к Internet Standard. Это не отменяет описанного исторического использования. И наоборот, строка IANA не делает любой помеченный body соответствующим профилю. Редакционный статус, регистрация имени и работающий код имеют разные источники истины.

Новым состояниям дали новые имена

В декабре 1993 года RFC 1554 описал экспериментальное многоязычное расширение ISO-2022-JP-2. Оно добавило китайские, корейские, дополнительные японские, латинские и греческие обозначения, а также вторую область состояния с очисткой части контекста на новой строке. Более сложный декодер получил отдельное MIME-имя.

В 1997 году RFC 2237 определил ISO-2022-JP-1 для JIS X 0212 через ESC $ ( D. Требование завершать текст в ASCII сохранилось; без дополнительных символов следовало применять обычный ISO-2022-JP.

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

Спецификация заканчивалась до читателя

Документы доказывают, как должен быть построен соответствующий поток. Они не доказывают, что увидел конкретный человек. MIME-поле, исходные байты, переходы, преобразования реле, версия декодера, последовательность символов, шрифт и картинка должны сохраняться раздельно.

Опубликованные тексты Heng Lu помогают удержать границу. Minimum Initial Specification показывает, как небольшой общий слой оставляет внедрение местным участникам. Running-Code Primacy отделяет публикацию от исполнения. On Reality Layers не позволяет слить имя, представление, восприятие и действие в один символический факт.

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