mime.txt

MIMEPQ编解码

                            MIME Overview

                by Mark Grand <[e-mail]>

Internet e-mail allows mail messages to be exchanged between users of
computers around the world and occasionally beyond... to space
shuttles.  One of the main reasons that Internet e-mail has achieved
such wide use is because it provides a standard mechanism for messages
to be exchanged between over 1,000,000 computers connected to the
Internet.

The standards that are the basis for Internet e-mail were established
in 1982.  Though they were state of the art in 1982, in the
intervening years they have begun to show their age.  The 1982
standards allow for mail messages that contain a single human readable
message with the restrictions that:

    * the message contains only ASCII characters.

    * the message contains no lines longer than 1000 characters.

    * the message does not exceed a certain length

The 1982 standards do not allow EDI to be transmitted through Internet
mail, since EDI messages can violate all of these restrictions.  There
are a number of other types of messages and services that have are
supported by other mail standards that have been designed more
recently.  In June of 1992 a new Internet mail standard was approved.
This new standard is called MIME.

MIME is an acronym for Multipurpose Internet Mail Extensions.  It
builds on the older standard by standardizing additional fields for
mail message headers that describe new types of content and
organization for messages.

MIME allows mail messages to contain:

    * Multiple objects in a single message.

    * Text having unlimited line length or overall length.

    * Character sets other than ASCII.

    * Multi-font messages.

    * Binary or application specific files.

    * Images, Audio, Video and multi-media messages.

MIME defines the following new header fields:

1.  A MIME-Version header field, which uses a version number to
    declare that a message conforms to the MIME standard.

2.  A Content-Type header field, which can be used to specify the type
    and subtype of data in the body of a message and to fully specify
    the encoding of such data.

    2.a.  A Text Content-Type value, which can be used to represent
          textual information in a number of character sets and
          formatted text description languages in a standardized
          manner.

    2.b.  A Multipart Content-Type value, which can be used to combine
          several body parts, possibly of differing types of data,
          into a single message.

    2.c.  An Application Content-Type value, which can be used to
          transmit application data or binary data.

    2.d.  A Message Content-Type value, for encapsulating a mail
          message.

    2.e.  An Image Content-Type value, for transmitting still image
          (picture) data.

    2.f.  An Audio Content-Type value, for transmitting audio or voice
          data.

    2.g.  A Video Content-Type value, for transmitting video or moving
          image data, possibly with audio as part of the composite
          video data format.

3.  A Content-Transfer-Encoding header field, that specifies how the
    data is encoded to allow it to pass through mail transports having
    data or character set limitations.

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

MIME is an extensible mechanism.  It is expected that the set of
content-type/subtype pairs and their associated parameters will grow
with time.  Several other MIME fields, such as character set names,
are likely to have new values defined over time.  To ensure that the
set of such values develops in an orderly, and public manner, MIME
defines a registration process which uses the Internet Assigned
Numbers Authority (IANA) as a central registry for such values.

To promote interoperability between implementations, the MIME standard
document specifies a minimal subset of the above mechanisms that are
required for an implementation to claim to conform to the MIME
standard.



                        MIME Technical Summary

MIME is defined by an Internet standard document called RFC 1341.
This document summarizes the contents of RFC 1341.  Sufficient detail
is presented here to understand the capabilities of MIME.  For
sufficient detail to implement MIME please read RFC 1341.

MIME allows messages to contain multiple objects.  When multiple
objects are in a MIME message, they are represented in a form called a
body part.  A body part has a header and a body, so it makes sense to
speak about the body of a body part. Also, body parts can be nested in
bodies that contain one or multiple body parts.

The Content-Type values, subtypes, and parameter names defined in the
MIME standard are not case insensitive.  However, many parameter
values are case sensitive.

The MIME standard is written to allow MIME to be extended in certain
ways, without having to revise the standard.  MIME specifies sets of
values that are allowed for various fields and parameters.  The
provides a procedure for extending these sets of values by registering
them with an entity called the Internet Assigned Numbers Authority
(IANA).


The MIME-Version Header Field

MIME is designed to be compatible with older Internet mail standards.
In particular, it is compatible with RFC 822.  If a mail reading
program receives a message that is a MIME message then it will likely
perform additional processing for the MIME message that it would not
perform for non-MIME messages.  In order to allow mail reading
programs to recognize MIME messages, MIME messages are required to
contain a MIME-Version header field.  The MIME-Version header field
specifies the version of the MIME standard that the message conforms
to.

As of this writing there is only version (1.0) of the MIME standard.
Messages that comply with the standard must include a header field,
with the following verbatim text:

        MIME-Version: 1.0

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" if
and only if the embedded message is claimed to be MIME-compliant.


The Content-Type Header Field

The Content-Type field describes the data contained in the body fully
enough that the mail reader can pick an appropriate mechanism to
present the data to the user, or otherwise deal with the data in an
appropriate manner.

The Content-Type header field is used to specify the nature of data in
the body or body part, by giving type and subtype identifiers, and by
providing parameters that may be needed for certain types.  After the
type and subtype names, the remainder of the header field is a set of
parameters, specified in an attribute/value notation.  The set of
meaningful parameters differs for different types.  The order of
parameters is not significant.  Comments are allowed (in accordance
with RFC 822 rules) in structured header fields by placing them in
parentheses.

The top-level Content-Type is used to declare the general type of
data, while the subtype specifies a specific format for that type of
data.  Thus, a Content-Type of Image/xyz is enough to tell a mail
reader that the data is an image, even if the mail reader has no
knowledge of the specific image format xyz.  Such information can be
used, 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 Audio, Image,
Text, and Video, should not contain embedded information that is
really of a different type.  Such compound types are usually
represented using the Multipart or Application types.

Parameters are modifiers of the content-subtype.  Although most
parameters make sense only with certain content-types, others are
"global" in the sense that they might apply to any subtype.  For
example, the Boundary parameter, which is used to indicate how body
parts are separated from each other, makes sense only for the
Multipart content-type.  The Charset parameter might make sense with
several content-types.

The MIME standard defines seven content-types.  The authors of the
MIME standard state that the set of seven types is "substantially
complete".  They expect additional supported types to be accommodated
by creating new subtypes of the seven initial top-level types.  The
MIME standard, functioning as a constitution for the MIME community,
states that new standard content types can be defined only by revising
the standard (as opposed to the registration procedure for other types
of extensions).  However, MIME does provide for the use of
non-standard content types.  Non-standard content-types can be used,
but must be given names starting with X-.  Future standard content
type names will not begin with X-.

The syntax for the content type header field is

    Content-Type := type "/" subtype [";" parameter]...

The defined content types are:

    Application
        indicates data that does not fit into any of the other
        categories, such as uninterpreted binary data or information
        to be processed by a mail-based application. In addition to
        the following subtypes, it is likely that additional subtypes
        will be defined for applications such as mail-based scheduling
        systems, spreadsheets and EDI.

    Application/Octet-Stream
        indicates uninterpreted binary data, which a mail reading
        program may simply offer to write the information into a file.
        Possible parameters for Application/Octet-Stream include:

        Name
            a suggested name for the binary data if stored as a file.

        Type
            the general type or category of binary data.  This is
            intended for human recipients rather than for automated
            processing.

        Conversions
            the operations that performed on the data before putting
            it the body.  Note that the standard defines no conversion
            values.  Any conversion values that do not begin with X-
            must be preceded by a published specification and by
            registration with IANA.

        Padding
            the number of bits of padding that were appended to the
            bitstream comprising the actual contents to produce the
            enclosed byte-oriented data.  This is useful for enclosing
            a bitstream in a body when the total number of bits is not
            a multiple of the byte size.

    Application/ODA
        indicates a body containing information encoded according to
        the Office Document Architecture (ODA) standards, using the
        ODIF representation format.  For Application/ODA, the
        Content-Type line should also specify an attribute/value pair
        that indicates the document application profile (DAP), using a
        Profile parameter.  Thus an appropriate header field might
        look like this:

            Content-Type: application/oda;
                          profile=Q112

        Consult the ODA standard for further information.

    Application/PostScript
        indicates a body containing a postscript document.

Audio
    Indicates audio data.  Audio requires an audio output device (such
    as a speaker or a telephone) to "display" the contents.

    Audio/Basic
        The content of the Audio/Basic subtype is audio encoded using
        8-bit ISDN u-law. When this subtype is present, a sample rate
        of 8000 Hz and a single channel is assumed.

    Image
        Image data.  Image requires a display device (such as a
        graphical display, a printer, or a FAX machine) to view the
        information.