rfc2045-multipurposeinternetmailextensions(mime).mht

很好的原始资料 RFC 2045 (rfc2045) - Multipurpose Internet Mail Extensions (MIME) Part One

          of an encoded line.  Any TAB (HT) or SPACE characters
          on an encoded line MUST thus be followed on that line
          by a printable character.  In particular, an "=3D" at the
          end of an encoded line, indicating a soft line break
          (see rule #5) may follow one or more TAB (HT) or SPACE
          characters.  It follows that an octet with decimal
          value 9 or 32 appearing at the end of an encoded line
          must be represented according to Rule #1.  This rule is
          necessary because some MTAs (Message Transport Agents,
          programs which transport messages from one user to
          another, or perform a portion of such transfers) are
          known to pad lines of text with SPACEs, and others are
          known to remove "white space" characters from the end
          of a line.  Therefore, when decoding a Quoted-Printable
          body, any trailing white space on a line must be
          deleted, as it will necessarily have been added by
          intermediate transport agents.

    (4)   (Line Breaks) A line break in a text body, represented
          as a CRLF sequence in the text canonical form, must be
          represented by a (<A =
href=3D"http://www.faqs.org/rfcs/rfc822.html">RFC 822</A>) line break, =
which is also a
          CRLF sequence, in the Quoted-Printable encoding.  Since
          the canonical representation of media types other than
          text do not generally include the representation of
          line breaks as CRLF sequences, no hard line breaks
          (i.e. line breaks that are intended to be meaningful
          and to be displayed to the user) can occur in the
          quoted-printable encoding of such types.  Sequences
          like "=3D0D", "=3D0A", "=3D0A=3D0D" and "=3D0D=3D0A" will =
routinely
          appear in non-text data represented in quoted-
          printable, of course.

          Note that many implementations may elect to encode the
          local representation of various content types directly
          rather than converting to canonical form first,
          encoding, and then converting back to local
          representation.  In particular, this may apply to plain
          text material on systems that use newline conventions
          other than a CRLF terminator sequence.  Such an
          implementation optimization is permissible, but only
          when the combined canonicalization-encoding step is
          equivalent to performing the three steps separately.

    (5)   (Soft Line Breaks) The Quoted-Printable encoding
          REQUIRES that encoded lines be no more than 76
          characters long.  If longer lines are to be encoded
          with the Quoted-Printable encoding, "soft" line breaks

          must be used.  An equal sign as the last character on a
          encoded line indicates such a non-significant ("soft")
          line break in the encoded text.

   Thus if the "raw" form of the line is a single unencoded line that
   says:

     Now's the time for all folk to come to the aid of their country.

   This can be represented, in the Quoted-Printable encoding, as:

     Now's the time =3D
     for all folk to come=3D
      to the aid of their country.

   This provides a mechanism with which long lines are encoded in such a
   way as to be restored by the user agent.  The 76 character limit does
   not count the trailing CRLF, but counts all other characters,
   including any equal signs.

   Since the hyphen character ("-") may be represented as itself in the
   Quoted-Printable encoding, care must be taken, when encapsulating a
   quoted-printable encoded body inside one or more multipart entities,
   to ensure that the boundary delimiter does not appear anywhere in the
   encoded body.  (A good strategy is to choose a boundary that includes
   a character sequence such as "=3D_" which can never appear in a
   quoted-printable body.  See the definition of multipart messages in
   <A href=3D"http://www.faqs.org/rfcs/rfc2046.html">RFC 2046</A>.)

   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.  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 US-ASCII characters

     !"#$@[\]^`{|}~

   according to rule #1.

   Because quoted-printable data is generally assumed to be line-
   oriented, it is to be expected that the representation of 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.

   NOTE: Several kinds of substrings cannot be generated according to
   the encoding rules for the quoted-printable content-transfer-
   encoding, and hence are formally illegal if they appear in the output
   of a quoted-printable encoder. This note enumerates these cases and
   suggests ways to handle such illegal substrings if any are
   encountered in quoted-printable data that is to be decoded.

    (1)   An "=3D" followed by two hexadecimal digits, one or both
          of which are lowercase letters in "abcdef", is formally
          illegal. A robust implementation might choose to
          recognize them as the corresponding uppercase letters.

    (2)   An "=3D" followed by a character that is neither a
          hexadecimal digit (including "abcdef") nor the CR
          character of a CRLF pair is illegal.  This case can be
          the result of US-ASCII text having been included in a
          quoted-printable part of a message without itself
          having been subjected to quoted-printable encoding.  A
          reasonable approach by a robust implementation might be
          to include the "=3D" character and the following
          character in the decoded data without any
          transformation and, if possible, indicate to the user
          that proper decoding was not possible at this point in
          the data.

    (3)   An "=3D" cannot be the ultimate or penultimate character
          in an encoded object.  This could be handled as in case
          (2) above.

    (4)   Control characters other than TAB, or CR and LF as
          parts of CRLF pairs, must not appear. The same is true
          for octets with decimal values greater than 126.  If
          found in incoming quoted-printable data by a decoder, a
          robust implementation might exclude them from the
          decoded data and warn the user that illegal characters
          were discovered.

    (5)   Encoded lines must not be longer than 76 characters,
          not counting the trailing CRLF. If longer lines are
          found in incoming, encoded data, a robust
          implementation might nevertheless decode the lines, and
          might report the erroneous encoding to the user.

   WARNING TO IMPLEMENTORS:  If binary data is encoded in quoted-
   printable, care must be taken to encode CR and LF characters as =
"=3D0D"
   and "=3D0A", respectively.  In particular, a CRLF sequence in binary
   data should be encoded as "=3D0D=3D0A".  Otherwise, if CRLF were
   represented as a hard line break, it might be incorrectly decoded on
   platforms with different line break conventions.

   For formalists, the syntax of quoted-printable data is described by
   the following grammar:

     quoted-printable :=3D qp-line *(CRLF qp-line)

     qp-line :=3D *(qp-segment transport-padding CRLF)
                qp-part transport-padding

     qp-part :=3D qp-section
                ; Maximum length of 76 characters

     qp-segment :=3D qp-section *(SPACE / TAB) "=3D"
                   ; Maximum length of 76 characters

     qp-section :=3D [*(ptext / SPACE / TAB) ptext]

     ptext :=3D hex-octet / safe-char

     safe-char :=3D &lt;any octet with decimal value of 33 through
                  60 inclusive, and 62 through 126&gt;
                  ; Characters not listed as "mail-safe" in
                  ; <A =
href=3D"http://www.faqs.org/rfcs/rfc2049.html">RFC 2049</A> are also not =
recommended.

     hex-octet :=3D "=3D" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
                  ; Octet must be used for characters &gt; 127, =3D,
                  ; SPACEs or TABs at the ends of lines, and is
                  ; recommended for any character not listed in
                  ; <A =
href=3D"http://www.faqs.org/rfcs/rfc2049.html">RFC 2049</A> as =
"mail-safe".

     transport-padding :=3D *LWSP-char
                          ; Composers MUST NOT generate
                          ; non-zero length transport
                          ; padding, but receivers MUST
                          ; be able to handle padding
                          ; added by message transports.

   IMPORTANT:  The addition of LWSP between the elements shown in this
   BNF is NOT allowed since this BNF does not specify a structured
   header field.

6.8.  Base64 Content-Transfer-Encoding

   The Base64 Content-Transfer-Encoding is designed to represent
   arbitrary sequences of octets in a form that need not be humanly
   readable.  The encoding and decoding algorithms are simple, but the
   encoded data are consistently only about 33 percent larger than the
   unencoded data.  This encoding is virtually identical to the one used
   in Privacy Enhanced Mail (PEM) applications, as defined in <A =
href=3D"http://www.faqs.org/rfcs/rfc1421.html">RFC 1421</A>.

   A 65-character subset of US-ASCII is used, enabling 6 bits to be
   represented per printable character. (The extra 65th character, =
"=3D",
   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, Macintosh binhex 4.0 [<A =
href=3D"http://www.faqs.org/rfcs/rfc1741.html">RFC-1741</A>], 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 8bit 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 8bit byte, and the eighth bit will be the low-order bit in
   the first 8bit 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 multipart boundary delimiters defined in <A =
href=3D"http://www.faqs.org/rfcs/rfc2046.html">RFC 2046</A> (e.g.,
   "-").

                    Table 1: The Base64 Alphabet

     Value Encoding  Value Encoding  Value Encoding  Value Encoding
         0 A            17 R            34 i            51 z
         1 B            18 S            35 j            52 0
         2 C            19 T            36 k            53 1
         3 D            20 U            37 l            54 2
         4 E            21 V            38 m            55 3
         5 F            22 W            39 n            56 4
         6 G            23 X            40 o            57 5
         7 H            24 Y            41 p            58 6
         8 I            25 Z            42 q            59 7
         9 J            26 a            43 r            60 8
        10 K            27 b            44 s            61 9
        11 L            28 c            45 t            62 +
        12 M            29 d            46 u            63 /
        13 N            30 e            47 v
        14 O            31 f