📄 rfc2045-multipurposeinternetmailextensions(mime).mht
字号:
From: <由 Microsoft Internet Explorer 5 保存>
Subject: RFC 2045 (rfc2045) - Multipurpose Internet Mail Extensions (MIME) Part One
Date: Wed, 4 Jun 2008 09:36:51 +0800
MIME-Version: 1.0
Content-Type: multipart/related;
type="text/html";
boundary="----=_NextPart_000_0000_01C8C626.84C48E30"
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
This is a multi-part message in MIME format.
------=_NextPart_000_0000_01C8C626.84C48E30
Content-Type: text/html;
charset="gb2312"
Content-Transfer-Encoding: quoted-printable
Content-Location: http://www.faqs.org/rfcs/rfc2045
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RFC 2045 (rfc2045) - Multipurpose Internet Mail =
Extensions (MIME) Part One</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dgb2312">
<META=20
content=3D"RFC 2045 - Multipurpose Internet Mail Extensions (MIME) Part =
One: Format of Internet Message Bodies"=20
name=3Ddescription>
<META content=3D"RFC1521, RFC1522, RFC1590" name=3Dobsoletes>
<SCRIPT language=3DJavaScript1.2>=0A=
function erfc(s)=0A=
{document.write("<A href=3D\"/rfccomment.php?rfcnum=3D"+s+"\" =
target=3D\"_blank\" =
onclick=3D\"window.open('/rfccomment.php?rfcnum=3D"+s+"','Popup','toolbar=
=3Dno,location=3Dno,status=3Dno,menubar=3Dno,scrollbars=3Dyes,resizable=3D=
yes,width=3D680,height=3D530,left=3D30,top=3D43'); return =
false;\")>Comment on RFC "+s+"</A>\n");}=0A=
//-->=0A=
</SCRIPT>
<META content=3D"MSHTML 6.00.2900.3243" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<P align=3Dcenter><IMG height=3D62 alt=3D""=20
src=3D"http://www.faqs.org/images/library.jpg" width=3D150 =
align=3Dmiddle=20
border=3D0></P>
<H1 align=3Dcenter>RFC 2045 (RFC2045)</H1>
<P align=3Dcenter>Internet RFC/STD/FYI/BCP Archives</P>
<DIV align=3Dcenter>[ <A href=3D"http://www.faqs.org/rfcs/">RFC =
Index</A> | <A=20
href=3D"http://www.faqs.org/rfcs/rfcsearch.html">RFC Search</A> | <A=20
href=3D"http://www.faqs.org/faqs/">Usenet FAQs</A> | <A=20
href=3D"http://www.faqs.org/contrib/">Web FAQs</A> | <A=20
href=3D"http://www.faqs.org/docs/">Documents</A> | <A=20
href=3D"http://www.city-data.com/">Cities</A> ]=20
<P><STRONG>Alternate Formats:</STRONG> <A=20
href=3D"http://www.faqs.org/ftp/rfc/rfc2045.txt">rfc2045.txt</A> | <A=20
href=3D"http://www.faqs.org/ftp/rfc/pdf/rfc2045.txt.pdf">rfc2045.txt.pdf<=
/A></P></DIV>
<P align=3Dcenter>
<SCRIPT language=3DJavaScript><!--=0A=
erfc("2045");=0A=
// --></SCRIPT>
</P>
<H3 align=3Dcenter>RFC 2045 - Multipurpose Internet Mail Extensions =
(MIME) Part=20
One: Format of Internet Message Bodies</H3>
<HR noShade SIZE=3D2>
<PRE>
Network Working Group N. Freed
Request for Comments: 2045 Innosoft
Obsoletes: 1521, 1522, 1590 N. Borenstein
Category: Standards Track First Virtual
November 1996
Multipurpose Internet Mail Extensions
(MIME) Part One:
Format of Internet Message Bodies
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
STD 11, <A href=3D"http://www.faqs.org/rfcs/rfc822.html">RFC 822</A>, =
defines a message representation protocol specifying
considerable detail about US-ASCII message headers, and leaves the
message content, or message body, as flat US-ASCII text. This set of
documents, collectively called the Multipurpose Internet Mail
Extensions, or MIME, redefines the format of messages to allow for
(1) textual message bodies in character sets other than
US-ASCII,
(2) an extensible set of different formats for non-textual
message bodies,
(3) multi-part message bodies, and
(4) textual header information in character sets other than
US-ASCII.
These documents are based on earlier work documented in <A =
href=3D"http://www.faqs.org/rfcs/rfc934.html">RFC 934</A>, STD
11, and <A href=3D"http://www.faqs.org/rfcs/rfc1049.html">RFC =
1049</A>, but extends and revises them. Because <A =
href=3D"http://www.faqs.org/rfcs/rfc822.html">RFC 822</A> said
so little about message bodies, these documents are largely
orthogonal to (rather than a revision of) <A =
href=3D"http://www.faqs.org/rfcs/rfc822.html">RFC 822</A>.
This initial document specifies the various headers used to describe
the structure of MIME messages. The second document, <A =
href=3D"http://www.faqs.org/rfcs/rfc2046.html">RFC 2046</A>,
defines the general structure of the MIME media typing system and
defines an initial set of media types. The third document, <A =
href=3D"http://www.faqs.org/rfcs/rfc2047.html">RFC 2047</A>,
describes extensions to <A =
href=3D"http://www.faqs.org/rfcs/rfc822.html">RFC 822</A> to allow =
non-US-ASCII text data in
Internet mail header fields. The fourth document, <A =
href=3D"http://www.faqs.org/rfcs/rfc2048.html">RFC 2048</A>, specifies
various IANA registration procedures for MIME-related facilities. The
fifth and final document, <A =
href=3D"http://www.faqs.org/rfcs/rfc2049.html">RFC 2049</A>, describes =
MIME conformance
criteria as well as providing some illustrative examples of MIME
message formats, acknowledgements, and the bibliography.
These documents are revisions of RFCs 1521, 1522, and 1590, which
themselves were revisions of RFCs 1341 and 1342. An appendix in RFC
2049 describes differences and changes from previous versions.
Table of Contents
1. Introduction ......................................... 3
2. Definitions, Conventions, and Generic BNF Grammar .... 5
2.1 CRLF ................................................ 5
2.2 Character Set ....................................... 6
2.3 Message ............................................. 6
2.4 Entity .............................................. 6
2.5 Body Part ........................................... 7
2.6 Body ................................................ 7
2.7 7bit Data ........................................... 7
2.8 8bit Data ........................................... 7
2.9 Binary Data ......................................... 7
2.10 Lines .............................................. 7
3. MIME Header Fields ................................... 8
4. MIME-Version Header Field ............................ 8
5. Content-Type Header Field ............................ 10
5.1 Syntax of the Content-Type Header Field ............. 12
5.2 Content-Type Defaults ............................... 14
6. Content-Transfer-Encoding Header Field ............... 14
6.1 Content-Transfer-Encoding Syntax .................... 14
6.2 Content-Transfer-Encodings Semantics ................ 15
6.3 New Content-Transfer-Encodings ...................... 16
6.4 Interpretation and Use .............................. 16
6.5 Translating Encodings ............................... 18
6.6 Canonical Encoding Model ............................ 19
6.7 Quoted-Printable Content-Transfer-Encoding .......... 19
6.8 Base64 Content-Transfer-Encoding .................... 24
7. Content-ID Header Field .............................. 26
8. Content-Description Header Field ..................... 27
9. Additional MIME Header Fields ........................ 27
10. Summary ............................................. 27
11. Security Considerations ............................. 27
12. Authors' Addresses .................................. 28
A. Collected Grammar .................................... 29
1. Introduction
Since its publication in 1982, <A =
href=3D"http://www.faqs.org/rfcs/rfc822.html">RFC 822</A> has defined =
the standard
format of textual mail messages on the Internet. Its success has
been such that the <A =
href=3D"http://www.faqs.org/rfcs/rfc822.html">RFC 822</A> format has =
been adopted, wholly or
partially, well beyond the confines of the Internet and the Internet
SMTP transport defined by <A =
href=3D"http://www.faqs.org/rfcs/rfc821.html">RFC 821</A>. As the =
format has seen wider use,
a number of limitations have proven increasingly restrictive for the
user community.
<A href=3D"http://www.faqs.org/rfcs/rfc822.html">RFC 822</A> was =
intended to specify a format for text messages. As such,
non-text messages, such as multimedia messages that might include
audio or images, are simply not mentioned. Even in the case of text,
however, <A href=3D"http://www.faqs.org/rfcs/rfc822.html">RFC 822</A> =
is inadequate for the needs of mail users whose
languages require the use of character sets richer than US-ASCII.
Since <A href=3D"http://www.faqs.org/rfcs/rfc822.html">RFC 822</A> =
does not specify mechanisms for mail containing audio,
video, Asian language text, or even text in most European languages,
additional specifications are needed.
One of the notable limitations of <A =
href=3D"http://www.faqs.org/rfcs/rfc821.html">RFC 821</A>/822 based mail =
systems is
the fact that they limit the contents of electronic mail messages to
relatively short lines (e.g. 1000 characters or less [<A =
href=3D"http://www.faqs.org/rfcs/rfc821.html">RFC-821</A>]) of
7bit US-ASCII. This forces users to convert any non-textual data
that they may wish to send into seven-bit bytes representable as
printable US-ASCII characters before invoking a local mail UA (User
Agent, a program with which human users send and receive mail).
Examples of such encodings currently used in the Internet include
pure hexadecimal, uuencode, the 3-in-4 base 64 scheme specified in
<A href=3D"http://www.faqs.org/rfcs/rfc1421.html">RFC 1421</A>, the =
Andrew Toolkit Representation [ATK], and many others.
The limitations of <A =
href=3D"http://www.faqs.org/rfcs/rfc822.html">RFC 822</A> mail become =
even more apparent as gateways
are designed to allow for the exchange of mail messages between RFC
822 hosts and X.400 hosts. X.400 [X400] specifies mechanisms for the
inclusion of non-textual material within electronic mail messages.
The current standards for the mapping of X.400 messages to <A =
href=3D"http://www.faqs.org/rfcs/rfc822.html">RFC 822</A>
messages specify either that X.400 non-textual material must be
converted to (not encoded in) IA5Text format, or that they must be
discarded, notifying the <A =
href=3D"http://www.faqs.org/rfcs/rfc822.html">RFC 822</A> user that =
discarding has occurred.
This is clearly undesirable, as information that a user may wish to
receive is lost. Even though a user agent may not have the
capability of dealing with the non-textual material, the user might
have some mechanism external to the UA that can extract useful
information from the material. Moreover, it does not allow for the
fact that the message may eventually be gatewayed back into an X.400
message handling system (i.e., the X.400 message is "tunneled"
through Internet mail), where the non-textual information would
definitely become useful again.
This document describes several mechanisms that combine to solve most
of these problems without introducing any serious incompatibilities
with the existing world of <A =
href=3D"http://www.faqs.org/rfcs/rfc822.html">RFC 822</A> mail. In =
particular, it
describes:
(1) A MIME-Version header field, which uses a version
number to declare a message to be conformant with MIME
and allows mail processing agents to distinguish
between such messages and those generated by older or
non-conformant software, which are presumed to lack
such a field.
(2) A Content-Type header field, generalized from <A =
href=3D"http://www.faqs.org/rfcs/rfc1049.html">RFC 1049</A>,
which can be used to specify the media type and subtype
of data in the body of a message and to fully specify
the native representation (canonical form) of such
data.
(3) A Content-Transfer-Encoding header field, which can be
used to specify both the encoding transformation that
was applied to the body and the domain of the result.
Encoding transformations other than the identity
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -