Кратко

  • RFC 1502 описывал GeneralText в X.400: перечень наборов символов содержится в параметрах, а значение байта в конкретном месте зависит от управляющих последовательностей ISO 2022.
  • Читающая программа должна обозначить символ, который устройство не может вывести, и не подменять его местным символом той же двоичной позиции. Рекомендации отправителю не заменяют анализ полученного потока.

Пустое место заметно. Неверная буква способна незаметно войти в чужую фразу. Харальд Алвестранд в августе 1993 года выбрал борьбу со второй ошибкой, когда описывал многоязычный текст в почте X.400. Сеть уже умела перевезти несколько наборов символов; оставалось не дать последней программе цепочки убедительно исказить прочитанное.

Параметры GeneralText перечисляли используемые наборы. Внутри самого сообщения последовательности ISO 2022 назначали и включали нужный набор. Начальным считался IA5 в G0 и обычный управляющий набор в C0. Если текст начинался в другом состоянии, его следовало объявить. Список наборов похож на инвентарь: он показывает, что может встретиться, а значение одного байта выясняется только после учёта всех переключений до этого места.

Автор предложил отправителю удобный порядок: держать US-ASCII в G0, а при подходящем содержимом помещать набор ISO 8859 в G1. Это сохраняло битовое представление ASCII. Но получателю документ запрещал строить чтение на предположении, что отправитель выполнил этот совет. В почту попадали сообщения из разных программ и шлюзов; решающее значение имело фактическое состояние принятого текста.

Раздел 4 требовал от способного читать GeneralText приложения распознавать IA5 и родные для него наборы, всегда отмечать знак, который устройство вывода не может адекватно показать, и никогда не рисовать вместо неизвестного знака местный знак с совпавшей битовой позицией. Совпадение номера в двух таблицах не превращает два символа в один. Такая подстановка приписала бы автору письма выбор машины.

RFC также советовал режим с заменителями, режим с видимыми пропусками и сохранение сообщения вместе с данными о наборах символов. Те же требования относились к шлюзам, переводящим GeneralText в другой формат, например MIME. Удобная для экрана копия должна оставлять возможность проверить, что же было в исходном потоке.

Если наборы назначения не охватывали знак, раздел 5 допускал управляющий символ замены, отдельно объяснённую мнемонику, понятный человеку вариант или отказ от преобразования. При запрете на преобразование с потерями оставался отказ. Нынешняя карточка RFC Editor помечает RFC 1502 как Historic; оригинальный документ говорит о положении на пути стандартизации в 1993 году. Проверки конкретного почтового клиента в нём нет. Его принцип зато ясен: экран должен сообщить о своей неспособности, прежде чем выдавать чужую букву за авторскую.