Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1061170
  • 博文数量: 321
  • 博客积分: 7872
  • 博客等级: 少将
  • 技术积分: 2120
  • 用 户 组: 普通用户
  • 注册时间: 2007-05-16 09:06
文章分类

全部博文(321)

文章存档

2017年(1)

2016年(1)

2015年(12)

2014年(17)

2013年(78)

2012年(15)

2011年(17)

2010年(67)

2009年(102)

2008年(11)

分类: LINUX

2009-11-13 12:29:04

MIME

维基百科,自由的百科全书

跳转到: 导航, 搜索
多用途互联网邮件扩展(MIME,Multipurpose Internet Mail Extensions)是一个互联网标准,它扩展了电子邮件标准,使其能够支持非ASCII字符、二进制格式附件等多种格式的邮件消息。这个标准被定义在RFC 2045、RFC 2046、RFC 2047、RFC 2048、RFC 2049等RFC中。 由RFC 822转变而来的RFC 2822,规定电子邮件标准并不允许在邮件消息中使用7位ASCII字符集以外的字符。正因如此,一些非英语字符消息和二进制文件,图像,声音等非文字消息都不能在电子邮件中传输。MIME规定了用于表示各种各样的数据类型的符号化方法。 此外,在万维网中使用的HTTP协议中也使用了MIME的框架。

[编辑] MIME headers
MIME是通过标准化电子邮件报文的头部的附加领域(fields)而实现的;这些头部的附加领域,描述新的报文类型的内容和组织形式。

[编辑] MIME版本
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:用于传输动态影像数据,可以是与音频编辑在一起的视频数据格式。
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图像)
image/png(PNG图像)
video/mpeg(MPEG动画)
application/octet-stream(任意的二进制数据)
application/pdf(PDF文档)
application/msword(Microsoft Word文件)
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-Transfer-Encoding),这个区域使指定ASCII以外的字符编码方式成为可能。形式如下:

  Content-Transfer-Encoding: [mechanism]

其中,mechanism的值可以指定为“7bit”,“8bit”,“binary”,“quoted-printable”,“base64”。

[编辑] 7bit
7bit这里指的是7位的ASCII编码方式。

[编辑] 8bit
8位元ASCII码。

[编辑] binary
[编辑] quoted-printable
因为欧洲的一些文字和ASCII字符集中的某些字符有部分相同。如果邮件消息使用的是这些语言的话,于ASCII重叠的那些字符可以原样使用,ASCII字符集中不存在的字符采用形如“=??”的方法编码。这里“??”需要用将字符编码后的16进制数字来指定。采用quoted-printable编码的消息,长度不会变得太长,而且大部分都是ASCII中的字符,即使不通过解码也大致可以读懂消息的内容。

[编辑] base64
base64是一种将二进制的01序列转化成ASCII字符的编码方法。编码后的文本或者二进制消息,就可以运用SMTP等只支持ASCII字符的协议传送了。Base64一般被认为会平均增加33%的报文长度,而且,经过编码的消息对于人类来说是不可读的。

[编辑] x-encodingname
这个值是预留的扩展。

[编辑] 内容标识符(可选)
[编辑] 内容描述(可选)
[编辑] 参见
SOAP with Attachments
S/MIME
Mailcap
Unicode与电子邮件
DIME—微软提议的一种技术,被称为DIME,是部分改变的MIME,最初应用于Web服务
[编辑] 参考
RFC 1847 
Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted
RFC 2045 
MIME Part One: Format of Internet Message Bodies.
RFC 2046 
MIME Part Two: Media Types. N. Freed, Nathaniel Borenstein。November 1996.
RFC 2047 
MIME Part Three: Message Header Extensions for Non-ASCII Text. Keith Moore。November 1996.
RFC 4288 
MIME Part Four: Media Type Specifications and Registration Procedures.
RFC 4289 
MIME Part Four: Registration Procedures. N. Freed, J. Klensin. December 2005.
RFC 2049 

MIME Part Five: Conformance Criteria and Examples. N. Freed, N. Borenstein. November 1996.
RFC 2231 
MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations. N. Freed, K. Moore. November 1997.
RFC 2387 
The MIME Multipart/Related Content-type
[编辑] 外部连接
MIME类型
MIME的使用
追踪互联网邮件草稿与标准的Blog
IANA已注册的MIME媒体类型列表
字符集列表
Debian Wiki上的MIME
MIME的更详细综述(1993年)

阅读(917) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~