mime.txt

MIMEPQ编解码

The standard allows the use of additional sub-types without having to
change the standard.  However, it is important to insure that
sub-types used by different user communities of MIME do not conflict.
It would be confusing if Content-Type: application/foobar meant two
different things.  The standard specifies two mechanisms for defining
new Content-Type subtypes:

1.  Private values (starting with X-) may be defined between
    cooperating mail composing and reading programs without outside
    registration.  Use of this mechanism requires knowing that the
    reader of the message will not mistake the content type for
    something other than originally intended.

2.  New standard values must be registered with IANA.  Where intended
    for public use, the formats they refer to must also be defined by
    a published specification.

Messages that do not have a Content-Type field in their header are
displayed by user agents as if

    Content-Type: Text/plain; Charset=US-ASCII

had been specified.

When a mail reader encounters mail with an unknown Content-Type value,
it will generally treat it as equivalent to application/octet-stream.


The Content-Transfer-Encoding Header Field

Many Content-Types which could usefully be transported via e-mail are
represented, in their "natural" format, as 8-bit character or binary
data.  Such data cannot be transmitted over some transport protocols.
For example, SMTP (Simple Mail Transfer Protocol is an Internet
standard for transporting e-mail defined by a document called RFC 821)
restricts mail messages to 7-bit ASCII data with lines no longer than
1000 characters.

MIME provides two mechanisms for re-encoding such data into a 7-bit
short-line format.  The Content-Transfer-Encoding header field
indicates the mechanism used to perform such an encoding.  The
Content-Transfer-Encoding field indicates the transformation that has
been used to represent the body in an acceptable manner for transport.

The possible values for the Content-Transfer-Encoding field are:
        BASE64
        QUOTED-PRINTABLE
        8BIT
        7BIT
        BINARY
        x-EncodingName
These values are not case sensitive.  That is, Base64, BASE64 and
bAsE64 are all equivalent.  An encoding type of 7BIT requires that the
body is already in a 7-bit mail-ready representation.  That is the
default value: Content-Transfer-Encoding: 7BIT is assumed if the
Content-Transfer-Encoding header field is not present.

Both BASE64 and the QUOTED-PRINTABLE imply an encoding that consists
of lines no longer than 76 ASCII characters.  In other respects the
two encoding schemes are very different.

The encoding scheme implied by QUOTED-PRINTABLE is most appropriate
for data that consists primarily of printable ASCII characters. Using
this encoding method, printable ASCII character are represented as
themselves.  The equals sign (=) serves as an escape character.  Any
character that is not a printable or white space ASCII character is
represented as an equals sign followed by two hexadecimal digits.  An
equals sign in the message is also represented in this way.  Lines
that are longer than 76 characters are cut off after the 75th
character and the line ends with a equals sign.

The advantages of using the QUOTED-PRINTABLE encoding for message that
are mostly printable ASCII characters are that few additional
characters are required and the message can be read by human beings
who to not have a MIME aware mail reading program.  As an example,
here is an EDI interchange in QUOTED-PRINTABLE encoding:

ISA*00*          *00*          *01*987654321      *12*8005551234     *910=
607*0111*U*00200*110000777*0*T*>
GS*PO*987654321*8005551234*920501*2032*7721*X*002003
ST*850*000000001
BEG*00*NE*MS1112**920501**CONTRACT#
REF*IT*8128827763
N1*ST*MAVERICK SYSTEMS
N3*3312 NEW HAMPSHIRE STREET
N4*SAN JOSE*CA*94811
PO1*1*25*EA***VC*TP8MM*CB*TAPE8MM
PO1*2*30*EA***VC*TP1/4*CB*TAPE1/4INCH
PO1*3*125*EA***VC*DSK31/2*CB*DISK35
CTT*3
SE*11*000000001
GE*1*7721
IEA*1*110000777

Except for the ISA segment having been wrapped onto two lines, the
QUOTED-PRINTABLE encoding of the interchange is identical to its 7BIT
representation.

The BASE64 encoding mechanism is well suited for representing binary
files.  It represents any sequence of three bytes as four printable
ASCII characters.  The same interchange as shown above but using the
BASE64 encoding would look like:

SVNBKjAwKiAgICAgICAgICAqMDAqICAgICAgICAgICowMSo5ODc2NTQzMjEgICAgICAqMTIq
ODAwNTU1MTIzNCAgICAgKjkxMDYwNyowMTExKlUqMDAyMDAqMTEwMDAwNzc3KjAqVCo+CkdT
KlBPKjk4NzY1NDMyMSo4MDA1NTUxMjM0KjkyMDUwMSoyMDMyKjc3MjEqWCowMDIwMDMKU1Qq
ODUwKjAwMDAwMDAwMQpCRUcqMDAqTkUqTVMxMTEyKio5MjA1MDEqKkNPTlRSQUNUIwpSRUYq
SVQqODEyODgyNzc2MwpOMSpTVCpNQVZFUklDSyBTWVNURU1TCk4zKjMzMTIgTkVXIEhBTVBT
SElSRSBTVFJFRVQKTjQqU0FOIEpPU0UqQ0EqOTQ4MTEKUE8xKjEqMjUqRUEqKipWQypUUDhN
TSpDQipUQVBFOE1NClBPMSoyKjMwKkVBKioqVkMqVFAxLzQqQ0IqVEFQRTEvNElOQ0gKUE8x
KjMqMTI1KkVBKioqVkMqRFNLMzEvMipDQipESVNLMzUKQ1RUKjMKU0UqMTEqMDAwMDAwMDAx
CkdFKjEqNzcyMQpJRUEqMSoxMTAwMDA3NzcK

BASE64 bears some resemblance to uuencode in both appearance and
function.  However, uuencode uses characters that may not be processed
properly by an EBCDIC gateway.

The values 8bit, 7bit, and binary all imply that no encoding has been
performed. However, they are useful to indicate of the kind of data
contained in the object, and therefore of the kind of encoding that
might need to be performed for transmission in a given transport
system.  7bit means that the data is all represented as short lines of
ASCII data.  8bit means that the lines are short, but there may be
non-ASCII characters.  Binary means that not only may non-ASCII
characters be present, but also that the lines are not necessarily
short enough for SMTP transport.

The difference between 8bit and binary is that binary does not require
adherence to any limits on line length.  8bit and binary are intended
for compatibility with future Internet e-mail transport standards and
with gateways to non-Internet environments.  As of this writing there
are no standardized Internet e-mail transports for which it is
legitimate to include unencoded 8-bit or binary data in mail bodies.

Note that the five values defined for the Content-Transfer-Encoding
field imply nothing about the Content-Type other than the algorithm by
which it was encoded or the transport system requirements if
unencoded.

Some implementations may support additional Content-Transfer-Encoding
values (it is permitted but strongly discouraged by the standard).
Any such additional values must have names that begin with X- to
indicate its non-standard status For example:

        Content-Transfer-Encoding: x-my-new-encoding.

If a Content-Transfer-Encoding header field appears as part of a
message header, it applies to the entire body of that message.  If a
Content-Transfer-Encoding header field appears as part of a body
part's headers, it applies only to the body of that body part.  If a
message or body part is of type Multipart or Message, the
Content-Transfer-Encoding must be 7bit, 8bit or Binary.

The encoding mechanisms defined here explicitly encode all data in
ASCII.  Thus, for example, suppose a message or body part has header
fields such as:

        Content-Type: text/plain; charset=ISO-8859-1
        Content-transfer-encoding: base64

This should be interpreted to mean that the body is a Base64 ASCII
encoding of data that was originally in ISO-8859-1, and will be in
that character set again after decoding.


Optional Content-ID Header Field

It may be desirable to allow one body to reference another.
Accordingly, bodies may be labeled using the Content-ID header field,
which is syntactically identical to the RFC 822 Message-ID header
field: Content-ID values should be be as unique as possible.


Optional Content-Description Header Field

The ability to associate descriptive information with a 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.


Summary

Using MIME-Version, Content-Type, and Content-Transfer-Encoding header
fields, it is possible to include arbitrary types of data objects in
RFC 822 conformant mail messages.  No restrictions imposed by RFC 821
or RFC 822 are violated. MIME has been designed to avoid problems
caused by additional restrictions imposed by some Internet mail
transport mechanisms. The Multipart and Message content types allow
mixing and hierarchical structuring of objects of different types in a
single message.  Further content types provide a mechanism for tagging
messages or body parts as audio, image, or other kinds of data.  A
parameter syntax allows further specification of data format details,
particularly the specification of alternate character sets.
Additional optional header fields provide mechanisms for certain
extensions deemed desirable by many implementors.  Finally, a number
of useful content types are defined for general use by consenting user
agents, notably Text/Richtext, Message/Partial, and
Message/External-Body.

To promote interoperability between user agents, the MIME standard
specifies a minimal subset of MIME features a user agent must support
to be considered MIME conformant.


A Complex Multipart Example

The outline of a complex multipart message follows.  This message has
five parts to be displayed serially: two introductory plain text
parts, an embedded multipart message, a richtext part, and a closing
encapsulated text message in a non-ASCII character set.  The embedded
multipart message has two parts to be displayed in parallel, a picture
and an audio fragment.

    MIME-Version: 1.0
    From: Nathaniel Borenstein <[e-mail]>
    Subject: A multipart example
    Content-Type: multipart/mixed;
                  boundary=unique-boundary-1

    This is the preamble area of a multipart message.  Mail readers
    that understand multipart format should ignore this preamble.
    If you are reading this text, you might want to consider changing
    to a mail reader that understands how to properly display
    multipart messages.
    --unique-boundary-1

    Some text appears here...
    [Note that the preceding blank line means
    no header fields were given and this is text,
    with charset US ASCII.  It could have been
    done with explicit typing as in the next part.]

    --unique-boundary-1
    Content-type: text/plain; charset=US-ASCII

    This could have been part of the previous part, but illustrates
    explicit versus implicit typing of body parts.

    --unique-boundary-1
    Content-Type: multipart/parallel; boundary=unique-boundary-2

    --unique-boundary-2
    Content-Type: audio/basic
    Content-Transfer-Encoding: base64

    ... base64-encoded 8000 Hz single-channel
    u-law-format audio data goes here ...

    --unique-boundary-2
    Content-Type: image/gif
    Content-Transfer-Encoding: Base64

    ... base64-encoded image data goes here...

    --unique-boundary-2--

    --unique-boundary-1
    Content-type: text/richtext

    This is <bold><italic>richtext.</italic></bold><nl><nl>Isn't it
    <bigger><bigger>cool?</bigger></bigger>

    --unique-boundary-1
    Content-Type: message/rfc822

    From: (name in US-ASCII)
    Subject: (subject in US-ASCII)
    Content-Type: Text/plain; charset=ISO-8859-1
    Content-Transfer-Encoding: Quoted-printable

    ... Additional text in ISO-8859-1 goes here ...

    --unique-boundary-1--