rfc1522.txt

中、英文RFC文档大全打包下载完全版 .


RFC 1522                     MIME Part Two                September 1993


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

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

   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".  In addition, an encoded-word MUST NOT be used in a
   Received header field.

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

   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-words to



Moore                                                           [Page 6]

RFC 1522                     MIME Part Two                September 1993


   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.

6. Support of encoded-words by mail readers

6.1. Recognition of encoded-words 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-words.

   Encoded-words 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.

6.2. Display of encoded-words

   Any encoded-words so recognized are decoded, and if possible, the
   resulting unencoded text is displayed in the original character set.

   When displaying a particular header field that contains multiple
   encoded-words, any linear-white-space that separates a pair of
   adjacent encoded-words is ignored.  (This is to allow the use of
   multiple encoded-words to represent long strings of unencoded text,
   without having to separate encoded-words 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



Moore                                                           [Page 7]

RFC 1522                     MIME Part Two                September 1993


   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-words

   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),
       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 the
   start of the field-body or immediately following linear-white-space;
   "ends" means: at the end of the field-body or immediately preceding
   linear-white-space.) In addition, any "word" within a "phrase" that
   begins with "=?" and ends with "?=" must be a valid encoded-word.

   A mail reading program claiming compliance with this specification
   must be able to distinguish encoded-words from "text", "ctext", or
   "word"s, according to the rules in section 6, anytime they appear in
   appropriate places in message headers.  It must support both the "B"
   and "Q" encodings for any character set which it supports.  The
   program must be able to display the unencoded text if the character



Moore                                                           [Page 8]

RFC 1522                     MIME Part Two                September 1993


   set is "US-ASCII".  For the ISO-8859-* character sets, the mail
   reading program must at least be able to display the characters which
   are also in the ASCII set.

8. Examples

      From: =?US-ASCII?Q?Keith_Moore?= <[e-mail]>
      To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= <[e-mail]>
      CC: =?ISO-8859-1?Q?Andr=E9_?= Pirard <[e-mail]>
      Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?=
       =?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?=

      From: =?ISO-8859-1?Q?Olle_J=E4rnefors?= <[e-mail]>
      To: [e-mail], [e-mail]
      Subject: Time for ISO 10646?

      To: Dave Crocker <[e-mail]>
      Cc: [e-mail], [e-mail]
      From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[e-mail]>
      Subject: Re: RFC-HDR care and feeding

      From: Nathaniel Borenstein <[e-mail]>
            (=?iso-8859-8?b?7eXs+SDv4SDp7Oj08A==?=)
      To: Greg Vaudreuil <[e-mail]>, Ned Freed
         <[e-mail]>, Keith Moore <[e-mail]>
      Subject: Test of new header generator
      MIME-Version: 1.0
      Content-type: text/plain; charset=ISO-8859-1

9. References

   [1] Borenstein N., and N. Freed, "MIME (Multipurpose Internet Mail
       Extensions) Part One:  Mechanisms for Specifying and Describing
       the Format of Internet Message Bodies", RFC 1521, Bellcore,
       Innosoft, September 1993.

   [2] Crocker, D., "Standard for the Format of ARPA Internet Text
       Messages", STD 11, RFC 822, UDEL, August 1982.

   [3] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
       RFC 1340, USC/Information Sciences Institute, July 1992.










Moore                                                           [Page 9]

RFC 1522                     MIME Part Two                September 1993


10. Security Considerations

   Security issues are not discussed in this memo.

11. Author's Address

   Keith Moore
   University of Tennessee
   107 Ayres Hall
   Knoxville TN 37996-1301

   EMail: [e-mail]







































Moore                                                          [Page 10]