+ 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'.










 
RFC 2047               Message Header Extensions           November 1996


6. Support of 'encoded-word's by mail readers

6.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