rfc2045-multipurposeinternetmailextensions(mime).mht

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

          transformation are usually applied to data in order to
          allow it to pass through mail transport mechanisms
          which may have data or character set limitations.

    (4)   Two additional header fields that can be used to
          further describe the data in a body, the Content-ID and
          Content-Description header fields.

   All of the header fields defined in this document are subject to the
   general syntactic rules for header fields specified in <A =
href=3D"http://www.faqs.org/rfcs/rfc822.html">RFC 822</A>.  In
   particular, all of these header fields except for Content-Disposition
   can include <A href=3D"http://www.faqs.org/rfcs/rfc822.html">RFC =
822</A> comments, which have no semantic content and
   should be ignored during MIME processing.

   Finally, to specify and promote interoperability, <A =
href=3D"http://www.faqs.org/rfcs/rfc2049.html">RFC 2049</A> provides a
   basic applicability statement for a subset of the above mechanisms
   that defines a minimal level of "conformance" with this document.

   HISTORICAL NOTE:  Several of the mechanisms described in this set of
   documents may seem somewhat strange or even baroque at first reading.
   It is important to note that compatibility with existing standards
   AND robustness across existing practice were two of the highest
   priorities of the working group that developed this set of documents.
   In particular, compatibility was always favored over elegance.

   Please refer to the current edition of the "Internet Official
   Protocol Standards" for the standardization state and status of this
   protocol.  <A href=3D"http://www.faqs.org/rfcs/rfc822.html">RFC =
822</A> and STD 3, <A href=3D"http://www.faqs.org/rfcs/rfc1123.html">RFC =
1123</A> also provide essential
   background for MIME since no conforming implementation of MIME can
   violate them.  In addition, several other informational RFC documents
   will be of interest to the MIME implementor, in particular <A =
href=3D"http://www.faqs.org/rfcs/rfc1344.html">RFC 1344</A>,
   <A href=3D"http://www.faqs.org/rfcs/rfc1345.html">RFC 1345</A>, and =
<A href=3D"http://www.faqs.org/rfcs/rfc1524.html">RFC 1524</A>.

2.  Definitions, Conventions, and Generic BNF Grammar

   Although the mechanisms specified in this set of documents are all
   described in prose, most are also described formally in the augmented
   BNF notation of <A href=3D"http://www.faqs.org/rfcs/rfc822.html">RFC =
822</A>. Implementors will need to be familiar with
   this notation in order to understand this set of documents, and are
   referred to <A href=3D"http://www.faqs.org/rfcs/rfc822.html">RFC =
822</A> for a complete explanation of the augmented BNF
   notation.

   Some of the augmented BNF in this set of documents makes named
   references to syntax rules defined in <A =
href=3D"http://www.faqs.org/rfcs/rfc822.html">RFC 822</A>.  A complete =
formal
   grammar, then, is obtained by combining the collected grammar
   appendices in each document in this set with the BNF of <A =
href=3D"http://www.faqs.org/rfcs/rfc822.html">RFC 822</A> plus
   the modifications to <A =
href=3D"http://www.faqs.org/rfcs/rfc822.html">RFC 822</A> defined in <A =
href=3D"http://www.faqs.org/rfcs/rfc1123.html">RFC 1123</A> (which =
specifically
   changes the syntax for `return', `date' and `mailbox').

   All numeric and octet values are given in decimal notation in this
   set of documents. All media type values, subtype values, and
   parameter names as defined are case-insensitive.  However, parameter
   values are case-sensitive unless otherwise specified for the specific
   parameter.

   FORMATTING NOTE:  Notes, such at this one, provide additional
   nonessential information which may be skipped by the reader without
   missing anything essential.  The primary purpose of these non-
   essential notes is to convey information about the rationale of this
   set of documents, or to place these documents in the proper
   historical or evolutionary context.  Such information may in
   particular be skipped by those who are focused entirely on building a
   conformant implementation, but may be of use to those who wish to
   understand why certain design choices were made.

2.1.  CRLF

   The term CRLF, in this set of documents, refers to the sequence of
   octets corresponding to the two US-ASCII characters CR (decimal value
   13) and LF (decimal value 10) which, taken together, in this order,
   denote a line break in <A =
href=3D"http://www.faqs.org/rfcs/rfc822.html">RFC 822</A> mail.

2.2.  Character Set

   The term "character set" is used in MIME to refer to a method of
   converting a sequence of octets into a sequence of characters.  Note
   that unconditional and unambiguous conversion in the other direction
   is not required, in that not all characters may be representable by a
   given character set and a character set may provide more than one
   sequence of octets to represent a particular sequence of characters.

   This definition is intended to allow various kinds of character
   encodings, from simple single-table mappings such as US-ASCII to
   complex table switching methods such as those that use ISO 2022's
   techniques, to be used as character sets.  However, the definition
   associated with a MIME character set name must fully specify the
   mapping to be performed.  In particular, use of external profiling
   information to determine the exact mapping is not permitted.

   NOTE: The term "character set" was originally to describe such
   straightforward schemes as US-ASCII and ISO-8859-1 which have a
   simple one-to-one mapping from single octets to single characters.
   Multi-octet coded character sets and switching techniques make the
   situation more complex. For example, some communities use the term
   "character encoding" for what MIME calls a "character set", while
   using the phrase "coded character set" to denote an abstract mapping
   from integers (not octets) to characters.

2.3.  Message

   The term "message", when not further qualified, means either a
   (complete or "top-level") <A =
href=3D"http://www.faqs.org/rfcs/rfc822.html">RFC 822</A> message being =
transferred on a
   network, or a message encapsulated in a body of type "message/rfc822"
   or "message/partial".

2.4.  Entity

   The term "entity", refers specifically to the MIME-defined header
   fields and contents of either a message or one of the parts in the
   body of a multipart entity.  The specification of such entities is
   the essence of MIME.  Since the contents of an entity are often
   called the "body", it makes sense to speak about the body of an
   entity.  Any sort of field may be present in the header of an entity,
   but only those fields whose names begin with "content-" actually have
   any MIME-related meaning.  Note that this does NOT imply thay they
   have no meaning at all -- an entity that is also a message has non-
   MIME header fields whose meanings are defined by <A =
href=3D"http://www.faqs.org/rfcs/rfc822.html">RFC 822</A>.

2.5.  Body Part

   The term "body part" refers to an entity inside of a multipart
   entity.

2.6.  Body

   The term "body", when not further qualified, means the body of an
   entity, that is, the body of either a message or of a body part.

   NOTE:  The previous four definitions are clearly circular.  This is
   unavoidable, since the overall structure of a MIME message is indeed
   recursive.

2.7.  7bit Data

   "7bit data" refers to data that is all represented as relatively
   short lines with 998 octets or less between CRLF line separation
   sequences [<A =
href=3D"http://www.faqs.org/rfcs/rfc821.html">RFC-821</A>].  No octets =
with decimal values greater than 127
   are allowed and neither are NULs (octets with decimal value 0).  CR
   (decimal value 13) and LF (decimal value 10) octets only occur as
   part of CRLF line separation sequences.

2.8.  8bit Data

   "8bit data" refers to data that is all represented as relatively
   short lines with 998 octets or less between CRLF line separation
   sequences [<A =
href=3D"http://www.faqs.org/rfcs/rfc821.html">RFC-821</A>]), but octets =
with decimal values greater than 127
   may be used.  As with "7bit data" CR and LF octets only occur as part
   of CRLF line separation sequences and no NULs are allowed.

2.9.  Binary Data

   "Binary data" refers to data where any sequence of octets whatsoever
   is allowed.

2.10.  Lines

   "Lines" are defined as sequences of octets separated by a CRLF
   sequences.  This is consistent with both <A =
href=3D"http://www.faqs.org/rfcs/rfc821.html">RFC 821</A> and <A =
href=3D"http://www.faqs.org/rfcs/rfc822.html">RFC 822</A>.
   "Lines" only refers to a unit of data in a message, which may or may
   not correspond to something that is actually displayed by a user
   agent.

3.  MIME Header Fields

   MIME defines a number of new <A =
href=3D"http://www.faqs.org/rfcs/rfc822.html">RFC 822</A> header fields =
that are used to
   describe the content of a MIME entity.  These header fields occur in
   at least two contexts:

    (1)   As part of a regular <A =
href=3D"http://www.faqs.org/rfcs/rfc822.html">RFC 822</A> message =
header.

    (2)   In a MIME body part header within a multipart
          construct.

   The formal definition of these header fields is as follows:

     entity-headers :=3D [ content CRLF ]
                       [ encoding CRLF ]
                       [ id CRLF ]
                       [ description CRLF ]
                       *( MIME-extension-field CRLF )

     MIME-message-headers :=3D entity-headers
                             fields
                             version CRLF
                             ; The ordering of the header
                             ; fields implied by this BNF
                             ; definition should be ignored.

     MIME-part-headers :=3D entity-headers
                          [ fields ]
                          ; Any field not beginning with
                          ; "content-" can have no defined
                          ; meaning and may be ignored.
                          ; The ordering of the header
                          ; fields implied by this BNF
                          ; definition should be ignored.

   The syntax of the various specific MIME header fields will be
   described in the following sections.

4.  MIME-Version Header Field

   Since <A href=3D"http://www.faqs.org/rfcs/rfc822.html">RFC 822</A> =
was published in 1982, there has really been only one
   format standard for Internet messages, and there has been little
   perceived need to declare the format standard in use.  This document
   is an independent specification that complements <A =
href=3D"http://www.faqs.org/rfcs/rfc822.html">RFC 822</A>.  Although
   the extensions in this document have been defined in such a way as to
   be compatible with <A =
href=3D"http://www.faqs.org/rfcs/rfc822.html">RFC 822</A>, there are =
still circumstances in which it
   might be desirable for a mail-processing agent to know whether a
   message was composed with the new standard in mind.

   Therefore, this document defines a new header field, "MIME-Version",
   which is to be used to declare the version of the Internet message
   body format standard in use.

   Messages composed in accordance with this document MUST include such
   a header field, with the following verbatim text:

     MIME-Version: 1.0

   The presence of this header field is an assertion that the message
   has been composed in compliance with this document.

   Since it is possible that a future document might extend the message
   format standard again, a formal BNF is given for the content of the
   MIME-Version field:

     version :=3D "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

   Thus, future format specifiers, which might replace or extend "1.0",