rfc2045.pdf资源-CSDN文库

需积分: 11 137 浏览量 2016-06-26 00:26:28 上传评论收藏 44KB PDF 举报

文档标题“rfc2045.pdf”指的是一个被编号为RFC 2045的互联网文档，而RFC是“Request for Comments”的缩写，意为“请求注释”，是互联网标准制定的一系列报告的编号。这些文档记录了互联网协议、标准和功能的建议和结论。RFC文档被互联网工程任务组(IETF)、互联网研究任务组(IRTF)以及全球互联网社区用于各种目的，包括向公众提供技术信息和标准。描述中提到的“Base64编码”是一种编码方法，用于将二进制数据编码成纯文本。Base64编码在多个场景中非常有用，尤其是在需要将数据以纯文本形式传输或存储时，例如在电子邮件传输或在某些网络协议中。 RFC文档中涉及的标签“RFC, Base64”揭示了文档的内容，指的是该文档可能直接关联到互联网标准协议中的Base64编码使用规范。从提供的部分内容来看，文档与“Multipurpose Internet Mail Extensions”，通常缩写为MIME相关。MIME是一系列定义互联网邮件格式的规范，它允许邮件系统处理不同于ASCII字符集的文本消息体、非文本消息体的多种格式、多部分消息体以及非ASCII字符集的邮件头部信息。具体内容中说明了RFC 2045是MIME标准的一部分，该标准分为五个部分： 1. RFC 2045：描述了MIME消息的格式，包括邮件体的各种头部信息。 2. RFC 2046：定义了MIME媒体类型系统的通用结构，并规定了一系列的媒体类型。 3. RFC 2047：描述了扩展RFC 822以允许邮件头部字段中使用非ASCII文本数据。 4. RFC 2048：规定了MIME相关设施的IANA（互联网 Assigned Numbers Authority）注册程序。 5. RFC 2049：描述了MIME一致性准则，并提供了一些MIME消息格式的示例。这些RFC文档修订了之前版本的RFC 1521、1522和1590，这些又是之前RFC 1341和1342的修订版本。文档提到了STD 11，RFC 822，它定义了一种消息表示协议，详细说明了US-ASCII消息头，但对消息内容或消息体部分则仅限于平面的US-ASCII文本。MIME规范通过一系列的文档扩展了这一标准，支持了除US-ASCII之外的字符集用于文本消息体、非文本消息体的扩展格式集合、多部分消息体，以及非US-ASCII字符集的邮件头部信息。 RFC 2045文档是互联网邮件系统扩展标准的一部分，详细规定了MIME消息结构，特别是邮件体的头部信息。Base64编码作为互联网上数据传输的一种编码方式，在这个文档中可能有相应的规范和应用。MIME标准的推出和修订历史展示了互联网通信标准演进的过程，反映了技术发展和标准化工作的连贯性。整体而言，这部分内容强调了MIME标准的重要性和Base64编码在电子邮件协议中的核心地位。

资源推荐

资源详情

资源评论

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, RFC 822, 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 RFC 934, STD

11, and RFC 1049, but extends and revises them. Because RFC 822 said

so little about message bodies, these documents are largely

orthogonal to (rather than a revision of) RFC 822.

This initial document specifies the various headers used to describe

the structure of MIME messages. The second document, RFC 2046,

defines the general structure of the MIME media typing system and

defines an initial set of media types. The third document, RFC 2047,

describes extensions to RFC 822 to allow non-US-ASCII text data in

Freed & Borenstein Standards Track [Page 1]

RFC 2045 Internet Message Bodies November 1996

Internet mail header fields. The fourth document, RFC 2048, specifies

various IANA registration procedures for MIME-related facilities. The

fifth and final document, RFC 2049, 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

Freed & Borenstein Standards Track [Page 2]

RFC 2045 Internet Message Bodies November 1996

1. Introduction

Since its publication in 1982, RFC 822 has defined the standard

format of textual mail messages on the Internet. Its success has

been such that the RFC 822 format has been adopted, wholly or

partially, well beyond the confines of the Internet and the Internet

SMTP transport defined by RFC 821. As the format has seen wider use,

a number of limitations have proven increasingly restrictive for the

user community.

RFC 822 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, RFC 822 is inadequate for the needs of mail users whose

languages require the use of character sets richer than US-ASCII.

Since RFC 822 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 RFC 821/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 [RFC-821]) 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

RFC 1421, the Andrew Toolkit Representation [ATK], and many others.

The limitations of RFC 822 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 RFC 822

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 RFC 822 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.

Freed & Borenstein Standards Track [Page 3]

RFC 2045 Internet Message Bodies November 1996

This document describes several mechanisms that combine to solve most

of these problems without introducing any serious incompatibilities

with the existing world of RFC 822 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 RFC 1049,

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

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 RFC 822. In

particular, all of these header fields except for Content-Disposition

can include RFC 822 comments, which have no semantic content and

should be ignored during MIME processing.

Finally, to specify and promote interoperability, RFC 2049 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.

Freed & Borenstein Standards Track [Page 4]

RFC 2045 Internet Message Bodies November 1996

Please refer to the current edition of the "Internet Official

Protocol Standards" for the standardization state and status of this

protocol. RFC 822 and STD 3, RFC 1123 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 RFC 1344,

RFC 1345, and RFC 1524.

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 RFC 822. Implementors will need to be familiar with

this notation in order to understand this set of documents, and are

referred to RFC 822 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 RFC 822. A complete formal

grammar, then, is obtained by combining the collected grammar

appendices in each document in this set with the BNF of RFC 822 plus

the modifications to RFC 822 defined in RFC 1123 (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 RFC 822 mail.

Freed & Borenstein Standards Track [Page 5]

剩余30页未读，继续阅读

评论收藏

内容反馈

SoyaDokio

粉丝: 9
资源: 3

rfc2045.pdf

RFC2045 PDF文档

RFC文档pdf完整版

原始MIME的rfc文档2045-2049

RFC2045-2049.rar

rfc中文文档.rar

rfc全部文档离线下载rfc1-rfc8700

rfc2045 2046 2047 中文

RFC2045&RFC2046(smtp协议相关)

RFC系列文档大全（RFC1-RFC1000）

RFC中文文档包括RFC1-3093.zip

rfc2045.rar_rfc2045_邮件服务器

rfc3551.pdf

HTTP2-rfc7540.pdf

RFC1157.pdf

rfc1904.pdf

rfc5416.pdf

RFC英文文档完整版.zip

content-type.js:一个（主要是）符合 rfc-2045 的内容类型解析器

RFC3501.rar_RFC3501_rfc 3501_rfc35_rfc3501 pdf_rfc3501.pdf

RTMFP:rfc7425.pdf

rfc7049.pdf

CGI手册RFC3875.pdf

rfc3640.pdf

rfc2819.pdf

rfc1631.pdf英文版

RFC3984.pdf

rfc1903.pdf

MSRP-rfc4975.pdf

STUN_RFC3489.pdf

最新资源