多用途互联网邮件扩展-MIME
2024-05-31 15:38:57 
阿炯
多用途互联网邮件扩展（Multipurpose Internet Mail Extensions，缩写：MIME）是一个互联网标准，它扩展了电子邮件标准，使其能够支持：
非ASCII字符文本；
非文本格式附件（二进位制、声音、图片等）；
由多部分（multiple parts）组成的消息体；
包含非ASCII字符的标头信息（Header information）。这个标准被定义于 RFC 2045、RFC 2046、RFC 2047、RFC 2048、RFC 2049 等RFC中。
MIME改善了由 RFC 822 转变而来的 RFC 2822，这些旧标准规定电子邮件标准并不允许在邮件消息中使用7位ASCII字符集以外的字符。正因如此，一些非英语字符消息和二进制文件，图像，声音等非文字消息原本都不能在电子邮件中传输（MIME可以）。MIME规定了用于表示各种各样的数据类型的符号化方法。此外，在万维网中使用的HTTP协议中也使用了MIME的框架，标准被扩展为互联网媒体形式。
MIME headers
MIME是通过标准化电子邮件报文的头部的附加域（fields）而实现的；这些头部的附加域，描述新的报文类型的内容和组织形式。
MIME版本
（MIME-Version）这个标头区域在邮件消息的报文用一个版本号码来指明消息遵从的MIME规范版本。当前版本是1.0。
MIME-Version: 1.0
内容类型
（Content-Type），这个标头区域用于指定信息的类型。一般以下面的形式呈现：
Content-Type: [type]/[subtype]; parameter
type有以下的形式：
Text：用于标准化地表示的文字消息，文字消息可以是多种字符集和或者多种格式的；
Multipart：用于连接消息体的多个部分构成一个消息，这些部分可以是不同类型的资料；
Application：用于传输应用程序资料或者二进制资料；
Message：用于包装一个E-mail消息；
Image：用于传输静态图片资料；
Audio：用于传输音频或者音声资料；
Video：用于传输动态影像资料，可以是与音频编辑在一起的视频资料格式；
Font：用于传输字体文件；
Model：用于传输3D模型文件。
subtype用于指定type的详细形式。content-type/subtype配对的集合和与此相关的参数，将随着时间而增长。为了确保这些值在一个有序而且公开的状态下开发，MIME使用Internet Assigned Numbers Authority (IANA)作为中心的注册机制来管理这些值。常用的subtype值如下所示：
text/plain（纯文字）
text/html（HTML文件）
application/xhtml+xml（XHTML文件）
image/gif（GIF图片）
image/jpeg（JPEG图片）【PHP中为：image/pjpeg】
image/png（PNG图片）【PHP中为：image/x-png】
audio/mpeg（MP3音频）
audio/aac（AAC音频）
video/mpeg（MPEG视频）
video/mp4（MPEG-4视频）
application/octet-stream（任意的二进制资料）
application/pdf（PDF文件）
application/msword（Microsoft Word文件）
application/vnd.openxmlformats-officedocument.wordprocessingml.document（Microsoft Word 2007文件）
application/vnd.wap.xhtml+xml (wap1.0+)
application/xhtml+xml (wap2.0+)
message/rfc822（RFC 822形式）
multipart/alternative（HTML邮件的HTML形式和纯文本形式，相同内容使用不同形式表示）
application/x-www-form-urlencoded（使用HTTP的POST方法提交的窗体）
multipart/form-data（同上，但主要用于表单提交时伴随文件上传的场合）
此外，尚未被接受为正式数据类型的subtype，可以使用x-开始的独立名称（例如application/x-gzip）。vnd-开始的固有名称也可以使用（例：application/vnd.ms-excel）。
parameter可以用来指定附加的信息，更多情况下是用于指定text/plain和text/htm等的文字编码方式的charset参数。MIME根据type制定了默认的subtype，当客户端不能确定消息的subtype的情况下，消息被看作默认的subtype进行处理。Text默认是text/plain，Application默认是application/octet-stream而Multipart默认情况下被看作multipart/mixed。
内容配置
内容配置（Content-Disposition），原始的MIME只描述邮件内容的结构，并不会处理表现类型的问题。内容配置（Content-Disposition）在RFC 2183 中被添加，用来指明MIME的表现类型。MIME的每一部分可以添加下列配置。
1.inline 添加此配置后客户端应自动展示信息；
2.attachment 添加此配置后客户端在接受到信息后不自动展示，需要用户自己选择相应的方法处理信息。
Content-Disposition字段也提供了一些参数。如文件名，文件的创建日期和修改日期等，使邮件客户端可以保存附件。 以下是一个示例。
Content-Disposition: attachment; filename=genome.jpeg;
modification-date="Wed, 12 Feb 1997 16:29:51 -0500";
尽管有些邮件客户端仅在Content-Type的参数中添加了文件名来通信，但这是不推荐的。正确的做法是在Content-Disposition中指定filename或是同时在Content-Type和Content-Disposition中指定name和filename的参数。在HTTP中Content-Disposition: attachment通常用来提示客户端将响应体作为下载文件，而不是在页面中展示它。filename参数是默认的下载文件名。
内容传输编码
（Content-Transfer-Encoding），这个区域使指定ASCII以外的文字编码方式成为可能。形式如下：
Content-Transfer-Encoding: [mechanism]
其中mechanism的值可以指定为“7bit”，“8bit”，“binary”，“quoted-printable”，“base64”。
7bit：7比特ASCII码。
8bit：8位ASCII码。
binary：Not only may non-ASCII characters be present but the lines are not necessarily short enough for SMTP transport.
quoted-printable：因为欧洲的一些文字和ASCII字符集中的某些字符有部分相同。如果邮件消息使用的是这些语言的话，与ASCII重叠的那些字符可以原样使用，ASCII字符集中不存在的字符采用形如“=??”的方法编码。这里“??”需要用将字符编码后的16进制数字来指定。采用quoted-printable编码的消息，长度不会变得太长，而且大部分都是ASCII中的字符，即使不通过解码也大致可以读懂消息的内容。
base64：这是一种将二进制的01序列转化成ASCII字符的编码方式。编码后的文字或者二进制消息，就可以运用SMTP等只支持ASCII字符的协议发送了。Base64一般被认为会平均增加33%的报文长度，而且，经过编码的消息对于人类来说是不可读的。
x-encodingname：这个值是预留的扩展。
内容标识符（可选）
内容描述（可选）
本文源自：互联网
非ASCII字符文本；
非文本格式附件（二进位制、声音、图片等）；
由多部分（multiple parts）组成的消息体；
包含非ASCII字符的标头信息（Header information）。这个标准被定义于 RFC 2045、RFC 2046、RFC 2047、RFC 2048、RFC 2049 等RFC中。
MIME改善了由 RFC 822 转变而来的 RFC 2822，这些旧标准规定电子邮件标准并不允许在邮件消息中使用7位ASCII字符集以外的字符。正因如此，一些非英语字符消息和二进制文件，图像，声音等非文字消息原本都不能在电子邮件中传输（MIME可以）。MIME规定了用于表示各种各样的数据类型的符号化方法。此外，在万维网中使用的HTTP协议中也使用了MIME的框架，标准被扩展为互联网媒体形式。
MIME headers
MIME是通过标准化电子邮件报文的头部的附加域（fields）而实现的；这些头部的附加域，描述新的报文类型的内容和组织形式。
MIME版本
（MIME-Version）这个标头区域在邮件消息的报文用一个版本号码来指明消息遵从的MIME规范版本。当前版本是1.0。
MIME-Version: 1.0
内容类型
（Content-Type），这个标头区域用于指定信息的类型。一般以下面的形式呈现：
Content-Type: [type]/[subtype]; parameter
type有以下的形式：
Text：用于标准化地表示的文字消息，文字消息可以是多种字符集和或者多种格式的；
Multipart：用于连接消息体的多个部分构成一个消息，这些部分可以是不同类型的资料；
Application：用于传输应用程序资料或者二进制资料；
Message：用于包装一个E-mail消息；
Image：用于传输静态图片资料；
Audio：用于传输音频或者音声资料；
Video：用于传输动态影像资料，可以是与音频编辑在一起的视频资料格式；
Font：用于传输字体文件；
Model：用于传输3D模型文件。
subtype用于指定type的详细形式。content-type/subtype配对的集合和与此相关的参数，将随着时间而增长。为了确保这些值在一个有序而且公开的状态下开发，MIME使用Internet Assigned Numbers Authority (IANA)作为中心的注册机制来管理这些值。常用的subtype值如下所示：
text/plain（纯文字）
text/html（HTML文件）
application/xhtml+xml（XHTML文件）
image/gif（GIF图片）
image/jpeg（JPEG图片）【PHP中为：image/pjpeg】
image/png（PNG图片）【PHP中为：image/x-png】
audio/mpeg（MP3音频）
audio/aac（AAC音频）
video/mpeg（MPEG视频）
video/mp4（MPEG-4视频）
application/octet-stream（任意的二进制资料）
application/pdf（PDF文件）
application/msword（Microsoft Word文件）
application/vnd.openxmlformats-officedocument.wordprocessingml.document（Microsoft Word 2007文件）
application/vnd.wap.xhtml+xml (wap1.0+)
application/xhtml+xml (wap2.0+)
message/rfc822（RFC 822形式）
multipart/alternative（HTML邮件的HTML形式和纯文本形式，相同内容使用不同形式表示）
application/x-www-form-urlencoded（使用HTTP的POST方法提交的窗体）
multipart/form-data（同上，但主要用于表单提交时伴随文件上传的场合）
此外，尚未被接受为正式数据类型的subtype，可以使用x-开始的独立名称（例如application/x-gzip）。vnd-开始的固有名称也可以使用（例：application/vnd.ms-excel）。
parameter可以用来指定附加的信息，更多情况下是用于指定text/plain和text/htm等的文字编码方式的charset参数。MIME根据type制定了默认的subtype，当客户端不能确定消息的subtype的情况下，消息被看作默认的subtype进行处理。Text默认是text/plain，Application默认是application/octet-stream而Multipart默认情况下被看作multipart/mixed。
内容配置
内容配置（Content-Disposition），原始的MIME只描述邮件内容的结构，并不会处理表现类型的问题。内容配置（Content-Disposition）在RFC 2183 中被添加，用来指明MIME的表现类型。MIME的每一部分可以添加下列配置。
1.inline 添加此配置后客户端应自动展示信息；
2.attachment 添加此配置后客户端在接受到信息后不自动展示，需要用户自己选择相应的方法处理信息。
Content-Disposition字段也提供了一些参数。如文件名，文件的创建日期和修改日期等，使邮件客户端可以保存附件。 以下是一个示例。
Content-Disposition: attachment; filename=genome.jpeg;
modification-date="Wed, 12 Feb 1997 16:29:51 -0500";
尽管有些邮件客户端仅在Content-Type的参数中添加了文件名来通信，但这是不推荐的。正确的做法是在Content-Disposition中指定filename或是同时在Content-Type和Content-Disposition中指定name和filename的参数。在HTTP中Content-Disposition: attachment通常用来提示客户端将响应体作为下载文件，而不是在页面中展示它。filename参数是默认的下载文件名。
内容传输编码
（Content-Transfer-Encoding），这个区域使指定ASCII以外的文字编码方式成为可能。形式如下：
Content-Transfer-Encoding: [mechanism]
其中mechanism的值可以指定为“7bit”，“8bit”，“binary”，“quoted-printable”，“base64”。
7bit：7比特ASCII码。
8bit：8位ASCII码。
binary：Not only may non-ASCII characters be present but the lines are not necessarily short enough for SMTP transport.
quoted-printable：因为欧洲的一些文字和ASCII字符集中的某些字符有部分相同。如果邮件消息使用的是这些语言的话，与ASCII重叠的那些字符可以原样使用，ASCII字符集中不存在的字符采用形如“=??”的方法编码。这里“??”需要用将字符编码后的16进制数字来指定。采用quoted-printable编码的消息，长度不会变得太长，而且大部分都是ASCII中的字符，即使不通过解码也大致可以读懂消息的内容。
base64：这是一种将二进制的01序列转化成ASCII字符的编码方式。编码后的文字或者二进制消息，就可以运用SMTP等只支持ASCII字符的协议发送了。Base64一般被认为会平均增加33%的报文长度，而且，经过编码的消息对于人类来说是不可读的。
x-encodingname：这个值是预留的扩展。
内容标识符（可选）
内容描述（可选）
本文源自：互联网