rfc1521.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,370 行 · 第 1/5 页

      Content-Transfer-Encoding.  A way to get reasonably reliable
      transport through EBCDIC gateways is to also quote the ASCII
      characters

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

      according to rule #1.  See Appendix B for more information.

   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.

   WARNING TO IMPLEMENTORS: If binary data are encoded in quoted-
   printable, care must be taken to encode CR and LF characters as "=0D"
   and "=0A", respectively.  In particular, a CRLF sequence in binary
   data should be encoded as "=0D=0A".  Otherwise, if CRLF were
   represented as a hard line break, it might be incorrectly decoded on



Borenstein & Freed                                             [Page 20]

RFC 1521                          MIME                    September 1993


   platforms with different line break conventions.

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

   quoted-printable := ([*(ptext / SPACE / TAB) ptext] ["="] CRLF)
        ; Maximum line length of 76 characters excluding CRLF

   ptext := octet /<any ASCII character except "=", SPACE, or TAB>
        ; characters not listed as "mail-safe" in Appendix B
        ; are also not recommended.

   octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
        ; octet must be used for characters > 127, =, SPACE, or TAB,
        ; and is recommended for any characters not listed in
        ; Appendix B as "mail-safe".

5.2.  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 RFC 1421.
   The base64 encoding is adapted from RFC 1421, with one change: base64
   eliminates the "*" mechanism for embedded clear text.

   A 65-character subset of US-ASCII is used, enabling 6 bits to be
   represented per printable character. (The extra 65th character, "=",
   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 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 8-bit 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.



Borenstein & Freed                                             [Page 21]

RFC 1521                          MIME                    September 1993


   That is, the first bit in the stream will be the high-order bit in
   the first byte, and the eighth bit will be the low-order bit in the
   first 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 encapsulation boundaries defined in this document (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            48 w         (pad) =
          15 P            32 g            49 x
          16 Q            33 h            50 y

   The output stream (encoded bytes) must be represented in lines of no
   more than 76 characters each.  All line breaks or other characters
   not found in Table 1 must be ignored by decoding software.  In base64
   data, characters other than those in Table 1, line breaks, and other
   white space probably indicate a transmission error, about which a
   warning message or even a message rejection might be appropriate
   under some circumstances.

   Special processing is performed if fewer than 24 bits are available
   at the end of the data being encoded.  A full encoding quantum is
   always completed at the end of a body.  When fewer than 24 input bits
   are available in an input group, zero bits are added (on the right)
   to form an integral number of 6-bit groups.  Padding at the end of
   the data is performed using the '=' character.  Since all base64
   input is an integral number of octets, only the following cases can



Borenstein & Freed                                             [Page 22]

RFC 1521                          MIME                    September 1993


   arise: (1) the final quantum of encoding input is an integral
   multiple of 24 bits; here, the final unit of encoded output will be
   an integral multiple of 4 characters with no "=" padding, (2) the
   final quantum of encoding input is exactly 8 bits; here, the final
   unit of encoded output will be two characters followed by two "="
   padding characters, or (3) the final quantum of encoding input is
   exactly 16 bits; here, the final unit of encoded output will be three
   characters followed by one "=" padding character.

   Because it is used only for padding at the end of the data, the
   occurrence of any '=' characters may be taken as evidence that the
   end of the data has been reached (without truncation in transit).  No
   such assurance is possible, however, when the number of octets
   transmitted was a multiple of three.

   Any characters outside of the base64 alphabet are to be ignored in
   base64-encoded data.  The same applies to any illegal sequence of
   characters in the base64 encoding, such as "====="

   Care must be taken to use the proper octets for line breaks if base64
   encoding is applied directly to text material that has not been
   converted to canonical form.  In particular, text line breaks must be
   converted into CRLF sequences prior to base64 encoding. The important
   thing to note is that this may be done directly by the encoder rather
   than in a prior canonicalization step in some implementations.

      NOTE: There is no need to worry about quoting apparent
      encapsulation boundaries within base64-encoded parts of multipart
      entities because no hyphen characters are used in the base64
      encoding.

6.    Additional Content-Header Fields

6.1.  Optional Content-ID Header Field

   In constructing a high-level user agent, it may be desirable to allow
   one body to make reference to another.  Accordingly, bodies may be
   labeled using the "Content-ID" header field, which is syntactically
   identical to the "Message-ID" header field:

   id :=  "Content-ID" ":" msg-id
   Like the Message-ID values, Content-ID values must be generated to be
   world-unique.

   The Content-ID value may be used for uniquely identifying MIME
   entities in several contexts, particularly for cacheing data
   referenced by the message/external-body mechanism.  Although the
   Content-ID header is generally optional, its use is mandatory in



Borenstein & Freed                                             [Page 23]

RFC 1521                          MIME                    September 1993


   implementations which generate data of the optional MIME Content-type
   "message/external-body".  That is, each message/external-body entity
   must have a Content-ID field to permit cacheing of such data.

   It is also worth noting that the Content-ID value has special
   semantics in the case of the multipart/alternative content-type.
   This is explained in the section of this document dealing with
   multipart/alternative.

6.2.  Optional Content-Description Header Field

   The ability to associate some descriptive information with a given
   body is often desirable. For example, it may be useful to mark an
   "image" body as "a picture of the Space Shuttle Endeavor."  Such text
   may be placed in the Content-Description header field.

   description := "Content-Description" ":" *text

   The description is presumed to be given in the US-ASCII character
   set, although the mechanism specified in [RFC-1522] may be used for
   non-US-ASCII Content-Description values.

7.    The Predefined Content-Type Values

   This document defines seven initial Content-Type values and an
   extension mechanism for private or experimental types.  Further
   standard types must be defined by new published specifications.  It
   is expected that most innovation in new types of mail will take place
   as subtypes of the seven types defined here.  The most essential
   characteristics of the seven content-types are summarized in Appendix
   F.

7.1  The Text Content-Type

   The text Content-Type is intended for sending material which is
   principally textual in form.  It is the default Content-Type.  A
   "charset" parameter may be used to indicate the character set of the
   body text for some text subtypes, notably including the primary
   subtype, "text/plain", which indicates plain (unformatted) text.  The
   default Content-Type for Internet mail is "text/plain; charset=us-
   ascii".

   Beyond plain text, there are many formats for representing what might
   be known as "extended text" -- text with embedded formatting and
   presentation information.  An interesting characteristic of many such
   representations is that they are to some extent readable even without
   the software that interprets them.  It is useful, then, to
   distinguish them, at the highest level, from such unreadable data as



Borenstein & Freed                                             [Page 24]

RFC 1521                          MIME                    September 1993


   images, audio, or text represented in an unreadable form.  In the
   absence of appropriate interpretation software, it is reasonable to
   show subtypes of text to the user, while it is not reasonable to do
   so with most nontextual data.

   Such formatted textual data should be represented using subtypes of
   text.  Plausible subtypes of text are typically given by the common
   name of the representation format, e.g., "text/richtext" [RFC-1341].

7.1.1.     The charset parameter

   A critical parameter that may be specified in the Content-Type field
   for text/plain data is the character set.  This is specified with a
   "charset" parameter, as in:

        Content-type: text/plain; charset=us-ascii

   Unlike some other parameter values, the values of the charset
   parameter are NOT case sensitive.  The default character set, which
   must