Почему "-" (дефис) является уникальным ограничением ASCII для совместимости с электронной почтой?
Я читал это предложение для Base91 (с жирным форматированием, добавленным мной):
Вся электронная почта на основе SMTP может обеспечить совместимость с электронной почтой. Так называемая совместимость с электронной почтой заключается в преобразовании произвольных 8-битных строк данных или данных произвольного потока битов, передаваемых электронной почтой, в символьные строки ограниченного ASCII. Основным ограничением последнего является то, что:
(а) символы должны быть напечатаны;
(б) символы не являются контрольными или "-" (дефис).
Всего существует 94 таких символа ASCII, и их соответствующее цифровое кодирование представляет собой целые числа в диапазоне от 32 до 126, за исключением 45. Электронная почта, написанная этими символами ASCII, совместима со стандартом SMTP в Интернете и может передаваться практически во все системы электронной почты.
Примечание: 45 - это значение ASCII для дефиса.
Примечание: я только что выяснил, что это предложение исходит из патентов в Китае (ZL00112884.1) и США (US6859151B2).
Но я также прочитал RFC 5321, касающийся SMTP, и не смог найти ничего, что делало бы символ дефиса исключительным ограничением из диапазона ASCII для печати.
Примечание. Диапазон печати ASCII:
! "# $% & '() * +, - /0123456789:;. => @ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_` АБВГДЕЖЗИКЛМНОПРСТУФХЧШЭЮЯ {|}~
Почему в предложении / патенте Base91 утверждается, что "-" (дефис) является единственным ограничением совместимости электронной почты?
2 ответа
Похоже, дефис используется в качестве управляющего / маркерного символа в многострочных SMTP-сообщениях.
RFC5321 4.2.1 Код ответа Серьезность и теория:
Формат многострочных ответов требует, чтобы каждая строка, кроме последней, начиналась с кода ответа, после которого следовал бы дефис, "-" (также известный как минус), за которым следовал текст. Последняя строка начинается с кода ответа, за которым сразу следует
<SP>
, возможно, некоторый текст, и<CRLF>
, Как отмечалось выше, серверы ДОЛЖНЫ отправить<SP>
если последующий текст не отправлен, но клиенты ДОЛЖНЫ быть готовы к тому, что он будет опущен.
Предложение Base91 использует SMTP в качестве примера как его применения, так и ограничений. Как вы заявляете, изначально он хотел использовать 94 символа, но из-за различных стандартов (например, SMTP) он исключает обычно используемые псевдоуправляющие символы ("-", ".", "="). Он использует SMTP, потому что демонстрирует практичность кодирования Base91 (например, кодирование 13 битов данных на символ, а не 6 битов с помощью Base64 может значительно уменьшить количество битов, необходимых для кодирования любого данного сообщения) в дополнение к признанию того, что в нем используются дефисы в качестве управляющего символа не будет вызывать неоднозначность в тексте Base91.
Base91 может закодировать любой текст. В документе говорится, что он отображает 13 бит данных в два печатных символа ASCII. Base91 может кодировать любой номер, любой символ (включая символы новой строки), аналогично тому, как Base64 может кодировать любой символ. Аналогично, это отображение может быть обращено, чтобы произвести исходный вывод из кодировки Base91.
Вот пример многострочного кода ответа SMTP:
250-First line
250-Second line
250-234 Text beginning with numbers
250 The last line
В этом примере он преобразует большое многострочное SMTP-сообщение, которое содержит и дефисы, и новые строки, и числа, в некоторую форму в кодировке Base91. Если эта закодированная форма содержит псевдоуправляющие символы, такие как дефис, клиенты SMTP могут интерпретировать данные, закодированные в Base91, как искаженные данные SMTP. Цель удаления таких символов, как дефисы, из набора символов Base91 не из-за недостатков SMTP или спецификаций самого SMTP, а из-за клиентов, которые используют и анализируют данные SMTP, и из-за того, что клиенты по-прежнему могут правильно принимать данные Base91 без какого-либо риска. неверного разбора как данных SMTP.
Я подозреваю, что просто сделать base91 устойчивым к тому, что люди иногда делают с текстом, то есть копировать / вставлять документы и т. Д. Не имеет смысла ожидать, что это случится часто, но некоторые текстовые процессоры и т. Д. Будут использовать тире как точки переноса.