5.1. Механизм конвертации "Quoted-Printable"
Этот механизм предназначен для представления данных, в основном состоящих из байтов, соответствующих символам, имеющим изображение в символьном наборе ASCII. В результате данного кодирования все байты будут иметь такие значения, гарантированные от дальнейшей модификации почтовым транспортом. Если конвертируемые данные в основном представляют собой ASCII-текст, то конечная их форма остается узнаваемой и читаемой для человека. Тело, полностью состоящее из ASCII-символов, также может быть конвертироавано в Quoted-Printable, что гарантирует его содержимому целостность при прохождении через всякие шлюзы, в которых происходит языковая перекодировка символов или преобразование концов строк и т.д.
В Quoted-Printable байты должны быть рпедставлены в соответствии со следующими правилами:
Правило №1 (обычное 8-битное представление): Каждый байт, кроме тех, которые используются для обозначения конца строки, может быть представлен с помощью двух шестнадцатиричных цифр, предворяемых знаком "=". При написании шестнадцатиричных цифр с A по F должны использоваться заглавные буквы. Кроме тех случаев, когда нижеследующие правила позволяют альтернативное кодирование, данное правило является обязательным.
Правило №2 (Буквенное представление): Байты с десятичным значением с 33 по 60 и с 62 по 126 МОГУТ быть представлены ASCII-символами, соответствующими этим значениям (с '!' по '<' и с '>' по '~').
Правило №3 (Пробелы): Байты со значениями 9 и 32 МОГУТ быть представлены как ASCII-символы "Табуляция" и "Пробел", но НЕ ДОЛЖНЫ быть представлены так в конце строки. Везде, где они представлены соответствующими ASCII-символами, за ними должен следовать символ, имеющий графическое изображение (печатный символ). В конце же строки символы табуляции и пробела должны быть представлены в соответствии с правилом #1, так как некоторые почтовые транспорты могут убирать пробелы в конце строки.
Правило №4 (Конец строки): Конец строки в тексте письма должен быть представлен (в соответствии с RFC 822) последовательностью CRLF. Так как в каноническом представлении текста не требуется визуального отображения символов конца строки, в Quoted-Printable не используется видимых символов для обозначения конца строки. Для представления бинарных данных более предпочтительной является кодировка base64.
Необходимо заметить, что многие реализации почтовых программ могут кодировать по-своему. В частности, при представлеии текста в системах, использующих другие соглашения по обозначению конца строки (отличные от CRLF). Такие реализации недопустимы, и генерация концов строки должна быть стандартизована везде, чтобы не требовалось распознавать, используется ли какое-либо альтернативное представление.
ПРАВИЛО #5: (Мягкий конец строки): В соответствии с Quoted-Printable длина строки не должна превышать 76 символов. В противном случае используется 'мягкий' перевод строки, представимый знаком равенства. Например, если исходная строка имела вид:
Now's the time for all folk to come to the aid of their country.
то в Quoted-Printable encoding он может быть представлена следующим образом:
Now's the time = for all folk to come= to the aid of their country.
Это обеспечивает механизм восстановления исходной длины строки пользовательским почтовыи агентом.
Поскольку символ дефиса ("-") представляется в Quoted-Printable в обычном виде, особую осторожность нужно соблюдать при заключении тела в Quoted-Printable в многочастное письмо, чтобы удостовериться, что граница этого включения не проявляется нигде внутри этого включения (лучше всего выбрать обозначение границы в виде последовательности символов "=_", которая никогда не появляется в теле, закодированном в Quoted-Printable. См. определение многочастного письма далее.)
Замечание: Quoted-Printable представляет собой нечто вроде компромисса между читабельностью и сохранностью при пересылке. Тела в Quoted-Printable будут надежно защищены при прохождении многих почтовых шлюзов, но могут быть не очень хорошо переданы через некоторые шлюзы, использующие трансляцию в EBCDIC. (Теоретически, EBCDIC-шлюз должен кодировать тело из quoted-printable в base64 и затем декодировать обратно, но таких шлюзов пока не существует). Единственный способ добится действительно надежной транспортировки через EBCDIC-шлюз — экранировать ASCII-символы.
!"#[email protected]
[\]^`{|}~
в соответствии с правилом #1.
Так как данные в quoted-printable являются строчно-ориентированными, можно ожидать, что представление концов строки в Quoted-Printable будет изменено почтовым транспортом таким же образом, как и обычный текст может измениться при пересылке по Internet-почте между системами с разными соглашениями по представлению концов строки. Если подобные изменения могут нарушить целостность данных, то имеет смысл пользоваться кодировкой base64, а не Quoted-Printable.
Вниманию создателей ПО: Если двоичные данные пересылаются в Quoted-Printable, то надо соблюдать осторожность при кодировании символов CR и LF. В частности, последовательность CRLF должна быть представлена как "=0D=0A", в противном случае, если CRLF означает конец строки, то она может быть неверно интерпретирована в платформах с другими соглашениями по концу строки.
Синтаксис данных в quoted-printable описывается следующим образом:
quoted-printable := ([*(простой текст / ПРОБЕЛ / ТАБУЛЯЦИЯ) простой текст]
["="] CRLF)
; Максимальная длина строки — 76 символов, включая CRLF
простой текст := байт /<любой ASCII-символ "=", ПРОБЕЛ или ТАБУЛЯЦИЯ>
; символы, не перечисленные в приложении B к RFC 1521 как безопас-
; ные для почты, также не рекомендуются к использованию
байт := "=" 2(ФИФРА / "A" / "B" / "C" / "D" / "E" / "F")
; байт используется для символов > 127, =, ПРОБЕЛ, или ТАБУЛЯЦИЯ,
; и рекомендуется для представления любых символов, не перечислен-
; ных в приложении B к RFC 1521 как безопасные для почты