Quoted-Printable, or QP encoding, is a binary-to-text encoding system using printable ASCII characters (alphanumeric and the equals sign = ) to transmit 8-bit data over a 7-bit data path or, generally, over a medium which is not 8-bit clean. [1] It is defined as a MIME content transfer encoding for use in e-mail.
QP works by using the equals sign = as an escape character. It also limits line length to 76, as some software has limits on line length.
Содержание
Contents
Introduction [ edit ]
MIME defines mechanisms for sending other kinds of information in e-mail, including text in languages other than English, using character encodings other than ASCII. However, these encodings often use byte values outside the ASCII range so they need to be encoded further before they are suitable for use in a non-8-bit-clean environment. Quoted-Printable encoding is one method used for mapping arbitrary bytes into sequences of ASCII characters. So, Quoted-Printable is not a character encoding scheme itself, but a data coding layer to be used under some byte-oriented character encoding. QP encoding is reversible, meaning the original bytes and hence the non-ASCII characters they represent can be identically recovered.
Quoted-Printable and Base64 are the two basic MIME content transfer encodings, if a trivial "8bit" encoding is not counted. If the text to be encoded does not contain many non-ASCII characters, then Quoted-Printable results in a fairly readable [2] and compact encoded result. On the other hand, if the input is not mostly ASCII, then Quoted-Printable becomes both unreadable and extremely inefficient. Base64 is not human-readable, but has a uniform overhead for all data and is the more sensible choice for binary formats or text in a script other than Latin script.
Quoted-Printable encoding [ edit ]
Any 8-bit byte value may be encoded with 3 characters: an = followed by two hexadecimal digits ( 0 – 9 or A – F ) representing the byte’s numeric value. For example, an ASCII form feed character (decimal value 12) can be represented by " =0C ", and an ASCII equal sign (decimal value 61) must be represented by =3D . All characters except printable ASCII characters or end of line characters (but also = ) must be encoded in this fashion.
All printable ASCII characters (decimal values between 33 and 126) may be represented by themselves, except = (decimal 61).
ASCII tab and space characters, decimal values 9 and 32, may be represented by themselves, except if these characters would appear at the end of the encoded line. In that case, they would need to be escaped as =09 (tab) or =20 (space), or be followed by a = (soft line break) as the last character of the encoded line. This last solution is valid because it prevents the tab or space from being the last character of the encoded line.
If the data being encoded contains meaningful line breaks, they must be encoded as an ASCII CR LF sequence, not as their original byte values, neither directly nor via = signs. Conversely, if byte values 13 and 10 have meanings other than end of line (in media types, [3] for example), then they must be encoded as =0D and =0A respectively.
Lines of Quoted-Printable encoded data must not be longer than 76 characters. To satisfy this requirement without altering the encoded text, soft line breaks may be added as desired. A soft line break consists of an = at the end of an encoded line, and does not appear as a line break in the decoded text. These soft line breaks also allow encoding text without line breaks (or containing very long lines) for an environment where line size is limited, such as the 1000 characters per line limit of some SMTP software, as allowed by RFC 2821.
A slightly modified version of Quoted-Printable is used in message headers; see MIME#Encoded-Word.
Example [ edit ]
The following example is a French text (encoded in UTF-8), with a high frequency of letters with diacritical marks (such as the é).
This encodes the following quotation:
J’interdis aux marchands de vanter trop leurs marchandises. Car ils se font vite pédagogues et t’enseignent comme but ce qui n’est par essence qu’un moyen, et te trompant ainsi sur la route à suivre les voilà bientôt qui te dégradent, car si leur musique est vulgaire ils te fabriquent pour te la vendre une âme vulgaire.
It is necessary, therefore, to define a standard mechanism for re-encoding such data into a 7-bit short-line format. This document specifies that such encodings will be indicated by a new "Content-Transfer-Encoding" header field. The Content-Transfer-Encoding field is used to indicate the type of transformation that has been used in order to represent the body in an acceptable manner for transport.
Unlike Content-Types, a proliferation of Content-Transfer- Encoding values is undesirable and unnecessary. However, establishing only a single Content-Transfer-Encoding mechanism does not seem possible. There is a tradeoff between the desire for a compact and efficient encoding of largely-binary data and the desire for a readable encoding of data that is mostly, but not entirely, 7-bit data. For this reason, at least two encoding mechanisms are necessary: a "readable" encoding and a "dense" encoding.
The Content-Transfer-Encoding field is designed to specify an invertible mapping between the "native" representation of a type of data and a representation that can be readily exchanged using 7 bit mail transport protocols, such as those defined by RFC 821 (SMTP). This field has not been defined by any previous standard. The field’s value is a single token specifying the type of encoding, as enumerated below. Formally: These values are not case sensitive. That is, Base64 and BASE64 and bAsE64 are all equivalent. An encoding type of 7BIT requires that the body is already in a seven-bit mail- ready representation. This is the default value — that is, "Content-Transfer-Encoding: 7BIT" is assumed if the Content-Transfer-Encoding header field is not present.
The values "8bit", "7bit", and "binary" all imply that NO encoding has been performed. However, they are potentially useful as indications of the kind of data contained in the object, and therefore of the kind of encoding that might need to be performed for transmission in a given transport system. "7bit" means that the data is all represented as short lines of US-ASCII data. "8bit" means that the lines are short, but there may be non-ASCII characters (octets with the high-order bit set). "Binary" means that not only may non-ASCII characters be present, but also that the lines are not necessarily short enough for SMTP transport.
The difference between "8bit" (or any other conceivable bit-width token) and the "binary" token is that "binary" does not require adherence to any limits on line length or to the SMTP CRLF semantics, while the bit-width tokens do require such adherence. If the body contains data in any bit-width other than 7-bit, the appropriate bit-width Content-Transfer-Encoding token must be used (e.g., "8bit" for unencoded 8 bit wide data). If the body contains binary data, the "binary" Content-Transfer-Encoding token must be used.
As of the publication of this document, there are no standardized Internet transports for which it is legitimate to include unencoded 8-bit or binary data in mail bodies. Thus there are no circumstances in which the "8bit" or "binary" Content-Transfer-Encoding is actually legal on the Internet. However, in the event that 8-bit or binary mail transport becomes a reality in Internet mail, or when this document is used in conjunction with any other 8-bit or binary-capable transport mechanism, 8-bit or binary bodies should be labeled as such using this mechanism.
Implementors may, if necessary, define new Content- Transfer-Encoding values, but must use an x-token, which is a name prefixed by "X-" to indicate its non-standard status, e.g., "Content-Transfer-Encoding: x-my-new-encoding". However, unlike Content-Types and subtypes, the creation of new Content-Transfer-Encoding values is explicitly and strongly discouraged, as it seems likely to hinder interoperability with little potential benefit. Their use is allowed only as the result of an agreement between cooperating user agents.
If a Content-Transfer-Encoding header field appears as part of a message header, it applies to the entire body of that message. If a Content-Transfer-Encoding header field appears as part of a body part’s headers, it applies only to the body of that body part. If an entity is of type "multipart" or "message", the Content-Transfer-Encoding is not permitted to have any value other than a bit width (e.g., "7bit", "8bit", etc.) or "binary".
It should be noted that email is character-oriented, so that the mechanisms described here are mechanisms for encoding arbitrary byte streams, not bit streams. If a bit stream is to be encoded via one of these mechanisms, it must first be converted to an 8-bit byte stream using the network standard bit order ("big-endian"), in which the earlier bits in a stream become the higher-order bits in a byte. A bit stream not ending at an 8-bit boundary must be padded with zeroes. This document provides a mechanism for noting the addition of such padding in the case of the application Content-Type, which has a "padding" parameter.
The encoding mechanisms defined here explicitly encode all data in ASCII. Thus, for example, suppose an entity has header fields such as: This should be interpreted to mean that the body is a base64 ASCII encoding of data that was originally in ISO-8859-1, and will be in that character set again after decoding.
The following sections will define the two standard encoding mechanisms. The definition of new content-transfer- encodings is explicitly discouraged and should only occur when absolutely necessary. All content-transfer-encoding namespace except that beginning with "X-" is explicitly reserved to the IANA for future use. Private agreements about content-transfer-encodings are also explicitly discouraged.
Certain Content-Transfer-Encoding values may only be used on certain Content-Types. In particular, it is expressly forbidden to use any encodings other than "7bit", "8bit", or "binary" with any Content-Type that recursively includes other Content-Type fields, notably the "multipart" and "message" Content-Types. All encodings that are desired for bodies of type multipart or message must be done at the innermost level, by encoding the actual body that needs to be encoded.
NOTE ON ENCODING RESTRICTIONS:
NOTE ON THE RELATIONSHIP BETWEEN CONTENT-TYPE AND CONTENT- TRANSFER-ENCODING
NOTE ON TRANSLATING ENCODINGS
NOTE ON CANONICAL ENCODING MODEL:
5.1 Quoted-Printable Content-Transfer-Encoding
In this encoding, octets are to be represented as determined by the following rules:
Rule #1: (General 8-bit representation)
Rule #2: (Literal representation) Octets with decimal values of 33 through 60 inclusive, and 62 through 126, inclusive, MAY be represented as the ASCII characters which correspond to those octets (EXCLAMATION POINT through LESS THAN, and GREATER THAN through TILDE, respectively).
Rule #3: (White Space)
Rule #4 (Line Breaks)
Note that many implementation may elect to encode the local representation of various content types directly. In particular, this may apply to plain text material on systems that use newline conventions other than CRLF delimiters. Such an implementation is permissible, but the generation of line breaks must be generalized to account for the case where alternate representations of newline sequences are used.
Rule #5 (Soft Line Breaks)
Since the hyphen character ("-") is represented as itself in the Quoted-Printable encoding, care must be taken, when encapsulating a quoted-printable encoded body in a multipart entity, to ensure that the encapsulation boundary does not appear anywhere in the encoded body. (A good strategy is to choose a boundary that includes a character sequence such as "=_" which can never appear in a quoted-printable body. See the definition of multipart messages later in this document.)
NOTE: The quoted-printable encoding represents something of a compromise between readability and reliability in transport. Bodies encoded with the quoted-printable encoding will work reliably over most mail gateways, but may not work perfectly over a few gateways, notably those involving translation into EBCDIC. (In theory, an EBCDIC gateway could decode a quoted-printable body and re-encode it using base64, but such gateways do not yet exist.) A higher level of confidence is offered by the base64 Content-Transfer-Encoding. A way to get reasonably reliable transport through EBCDIC gateways is to also quote the ASCII characters according to rule #1. See Appendix B for more information.
Because quoted-printable data is generally assumed to be line-oriented, it is to be expected that the breaks between the lines of quoted printable data may be altered in transport, in the same manner that plain text mail has always been altered in Internet mail when passing between systems with differing newline conventions. If such alterations are likely to constitute a corruption of the data, it is probably more sensible to use the base64 encoding rather than the quoted-printable encoding.
5.2 Base64 Content-Transfer-Encoding
A 65-character subset of US-ASCII is used, enabling 6 bits to be represented per printable character. (The extra 65th character, "=", is used to signify a special processing function.)
NOTE: This subset has the important property that it is represented identically in all versions of ISO 646, including US ASCII, and all characters in the subset are also represented identically in all versions of EBCDIC. Other popular encodings, such as the encoding used by the UUENCODE utility and the base85 encoding specified as part of Level 2 PostScript, do not share these properties, and thus do not fulfill the portability requirements a binary transport encoding for mail must meet.
The encoding process represents 24-bit groups of input bits as output strings of 4 encoded characters. Proceeding from left to right, a 24-bit input group is formed by concatenating 3 8-bit input groups. These 24 bits are then treated as 4 concatenated 6-bit groups, each of which is translated into a single digit in the base64 alphabet. When encoding a bit stream via the base64 encoding, the bit stream must be presumed to be ordered with the most- significant-bit first. That is, the first bit in the stream will be the high-order bit in the first byte, and the eighth bit will be the low-order bit in the first byte, and so on.
Each 6-bit group is used as an index into an array of 64 printable characters. The character referenced by the index is placed in the output string. These characters, identified in Table 1, below, are selected so as to be universally representable, and the set excludes characters with particular significance to SMTP (e.g., ".", "CR", "LF") and to the encapsulation boundaries defined in this document (e.g., "-").
Table 1: The Base64 Alphabet
Special processing is performed if fewer than 24 bits are available at the end of the data being encoded. A full encoding quantum is always completed at the end of a body. When fewer than 24 input bits are available in an input group, zero bits are added (on the right) to form an integral number of 6-bit groups. Output character positions which are not required to represent actual input data are set to the character "=". Since all base64 input is an integral number of octets, only the following cases can arise: (1) the final quantum of encoding input is an integral multiple of 24 bits; here, the final unit of encoded output will be an integral multiple of 4 characters with no "=" padding, (2) the final quantum of encoding input is exactly 8 bits; here, the final unit of encoded output will be two characters followed by two "=" padding characters, or (3) the final quantum of encoding input is exactly 16 bits; here, the final unit of encoded output will be three characters followed by one "=" padding character.
Care must be taken to use the proper octets for line breaks if base64 encoding is applied directly to text material that has not been converted to canonical form. In particular, text line breaks should be converted into CRLF sequences prior to base64 encoding. The important thing to note is that this may be done directly by the encoder rather than in a prior canonicalization step in some implementations.
NOTE: There is no need to worry about quoting apparent encapsulation boundaries within base64-encoded parts of multipart entities because no hyphen characters are used in the base64 encoding.
Многие типы данных, пересылаемых через email требуют "натурального" представления, то есть, 8-битный набор символов либо двоичный код (что для машины — одно и то же, только представимо для пользователя по-разному). В таком виде данные не могут быть пересланы по 7-битным почтовым протоколам, например, RFC 821, который, к тому же, ограничивает длину строки 1000 символами.
Стандартные механизмы конвертирования почты в 7-битный короткострочный формат, приемлимый для почтового транспорта, описывает поле заголовка Content-Transfer-Encoding.
В отличие от типов содержимого, увеличение множества значений Content-Transfer-Encoding не является необходимым и даже нежелательно. Но установление единого механизма конвертирования не представляется возможным. Существует противоречие между желанием эффективно "ужать" бинарные данные и желанием трансформировать данные, которые, хотя бы частично являются 7-битным текстом, так, чтобы их все-таки можно было читать. По этой причине необходимы по крайней мере 2 механизма конвертации: "читабельный" и "плотно ужимающий".
Данное поле не было определено в предыдущих стандартах. Его значение должно быть строкой без пробелов, определяющей тип конвертации, как показано ниже:
Значения не чувствительны к регистру букв, то есть, Base64, BASE64 и bAsE64 — одно и то же. Значение "7BIT" означает, что тело письма уже имеет 7-битный формат и не тренбует дополнительной обработки для пересылки по почте. Это значение полагается по умолчанию, если поле заголовка Content-Transfer-Encoding отсутствует.
Значения "8bit", "7bit" и "binary" означают, что никакой трансформации содержимого не производится. Однако, они сделаны различными для индикации того, что из себя представляет содержимое письма, и, соответственно, способа обработки, который может потребоваться для данной транспортной системы. В частности:
"7bit" означает, что данные являются текстом, имеют короткие строки и языковую кодировку US-ASCII.
"8bit" означает короткие строки, но в них могут содержаться не-ASCII символы (128-255).
"Binary" означает, что тело письма может содержать не-ASCII символы, но строки могут быть произвольной длины, т.е. слишком длинными для SMTP-транспорта, и может несоблюдаться соглашение по признаку конца строки (CRLF), принятое в SMTP-транспорте.
Хотя на первый взгляд разница в значениях Content-Transfer-Encoding может показатся неважной — ведь все они означают, что никакого преобразования нет, но четкая разметка важна для почтовых шлюзов между разными почтовыми системами, имеющими разные возможности и особенности работы, число которых со временем растет.
Спецификация на почтовый транспорт для пересылки некодированных 8-битных данных дана в RFC-1426. Однако, нет стандартизованных транспортов рочты Internet, для которых является приемлимым включение в тело письма некодированных двоичных данных. Таким образом, значение "binary" фактически не является легальным в Internet. Но в соответствии с MIME, при использовании почтовой системой транспорта, умеющего работать с двоичными данными, в случае, когда необходимо послать двоичные данные по e-mail, необходимо указать это в заголовке в поле Content-Transfer-Encoding.
Пять значений, определенных для поля Content-Transfer-Encoding, ничего не говорят о типе содержимого кроме указания алгоритма кодирования либо требований к почтовому транспорту в случае некодированных данных.
Производители почтового ПО, если необходимо, могут определить новые значения поля Content-Transfer-Encoding, но эти значения должны иметь префикс "X-" ("x-"), чтобы подчеркнуть их нестандартный характер. Однако, в отличие от типов и подтипов поля Content-Type, введение новых значений Content-Transfer-Encoding настоятельно не рекомендуется, так как может оказаться помехой для взаимосовместимости почтовых систем. Использование X-значений позволяется только как результат взаимосоглашения между взаимодействующими системами.
Если поле Content-Transfer-Encoding появляеися в заголовке тела какой-то части письма, оно применяется только к содержимому этой части. Если письмо (часть письма) имеет тип "multipart" или "message", то поле Content-Transfer-Encoding может иметь в качестве своего значения только длину символа ("7bit", "8bit" и т.д.) или "binary".
Необходимо заметить. что электронная почта является символьно-ориентированной, так что механизмы конвертации работают с данными как с потоком символов, а не битов. Если битовый поток должен быть кодирован посредством какого-либо из этих механизмов, сначала он должен быть конвертирован в 8-битный поток байтов, используя порядок битов, стандартный для сетей (старшие разряды в конце). То есть, передние биты в потоке становятся битами высшего порядка в байте. Если битовый поток оканчивается неполным байтом, недостающие разряды заполняются нулями.
Все кодирующие механизмы, определенные в спецификации MIME, кодируют любые данные в символьную форму. Так, к примеру, полагая, что тело письма (части письма) имеет поля заголовка вроде:
то это означает, что тело письма представляет собой ASCII-код base64 текстовых данных, которые в нормальном виде имеют языковую кодировку ISO-8859-1, и будут в этой языковой кодировке после декодирования.
Все множество определенных значений поля content-transfer-encoding кроме начинающихся с префикса "X-", зарезервировано в IANA для будущего использования. Частные соглашения по значениям content-transfer-encoding также настоятельно не рекомендуются.
Некоторые значения Content-transfer-encoding могут использоваться только с определенными типами (поле Content-Type). В частности, запрещено использовать любые значения кроме "7bit", "8bit", или "binary" с любым типом, рекурсивно включающим заголовки с полем Content-Type (как правило, это типы "multipart" и "message"). Все кодирования, необходимые для содержимого тел многочастного письма должны быть произведены на более низком уровне.
Замечания по ограничениям конвертации
Необходимо предотвращать случаи вложенного кодирования, когда данные проходят через алгоритм конвертации несколько раз и должны столько же раз быть декодированы, чтобы быть читаемыми. Вложенное кодирование добавляет сложностей пользовательским почтовым программам: кроме очевидных проблем с множественной конвертацией, они могут скрыть основную структуру письма. В частности, они могут привести к тому, что несколько операций по декодированию могут потребоваться только для того, чтобы определить, объекты каких типов находятся в письме. Запрещение вложенного кодирования может осложнить работу некоторых почтовых шлюзов, но это будет меньшей проблемой по сравнению с трудностями для пользовательских почтовых программ.
ЗАМЕЧАНИЕ ПО ПЕРЕВОДУ КОДОВ: Конверторы quoted-printable и base64 разработаны так, что данные после их применения легко взаимоконвертируемы. Единственный нюанс, возникающий в подобной ретрансляции — признак конца строки. При конвертации из quoted-printable в base64 перевод строки должен быть заменен последовательностью CRLF. Соответственно и наоборот, но ТОЛЬКО при конвертации текстовых данных.
Механизм конвертации "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 символов. В противном случае используется ‘мягкий’ перевод строки, представимый знаком равенства. Например, если исходная строка имела вид:
то в Quoted-Printable encoding он может быть представлена следующим образом:
Это обеспечивает механизм восстановления исходной длины строки пользовательским почтовыи агентом.
Поскольку символ дефиса ("-") представляется в Quoted-Printable в обычном виде, особую осторожность нужно соблюдать при заключении тела в Quoted-Printable в многочастное письмо, чтобы удостовериться, что граница этого включения не проявляется нигде внутри этого включения (лучше всего выбрать обозначение границы в виде последовательности символов "=_", которая никогда не появляется в теле, закодированном в Quoted-Printable.)
ЗАМЕЧАНИЕ: Quoted-Printable представляет собой нечто вроде компромисса между читабельностью и сохранностью при пересылке. Тела в Quoted-Printable будут надежно защищены при прохождении многих почтовых шлюзов, но могут быть не очень хорошо переданы через некоторые шлюзы, использующие трансляцию в EBCDIC. (Теоретически, EBCDIC-шлюз должен кодировать тело из quoted-printable в base64 и затем декодировать обратно, но таких шлюзов пока не существует). Единственный способ добится действительно надежной транспортировки через EBCDIC-шлюз — экранировать ASCII-символы
в соответствии с правилом #1.
Так как данные в quoted-printable являются строчно-ориентированными, можно ожидать, что представление концов строки в Quoted-Printable будет изменено почтовым транспортом таким же образом, как и обычный текст может измениться при пересылке по Internet-почте между системами с разными соглашениями по представлению концов строки. Если подобные изменения могут нарушить целостность данных, то имеет смысл пользоваться кодировкой base64, а не Quoted-Printable.
Вниманию создателей ПО: Если двоичные данные пересылаются в Quoted-Printable, то надо соблюдать осторожность при кодировании символов CR и LF. В частности, последовательность CRLF должна быть представлена как "=0D=0A", в противном случае, если CRLF означает конец строки, то она может быть неверно интерпретирована в платформах с другими соглашениями по концу строки.
Синтаксис данных в quoted-printable описывается следующим образом:
Механизм конвертации Base64
Этот алгоритм разработан для представления произвольных последовательностей байтов в форму, читаемую для человека. Кодирующий и декодирующий алгоритмы очень просты, но закодированные данные примерно на 33% больше, чем некодированные. этот метод идентичен тому, который используется в приложениях PEM (Privacy Enhanced Mail), описанной в RFC 1421 с одним отличием: base64 не приемлит встроенного "чистого" текста.
Base64 использует 65-символьный поднабор из US-ASCII, выделяя 6 бит на каждый печатный символ. (65-й символ "=" используется для обозначения функции спец. обработки).
ПРИМЕЧАНИЕ: этот поднабор имеет важное свойство: он идентичен всем версиям языковой кодировки ISO 646, включая US ASCII, а также всем версиям EBCDIC. Другие популярные механизмы кодирования (uuencode, base85 — часть уровня 2 PostScript) не разделяют этих свойств и поэтому не удовлетворяют требованиям переносимости для двоичных данных электронной почты.
Процесс кодирования преобразует 4 входных символа в виде 24-битной группы, обрабатывая их слева направо. Эти группы затем рассматриваются как 4 соединенные 6-битные группы, каждая из которых транслируется в одиночную цифру алфавита base64. При кодировании base64, входной поток байтов должен быть упорядочен старшими битами вперед.
Каждая 6-битная группа используется как индекс для массива 64-х печатных символов. Символ, на который указывает значение индекса, помещается в выходную строку. Эти символы выбраны так, чтобы быть универсально представимыми и исключают символы, имеющие специальное значение для SMTP-транспорта (".", CR, LF) и для синтаксиса вложенных тел MIME ("-").
Выходной поток (закодированные бфайты) должен иметь длину строк не более 76 символов. Все признаки перевода строки и другие символы, отсутствующие в таблице 1, должны быть проигнорированы декодером base64. Среди данных в Base64 символы, не перечисленные в табл. 1, переводы строки и т.п. должны говорить об ошибке передачи данных, и, соответственно, почтовая программа должна оповестить пользователя о ней.
Если в хвосте потока кодируемых данных осталось меньше, чем 24 бита, справа добавляются нулевые биты до образования целого числа 6-битных групп. А до конца 24-битной группы остается от 0 до 3-х недостающих 6-битных групп, вместо каждой из которых ставится символ-заполнитель ‘=’. Поскольку весь входной поток представляет собой целое число 8-битных групп (т.е., просто байтных значений), то возможны лишь следующие случаи: (1) входной поток как раз оканчивается 24-битной группой. В таком случае, выходной поток будет оканчиваться четырьмя символами Base64 без символа ‘=’; (2) хвост входного потока имеет длину 8 бит. Тогда в конце выходного кода быдут два символа Base64, с добавлением двух символов ‘=’; (3) хвост входного потока имеет длину 16 бит. Тогда в конце выходного будут стоять три символа Base64 и один символ ‘=’.
Т.к. символ ‘=’ является хвостовым заполнителем, его появление в теле письма может означать только то, что конец данных достигнут. Но такой гарантии нет, если число переданных битов кратно 24.
Любые бессмысленные последовательности в коде Base64 вроде "=====" должны быть игнорированы.
Если кодируемый текст не находится в канонической форме. то перед конвертацией в Base64 необходимо сначала все концы строк заменить стандартной последовательностью CRLF. Предпочтительнее эту функцию встроить в кодировщик Base64, нежели заставлять пользователя производить предварительную канонизацию текста другими средствами.
Нет нужды экранировать вложенные тела внутри многочастного тела (multipart) при кодировании его в Base64, так как в коде Base64 отсутствует символ ‘-‘.
