1. 介绍
自从1982年发布以来，RFC822已经定义了一个在Internet上传输文本邮件的标准格式。RFC822格式是如此的成功，它已经完全或部分的为大家所接受，其程度甚至超越了Internet或在RFC821中定义的Internet SMTP。也正是由于这种格式被广泛的使用，所以许多限制因素日益约束着使用者群体。
RFC822被制定为用来指定文本信息格式。这样，非文本信息――如包含音频或图像的多媒体信息――就完全没有被提及。甚至对一些文本的情况也是这样。RFC822不适用于那些需要多于US－ASCII字符集内容的使用者。因为RFC822没有定义一种机制，以允许邮件包含音频、视频、亚洲语言的文本甚至一些欧洲的语言文本，所以需要一个额外的规范来进行说明。
RFC821/822中的一个基于邮件系统的明显限制，就是将电子邮件消息(message)内容限制在一些由7位的US-ASCII字符组成的短行中（每行1000字节或更少[RFC821]）。这就迫使使用者在用本地用户代理（UA—User Agent，用来收发邮件的程序）发送他们的邮件之前，先要将将要发送的非文本数据转换为可打印的7位的US-ASCII字符。当前在Internet上使用的编码方式有：纯十六进制、uuencode、RFC1421中说明的base 64、ATK(the Andrew Toolkit Representation)及一些其它方式。
当为在RFC822主机与X.400主机之间交换邮件信息而设计网关时，RFC822的局限性就更加明显了。X.400[X400]指定了一种在电子邮件消息中包含非文本内容的机制。当前，从X.400消息到RFC822消息的映射标准规定，X.400消息中的非文本部分必须要转换为IA5Text格式，否则，这些内容就会被丢弃，并在丢弃即将发生时，通报RFC822的使用者。当一个用户丢掉了他想接收的内容时，这显然是十分另人不快的。即使在用户代理不能处理非文本内容的时候，用户也可以对其采取一些额外的机制，来提取有用的信息。另外，这种处理也没有考虑到：消息最后可能会被网关转发到支持非文本信息的X.400消息处理系统中。
这篇文档描述了几种机制，将它们联合起来，可以解决大部分的这类问题，而不会引入与RFC822不兼容的问题。详细的说，它描述了：
(1) “MIME-Version”头字段。它使用一个版本号来说明消息适用于MIME，而且允许邮件处理代理将这类消息与其它由旧版本或不适用的软件所产生的消息相区别。
(2) 在RFC1049中归纳的“Content-Type”头字段。用来指定消息数据的媒体类型(media type)及子类型，以及指定这些数据的本地表示方法（规范形式）。
(3) “Content-Transfer-Encoding”头字段。用来指定应用于主体(body)的编码转换方式及结果所处的范围。编码转换不同于恒等转换，它通常用于使数据通过那些有数据或字符集限制的邮件传输机制。
(4) 两个附加的头字段：“Content-ID”、“Content-Description”。它们被用来更深层的描述主体(body)中的数据。
这篇文档中的所有的头字段定义都服从于RFC822中规定的句法规则。特别的，除了“Content-Disposition”以外，所有的这些头字段都可以包含RFC822注释。这些注释没有实际意义，应该在MIME处理过程中忽略。
最后，为了说明及促进互用性，RFC2049为以上机制的子集提供了一个基本的适用性声明。它定义了与本文档相适应的最低限度。
历史注释：在第一次阅读时，这组文档中所描述的几个机制看起来会有些奇怪或具有巴洛克风格。但要注意，对于开发这组文档的团体而言，与现有标准兼容以及遇到现有习惯时的稳健性，这两者具有相同的优先级。特别是“兼容性”永远优先于“简洁”。
请查阅当前版本的《因特网官方标准》(“Internet Official Protocol Standards”)以得到本协议的标准化状态及情况。RFC 822和STD3，RFC1123也提供了MIME的基本背景，符合MIME的实现都不会违背它们。另外，MIME的实现者也许会关心几个另外的RFC文档，特别是RFC1344、RFC1345和RFC1524。
2. 定义、约定和一般的BNF语法
虽然这组文档所定义的机制都以文字的形式给出，但仍有一部分是由RFC 822定义的BNF符号所描述。为了了解这组文档，实现者需要熟悉这些符号，并参考RFC 822，以得到这些扩充的BNF符号的完整解释。
本文档中的一些扩展BNF所构成的名字参考了RFC 822中的句法规则。或要获得完整的语法则要组合如下内容：本系列每个文档中收集了语法的附录、RFC822中定义的BNF以及在RFC1123中对RFC822所进行的修正。（其中给出了“return”、“data”、“mailbox”的语法变化）
在这组文档中，所有的数值字及字节的值都由十进制的形式给出。所有的媒体类型（media type）、子类型以及参数名称都是大小写无关的。然而，除非特别说明，否则参数内容是大小写相关的。
格式注释：这部分的“注释”提供了一些不重要的信息，在阅读时可以跳过它们而不会错过任何本质的东西。添加这些注释的基本目的是为了说明关于这系列文档的基础原理，或是为了将其恰当地放置于历史或发展过程中。这些信息，可以被那些只关心建立实现的人所忽略，但对那些希望懂得为什么某种设计会被应用的人来说，这些信息还是会有一定用处的。
2.1 CRLF
在这系列文档中，术语CRLF指一个US-ASCII字符序列。它由两个字符组成：CR（十进制值为13）和LF（十进制值为10），它们按顺序放在一起，构成RFC 822邮件的换行。
2.2 字符集 （Character Set）
在MIME中，术语“字符集”（character set）被用来表示一种将字节序列转换成字符序列的方法。注意，反方向不需要绝对的、明确的转换，因为并不是所有的字符都可以被一个已知的字符集描述，而且一个字符集可能提供多于一个的字节序列，来表示某字符序列。
本定义允许将各种类型的字符编码做为字符集使用，如从简单的单表映射（如US-ASCII）到多表转换方法（如使用ISO 2022技术）等。然而与MIME字符集名称相关的定义则必须完全说明所要执行的映射。特别的，不允许使用外部描述信息来决定精确的映射。
注释：术语字符集(“character set”)最初是用来描述一些简单的方案如US-ASCII和ISO-8859-1的，它们都是从单一字节到单一字符的一对一映射。多字节编码字符集和转换方法使得情况更加复杂。例如，一些团体使用术语“character encoding”，而不是MIME中所使用的术语“character set”来表示字符集，而且使用“coded character set”来抽象的表示从整数（而不是字节）到字符的映射。
2.3 消息 （Message）
术语“消息”（Message）在没有进一步限定的时候，表示的是在Internet上传输的（完整或“顶层”的）RFC822消息，或者表示压缩在“message/rfc822”或“message/partial”中的内容。
2.4 实体 （Entity）
术语“实体”（Entity）特指MIME定义的头字段(header field)及内容(content),它们存在于消息(message)及多部分实体的一部分之中。对这些实体的规范是MIME的基本内容。因为一个实体的内容经常被称为“主体”(“body”)，所以关于实体主体说法是有意义的。任何字段都可以出现在实体头信息中，但是只有那些以“content-”开头的字段有真实的、与MIME相关的意义。注意，这并不意味着它们没有意义，一个没有MIME头字段的实体（或消息）的意义由RFC822所定义。
2.5 部分主体 （Body Part）
“body part”指的是多部分实体(mulitpart entity)中的一个实体(entity)。
2.6 主体 （Body）
在没做进一步说明的时候，术语“主体”（body）指的是一个实体(entity)的主体部分。也就是指“消息”(message)或“部分主体”(body part)的主体部分。
注释：很明显，以上四个概念被循环定义。因为MIME消息的整个结构就是递归的，所以这种情况不可避免。
2.7 7位的数据 （7bit Data）
“7位的数据”(7bit Data)所描述的是相对较短的数据行：每行有998个或更少的8位字节内容，行分隔符为CRLF序列[RFC-821]。其中，每一个8位字节的值都不可以大于十进制的127，也不能为NUL(十进制的0)，而且CR（十进制值为13）和LF（十进制值为10）字节只可以出现在CRLF序列中。
2.8 8位的数据 （8bit Data）
“8位的数据”(8bit Data)所描述的是相对较短的数据行：每行有998个或更少的8位字节内容，行分隔符为CRLF序列[RFC-821]。其但是字节的值可以大于十进制的127。与“7bit data”一样， CR（十进制值为13）和LF（十进制值为10）字节只可以出现在CRLF序列中，字节的值不能为NUL(十进制的0)。
2.9 二进制数据 （Binary Data）
“二进制数据”（Binary Data）是指可以包含任何字节序列的数据。
2.10 行 (Lines)
“行”（Lines）被定义为由CRLF分隔的字节序列。这与RFC 821及RFC 822一致。“行”(Lines)是指消息(Message)中的数据单位，它可以符合或不符合用户代理（user agent）所显示的真实情形。
