rfc2045-multipurposeinternetmailextensions(mime).mht

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

   are constrained to be two integer fields, separated by a period.  If
   a message is received with a MIME-version value other than "1.0", it
   cannot be assumed to conform with this document.

   Note that the MIME-Version header field is required at the top level
   of a message.  It is not required for each body part of a multipart
   entity.  It is required for the embedded headers of a body of type
   "message/rfc822" or "message/partial" if and only if the embedded
   message is itself claimed to be MIME-conformant.

   It is not possible to fully specify how a mail reader that conforms
   with MIME as defined in this document should treat a message that
   might arrive in the future with some value of MIME-Version other than
   "1.0".

   It is also worth noting that version control for specific media types
   is not accomplished using the MIME-Version mechanism.  In particular,
   some formats (such as application/postscript) have version numbering
   conventions that are internal to the media format.  Where such
   conventions exist, MIME does nothing to supersede them.  Where no
   such conventions exist, a MIME media type might use a "version"
   parameter in the content-type field if necessary.

   NOTE TO IMPLEMENTORS:  When checking MIME-Version values any <A =
href=3D"http://www.faqs.org/rfcs/rfc822.html">RFC 822</A>
   comment strings that are present must be ignored.  In particular, the
   following four MIME-Version fields are equivalent:

     MIME-Version: 1.0

     MIME-Version: 1.0 (produced by MetaSend Vx.x)

     MIME-Version: (produced by MetaSend Vx.x) 1.0

     MIME-Version: 1.(produced by MetaSend Vx.x)0

   In the absence of a MIME-Version field, a receiving mail user agent
   (whether conforming to MIME requirements or not) may optionally
   choose to interpret the body of the message according to local
   conventions.  Many such conventions are currently in use and it
   should be noted that in practice non-MIME messages can contain just
   about anything.

   It is impossible to be certain that a non-MIME mail message is
   actually plain text in the US-ASCII character set since it might well
   be a message that, using some set of nonstandard local conventions
   that predate MIME, includes text in another character set or non-
   textual data presented in a manner that cannot be automatically
   recognized (e.g., a uuencoded compressed UNIX tar file).

5.  Content-Type Header Field

   The purpose of the Content-Type field is to describe the data
   contained in the body fully enough that the receiving user agent can
   pick an appropriate agent or mechanism to present the data to the
   user, or otherwise deal with the data in an appropriate manner. The
   value in this field is called a media type.

   HISTORICAL NOTE:  The Content-Type header field was first defined in
   <A href=3D"http://www.faqs.org/rfcs/rfc1049.html">RFC 1049</A>.  <A =
href=3D"http://www.faqs.org/rfcs/rfc1049.html">RFC 1049</A> used a =
simpler and less powerful syntax, but one
   that is largely compatible with the mechanism given here.

   The Content-Type header field specifies the nature of the data in the
   body of an entity by giving media type and subtype identifiers, and
   by providing auxiliary information that may be required for certain
   media types.  After the media type and subtype names, the remainder
   of the header field is simply a set of parameters, specified in an
   attribute=3Dvalue notation.  The ordering of parameters is not
   significant.

   In general, the top-level media type is used to declare the general
   type of data, while the subtype specifies a specific format for that
   type of data.  Thus, a media type of "image/xyz" is enough to tell a
   user agent that the data is an image, even if the user agent has no
   knowledge of the specific image format "xyz".  Such information can
   be used, for example, to decide whether or not to show a user the raw
   data from an unrecognized subtype -- such an action might be
   reasonable for unrecognized subtypes of text, but not for
   unrecognized subtypes of image or audio.  For this reason, registered
   subtypes of text, image, audio, and video should not contain embedded
   information that is really of a different type.  Such compound
   formats should be represented using the "multipart" or "application"
   types.

   Parameters are modifiers of the media subtype, and as such do not
   fundamentally affect the nature of the content.  The set of
   meaningful parameters depends on the media type and subtype.  Most
   parameters are associated with a single specific subtype.  However, a
   given top-level media type may define parameters which are applicable
   to any subtype of that type.  Parameters may be required by their
   defining content type or subtype or they may be optional. MIME
   implementations must ignore any parameters whose names they do not
   recognize.

   For example, the "charset" parameter is applicable to any subtype of
   "text", while the "boundary" parameter is required for any subtype of
   the "multipart" media type.

   There are NO globally-meaningful parameters that apply to all media
   types.  Truly global mechanisms are best addressed, in the MIME
   model, by the definition of additional Content-* header fields.

   An initial set of seven top-level media types is defined in <A =
href=3D"http://www.faqs.org/rfcs/rfc2046.html">RFC 2046</A>.
   Five of these are discrete types whose content is essentially opaque
   as far as MIME processing is concerned.  The remaining two are
   composite types whose contents require additional handling by MIME
   processors.

   This set of top-level media types is intended to be substantially
   complete.  It is expected that additions to the larger set of
   supported types can generally be accomplished by the creation of new
   subtypes of these initial types.  In the future, more top-level types
   may be defined only by a standards-track extension to this standard.
   If another top-level type is to be used for any reason, it must be
   given a name starting with "X-" to indicate its non-standard status
   and to avoid a potential conflict with a future official name.

5.1.  Syntax of the Content-Type Header Field

   In the Augmented BNF notation of <A =
href=3D"http://www.faqs.org/rfcs/rfc822.html">RFC 822</A>, a =
Content-Type header field
   value is defined as follows:

     content :=3D "Content-Type" ":" type "/" subtype
                *(";" parameter)
                ; Matching of media type and subtype
                ; is ALWAYS case-insensitive.

     type :=3D discrete-type / composite-type

     discrete-type :=3D "text" / "image" / "audio" / "video" /
                      "application" / extension-token

     composite-type :=3D "message" / "multipart" / extension-token

     extension-token :=3D ietf-token / x-token

     ietf-token :=3D &lt;An extension token defined by a
                    standards-track RFC and registered
                    with IANA.&gt;

     x-token :=3D &lt;The two characters "X-" or "x-" followed, with
                 no intervening white space, by any token&gt;

     subtype :=3D extension-token / iana-token

     iana-token :=3D &lt;A publicly-defined extension token. Tokens
                    of this form must be registered with IANA
                    as specified in <A =
href=3D"http://www.faqs.org/rfcs/rfc2048.html">RFC 2048</A>.&gt;

     parameter :=3D attribute "=3D" value

     attribute :=3D token
                  ; Matching of attributes
                  ; is ALWAYS case-insensitive.

     value :=3D token / quoted-string

     token :=3D 1*&lt;any (US-ASCII) CHAR except SPACE, CTLs,
                 or tspecials&gt;

     tspecials :=3D  "(" / ")" / "&lt;" / "&gt;" / "@" /
                   "," / ";" / ":" / "\" / &lt;"&gt;
                   "/" / "[" / "]" / "?" / "=3D"
                   ; Must be in quoted-string,
                   ; to use within parameter values

   Note that the definition of "tspecials" is the same as the <A =
href=3D"http://www.faqs.org/rfcs/rfc822.html">RFC 822</A>
   definition of "specials" with the addition of the three characters
   "/", "?", and "=3D", and the removal of ".".

   Note also that a subtype specification is MANDATORY -- it may not be
   omitted from a Content-Type header field.  As such, there are no
   default subtypes.

   The type, subtype, and parameter names are not case sensitive.  For
   example, TEXT, Text, and TeXt are all equivalent top-level media
   types.  Parameter values are normally case sensitive, but sometimes
   are interpreted in a case-insensitive fashion, depending on the
   intended use.  (For example, multipart boundaries are case-sensitive,
   but the "access-type" parameter for message/External-body is not
   case-sensitive.)

   Note that the value of a quoted string parameter does not include the
   quotes.  That is, the quotation marks in a quoted-string are not a
   part of the value of the parameter, but are merely used to delimit
   that parameter value.  In addition, comments are allowed in
   accordance with <A href=3D"http://www.faqs.org/rfcs/rfc822.html">RFC =
822</A> rules for structured header fields.  Thus the
   following two forms

     Content-type: text/plain; charset=3Dus-ascii (Plain text)

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

   are completely equivalent.

   Beyond this syntax, the only syntactic constraint on the definition
   of subtype names is the desire that their uses must not conflict.
   That is, it would be undesirable to have two different communities
   using "Content-Type: application/foobar" to mean two different
   things.  The process of defining new media subtypes, then, is not
   intended to be a mechanism for imposing restrictions, but simply a
   mechanism for publicizing their definition and usage.  There are,
   therefore, two acceptable mechanisms for defining new media subtypes:

    (1)   Private values (starting with "X-") may be defined
          bilaterally between two cooperating agents without
          outside registration or standardization. Such values
          cannot be registered or standardized.

    (2)   New standard values should be registered with IANA as
          described in <A =
href=3D"http://www.faqs.org/rfcs/rfc2048.html">RFC 2048</A>.

   The second document in this set, <A =
href=3D"http://www.faqs.org/rfcs/rfc2046.html">RFC 2046</A>, defines the =
initial set of
   media types for MIME.

5.2.  Content-Type Defaults

   Default <A href=3D"http://www.faqs.org/rfcs/rfc822.html">RFC 822</A> =
messages without a MIME Content-Type header are taken
   by this protocol to be plain text in the US-ASCII character set,
   which can be explicitly specified as:

     Content-type: text/plain; charset=3Dus-ascii

   This default is assumed if no Content-Type header field is specified.
   It is also recommend that this default be assumed when a
   syntactically invalid Content-Type header field is encountered. In
   the presence of a MIME-Version header field and the absence of any
   Content-Type header field, a receiving User Agent can also assume
   that plain US-ASCII text was the sender's intent.  Plain US-ASCII
   text may still be assumed in the absence of a MIME-Version or the
   presence of an syntactically invalid Content-Type header field, but
   the sender's intent might have been otherwise.

6.  Content-Transfer-Encoding Header Field

   Many media types which could be usefully transported via email are
   represented, in their "natural" format, as 8bit character or binary
   data.  Such data cannot be transmitted over some transfer protocols.
   For example, <A href=3D"http://www.faqs.org/rfcs/rfc821.html">RFC =
821</A> (SMTP) restricts mail messages to 7bit US-ASCII
   data with lines no longer than 1000 characters including any trailing
   CRLF line separator.

   It is necessary, therefore, to define a standard mechanism for
   encoding such data into a 7bit short line format.  Proper labelling
   of unencoded material in less restrictive formats for direct use over
   less restrictive transports is also desireable.  This document
   specifies that such encodings will be indicated by a new "Content-
   Transfer-Encoding" header field.  This field has not been defined by
   any previous standard.