RFC 2047               Message Header Extensions           November 1996   Only a subset of the printable ASCII characters may be used in   'encoded-text'.  Space and tab characters are not allowed, so that   the beginning and end of an 'encoded-word' are obvious.  The "?"   character is used within an 'encoded-word' to separate the various   portions of the 'encoded-word' from one another, and thus cannot   appear in the 'encoded-text' portion.  Other characters are also   illegal in certain contexts.  For example, an 'encoded-word' in a   'phrase' preceding an address in a From header field may not contain   any of the "specials" defined in RFC 822.  Finally, certain other   characters are disallowed in some contexts, to ensure reliability for   messages that pass through internetwork mail gateways.   The "B" encoding automatically meets these requirements.  The "Q"   encoding allows a wide range of printable characters to be used in   non-critical locations in the message header (e.g., Subject), with   fewer characters available for use in other locations.4.1. The "B" encoding   The "B" encoding is identical to the "BASE64" encoding defined by RFC   2045.4.2. The "Q" encoding   The "Q" encoding is similar to the "Quoted-Printable" content-   transfer-encoding defined in RFC 2045.  It is designed to allow text   containing mostly ASCII characters to be decipherable on an ASCII   terminal without decoding.   (1) Any 8-bit value may be represented by a "=" followed by two       hexadecimal digits.  For example, if the character set in use       were ISO-8859-1, the "=" character would thus be encoded as       "=3D", and a SPACE by "=20".  (Upper case should be used for       hexadecimal digits "A" through "F".)   (2) The 8-bit hexadecimal value 20 (e.g., ISO-8859-1 SPACE) may be       represented as "_" (underscore, ASCII 95.).  (This character may       not pass through some internetwork mail gateways, but its use       will greatly enhance readability of "Q" encoded data with mail       readers that do not support this encoding.)  Note that the "_"       always represents hexadecimal 20, even if the SPACE character       occupies a different code position in the character set in use.   (3) 8-bit values which correspond to printable ASCII characters other       than "=", "?", and "_" (underscore), MAY be represented as those       characters.  (But see section 5 for restrictions.)  In       particular, SPACE and TAB MUST NOT be represented as themselves       within encoded words.Moore                       Standards Track                     [Page 6]RFC 2047               Message Header Extensions           November 19965. Use of encoded-words in message headers   An 'encoded-word' may appear in a message header or body part header   according to the following rules:(1) An 'encoded-word' may replace a 'text' token (as defined by RFC 822)    in any Subject or Comments header field, any extension message    header field, or any MIME body part field for which the field body    is defined as '*text'.  An 'encoded-word' may also appear in any    user-defined ("X-") message or body part header field.    Ordinary ASCII text and 'encoded-word's may appear together in the    same header field.  However, an 'encoded-word' that appears in a    header field defined as '*text' MUST be separated from any adjacent    'encoded-word' or 'text' by 'linear-white-space'.(2) An 'encoded-word' may appear within a 'comment' delimited by "(" and    ")", i.e., wherever a 'ctext' is allowed.  More precisely, the RFC    822 ABNF definition for 'comment' is amended as follows:    comment = "(" *(ctext / quoted-pair / comment / encoded-word) ")"    A "Q"-encoded 'encoded-word' which appears in a 'comment' MUST NOT    contain the characters "(", ")" or "    'encoded-word' that appears in a 'comment' MUST be separated from    any adjacent 'encoded-word' or 'ctext' by 'linear-white-space'.    It is important to note that 'comment's are only recognized inside    "structured" field bodies.  In fields whose bodies are defined as    '*text', "(" and ")" are treated as ordinary characters rather than    comment delimiters, and rule (1) of this section applies.  (See RFC    822, sections 3.1.2 and 3.1.3)(3) As a replacement for a 'word' entity within a 'phrase', for example,    one that precedes an address in a From, To, or Cc header.  The ABNF    definition for 'phrase' from RFC 822 thus becomes:    phrase = 1*( encoded-word / word )    In this case the set of characters that may be used in a "Q"-encoded    'encoded-word' is restricted to: <upper and lower case ASCII    letters, decimal digits, "!", "*", "+", "-", "/", "=", and "_"    (underscore, ASCII 95.)>.  An 'encoded-word' that appears within a    'phrase' MUST be separated from any adjacent 'word', 'text' or    'special' by 'linear-white-space'.Moore                       Standards Track                     [Page 7]RFC 2047               Message Header Extensions           November 1996   These are the ONLY locations where an 'encoded-word' may appear.  In   particular:   + An 'encoded-word' MUST NOT appear in any portion of an 'addr-spec'.   + An 'encoded-word' MUST NOT appear within a 'quoted-string'.   + An 'encoded-word' MUST NOT be used in a Received header field.   + An 'encoded-word' MUST NOT be used in parameter of a MIME     Content-Type or Content-Disposition field, or in any structured     field body except within a 'comment' or 'phrase'.   The 'encoded-text' in an 'encoded-word' must be self-contained;   'encoded-text' MUST NOT be continued from one 'encoded-word' to   another.  This implies that the 'encoded-text' portion of a "B"   'encoded-word' will be a multiple of 4 characters long; for a "Q"   'encoded-word', any "=" character that appears in the 'encoded-text'   portion will be followed by two hexadecimal characters.   Each 'encoded-word' MUST encode an integral number of octets.  The   'encoded-text' in each 'encoded-word' must be well-formed according   to the encoding specified; the 'encoded-text' may not be continued in   the next 'encoded-word'.  (For example, "=?charset?Q?=?=   =?charset?Q?AB?=" would be illegal, because the two hex digits "AB"   must follow the "=" in the same 'encoded-word'.)   Each 'encoded-word' MUST represent an integral number of characters.   A multi-octet character may not be split across adjacent 'encoded-   word's.   Only printable and white space character data should be encoded using   this scheme.  However, since these encoding schemes allow the   encoding of arbitrary octet values, mail readers that implement this   decoding should also ensure that display of the decoded data on the   recipient's terminal will not cause unwanted side-effects.   Use of these methods to encode non-textual data (e.g., pictures or   sounds) is not defined by this memo.  Use of 'encoded-word's to   represent strings of purely ASCII characters is allowed, but   discouraged.  In rare cases it may be necessary to encode ordinary   text that looks like an 'encoded-word'.Moore                       Standards Track                     [Page 8]RFC 2047               Message Header Extensions           November 19966. Support of 'encoded-word's by mail readers6.1. Recognition of 'encoded-word's in message headers   A mail reader must parse the message and body part headers according   to the rules in RFC 822 to correctly recognize 'encoded-word's.   'encoded-word's are to be recognized as follows:   (1) Any message or body part header field defined as '*text', or any       user-defined header field, should be parsed as follows: Beginning       at the start of the field-body and immediately following each       occurrence of 'linear-white-space', each sequence of up to 75       printable characters (not containing any 'linear-white-space')       should be examined to see if it is an 'encoded-word' according to       the syntax rules in section 2.  Any other sequence of printable       characters should be treated as ordinary ASCII text.   (2) Any header field not defined as '*text' should be parsed       according to the syntax rules for that header field.  However,       any 'word' that appears within a 'phrase' should be treated as an       'encoded-word' if it meets the syntax rules in section 2.       Otherwise it should be treated as an ordinary 'word'.   (3) Within a 'comment', any sequence of up to 75 printable characters       (not containing 'linear-white-space'), that meets the syntax       rules in section 2, should be treated as an 'encoded-word'.       Otherwise it should be treated as normal comment text.   (4) A MIME-Version header field is NOT required to be present for       'encoded-word's to be interpreted according to this       specification.  One reason for this is that the mail reader is       not expected to parse the entire message header before displaying       lines that may contain 'encoded-word's.6.2. Display of 'encoded-word's   Any 'encoded-word's so recognized are decoded, and if possible, the   resulting unencoded text is displayed in the original character set.   NOTE: Decoding and display of encoded-words occurs *after* a   structured field body is parsed into tokens.  It is therefore   possible to hide 'special' characters in encoded-words which, when   displayed, will be indistinguishable from 'special' characters in the   surrounding text.  For this and other reasons, it is NOT generally   possible to translate a message header containing 'encoded-word's to   an unencoded form which can be parsed by an RFC 822 mail reader.Moore                       Standards Track                     [Page 9]RFC 2047               Message Header Extensions           November 1996   When displaying a particular header field that contains multiple   'encoded-word's, any 'linear-white-space' that separates a pair of   adjacent 'encoded-word's is ignored.  (This is to allow the use of   multiple 'encoded-word's to represent long strings of unencoded text,   without having to separate 'encoded-word's where spaces occur in the   unencoded text.)   In the event other encodings are defined in the future, and the mail   reader does not support the encoding used, it may either (a) display   the 'encoded-word' as ordinary text, or (b) substitute an appropriate   message indicating that the text could not be decoded.   If the mail reader does not support the character set used, it may   (a) display the 'encoded-word' as ordinary text (i.e., as it appears   in the header), (b) make a "best effort" to display using such   characters as are available, or (c) substitute an appropriate message   indicating that the decoded text could not be displayed.   If the character set being used employs code-switching techniques,   display of the encoded text implicitly begins in "ASCII mode".  In   addition, the mail reader must ensure that the output device is once   again in "ASCII mode" after the 'encoded-word' is displayed.6.3. Mail reader handling of incorrectly formed 'encoded-word's   It is possible that an 'encoded-word' that is legal according to the   syntax defined in section 2, is incorrectly formed according to the   rules for the encoding being used.   For example:   (1) An 'encoded-word' which contains characters which are not legal       for a particular encoding (for example, a "-" in the "B"       encoding, or a SPACE or HTAB in either the "B" or "Q" encoding),       is incorrectly formed.   (2) Any 'encoded-word' which encodes a non-integral number of       characters or octets is incorrectly formed.   A mail reader need not attempt to display the text associated with an   'encoded-word' that is incorrectly formed.  However, a mail reader   MUST NOT prevent the display or handling of a message because an   'encoded-word' is incorrectly formed.7. Conformance   A mail composing program claiming compliance with this specification   MUST ensure that any string of non-white-space printable ASCII   characters within a '*text' or '*ctext' that begins with "=?" and   ends with "?=" be a valid 'encoded-word'.  ("begins" means: at theMoore                       Standards Track                    [Page 10]RFC 2047               Message Header Extensions           November 1996