rfc1341.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

            gateway could decode a quoted-printable body  and  re-encode
            it  using  base64,  but  such gateways do not yet exist.)  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 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 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.











            Borenstein & Freed                                 [Page 16]




            RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992


            5.2  Base64 Content-Transfer-Encoding

            The  Base64   Content-Transfer-Encoding   is   designed   to
            represent  arbitrary  sequences  of octets in a form that is
            not 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
            based on the one used in Privacy Enhanced Mail applications,
            as defined in RFC 1113.   The  base64  encoding  is  adapted
            from  RFC  1113, 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.  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., "-").










            Borenstein & Freed                                 [Page 17]




            RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992


                            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.  Output character positions
            which are not required to represent actual  input  data  are
            set  to  the  character  "=".   Since all base64 input is an
            integral number of octets,  only  the  following  cases  can
            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.

            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  should  be converted into CRLF sequences



            Borenstein & Freed                                 [Page 18]




            RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992


            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 Optional 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:

            Content-ID := msg-id

            Like  the  Message-ID  values,  Content-ID  values  must  be
            generated to be as unique as possible.

            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.

            Content-Description := *text

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



















            Borenstein & Freed                                 [Page 19]




            RFC 1341MIME: Multipurpose Internet Mail ExtensionsJune 1992


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

            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.  The primary subtype of text
            is "plain".  This 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  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