rfc1342.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 395 行 · 第 1/2 页

   valid charset parameters).

   When there is a possibility of using more than one character set to
   represent the text in an encoded-word, and in the absence of private
   agreements between sender and recipients of a message, it is
   recommended that members of the ISO-8859-* series be used in
   preference to other character sets.  Among the various ISO-8859-*
   character sets, the lowest-numbered set which contains all of the
   required characters should be used.

Use of encoded-words in message headers

   A sequence of one or more encoded-words is used to represent non-
   ASCII textual data within a header field.  An encoded-word must be
   separated from an adjacent encoded-word, "word", "text", "ctext", or
   "special" by a linear white-space character or a newline.  When
   displaying a particular header field" (in the RFC 822 sense)
   containing one or more encoded-words, an unencoded SPACE character
   that immediately follows the encoded-word is not displayed.  A
   newline that immediately follows an encoded-word is not displayed
   unless the encoded-word is the last token in that "field".  (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.)



Moore                                                           [Page 4]

RFC 1342                 Non-ASCII Mail Headers                June 1992


   An encoded-word may appear in a message header or body part header
   according to the following rules:

- An encoded-word may replace a "text" token (as defined by RFC 822) in:
  (1) a Subject or Comments header field, (2) any extension message
  header field, (3) any user-defined message header field, or (4) any
  RFC 1341 body part header field (such as Content-Description) for
  which the field body contains only "text"s.

- An encoded-word may appear within a comment delimited by "(" and ")",
  i.e., wherever a "ctext" is allowed.  More precisely, the RFC 822 EBNF
  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 "\".

- 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 EBNF
  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.)>.

  These are the ONLY locations where an encoded-word may appear.  In
  particular, an encoded-word MUST NOT appear in any portion of an
  "address".  In addition, an encoded-word MUST NOT be used in a
  Received header field.

  Whenever such words appear in a header being displayed, an enlightened
  mail reader will decode the text and render it appropriately.

  Only textual data (printable and white space characters) should be
  encoded using this scheme.  However, since these encoding schemes
  allow the encoding of arbitrary 8-bit 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
  represent strings of purely ASCII characters is allowed, but
  discouraged.



Moore                                                           [Page 5]

RFC 1342                 Non-ASCII Mail Headers                June 1992


Recognition of encoded-words in message headers.

   An encoded-word may be distinguished from an ordinary "word", "text",
   or "ctext", as follows: An encoded-word begins with "=?", ends with
   "?=", contains exactly four "?" characters including the delimiters,
   and is followed by a SPACE or newline.  If the "word", "text", or
   "ctext" does not meet the above tests, it should be displayed as it
   appears in the message header.

   If the mail reader does not support the character set used, it may
   either display the encoded-word as ordinary text (i.e., as it appears
   in the header), or it may substitute an appropriate message
   indicating that the decoded text could not be displayed.

Conformance

   A mail composing program claiming compliance with this specification
   MUST ensure that any string of printable ASCII characters in a
   message header that begins with "=?" and ends with "?=" 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 anytime they appear in appropriate places in message headers.
   The program must be able to display unencoded text if the character
   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.

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






Moore                                                           [Page 6]

RFC 1342                 Non-ASCII Mail Headers                June 1992


   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

References

   [1] Borenstein N., and N. Freed, "MIME (Multipurpose Internet Mail
       Extensions):  Mechanisms for Specifying and Describing the Format
       of Internet Message Bodies", RFC 1341, Bellcore, Innosoft,
       June 1992.

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

Security Considerations

   Security issues are not discussed in this memo.

Author's Address

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

   EMail: [e-mail]




















Moore                                                           [Page 7]