Кратко

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

Почтовая система с ограниченным набором знаков могла исказить имя ещё до того, как адресат открыл письмо. В июне 1992 года Келд Симонсен предложил в RFC 1345 другой путь: передавать отсутствующий символ под коротким именем из широко переносимых знаков. Получатель мог определить исходный символ даже на терминале, который не умел его показать. Точная запись имени зависела теперь от одного мелкого решения: оставит ли отправитель границу вокруг замены.

Отправитель ставил перед мнемоническим именем особый знак, чтобы получатель отличил замену от двух обычных букв в тексте. RFC рекомендовал ASCII-амперсанд с десятичным значением 38. Если в исходном тексте стоял сам амперсанд, вводный знак приходилось удваивать. Имена длиннее двух знаков заключались в подчёркивания. Эти метки занимали место в строке, зато декодер видел начало и конец каждой замены.

Основой служили 83 графических знака, неизменных среди вариантов ISO 646. Двухзнаковые имена предназначались главным образом для буквенных систем: латиницы, греческого, кириллицы, иврита и арабского. Имена переменной длины описывали также знаки японского и китайского письма. Поэтому узкий канал передавал обозначение символа, которого не было в его собственном наборе; метки сообщали получателю, где это обозначение читать.

Раздел 4.3.2 разрешил убрать обе подсказки одним параметром: intro=0. Из строки исчезали вводный знак и подчёркивания вокруг длинных имён. Получателю было проще читать результат, но декодер лишался способа отличить исходные буквы от имени заменённого символа. Авторы RFC прямо назвали это потерей информации и отказом от обратимости. Их предельный пример особенно красноречив: mnemonic+ascii+0 равен обычному ascii.

Для архива здесь важен момент выбора. Шлюз мог сохранить исходные байты вместе с размеченной версией либо передать дальше только удобную для чтения строку. Во втором случае будущий хранитель видел знакомые буквы, но не знал, какие из них когда-то были именами других символов. Название кодировки в каталоге не заменяло удалённые метки.

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

RFC 1345 вышел как информационный документ. Он оставил операторам выбор, а архиву — конкретный вопрос: сохранились ли исходные байты рядом с читаемой копией? Если ответ отрицательный, аккуратная строка уже не докажет, каким знаком было написано имя.

Источник: RFC 1345, Character Mnemonics & Character Sets, разделы 2 и 4.3; карточка RFC Editor.