12-MIME

12. 网络标准之:永远是1.0版本的MIME

简介

无规矩不成方圆,无标准不成网络通信。正是在各种网络协议和标准的基础之上,才构建了我们现在流行的互联网。今天给大家介绍的就是一个网络标准格式,叫做MIME,它的全称是Multipurpose Internet Mail Extensions,翻译过来就是多用途Internet邮件扩展。

那么有小伙伴开始疑惑了,原来是一个邮件的扩展协议,那么它跟我们使用的Internet网络有什么关系呢?

不急,我们慢慢道来。

MIME详解

在很久很久以前,计算机的一种流行的应用就是发邮件,最开始的时候,计算机世界的编码方式就只有ASCII一种,但是随着时间的推移和各种应用需求的激增,ASCII格式已经不能满足我们的需求了,格式多类型的同时也照成了互相通信之间的困难,于是一个统一的消息格式标准产生了,这个就是MIME。

MIME可以让邮件不仅支持ASCII,还可以支持其他的编码方式。同时支持图片、音频、视频和应用程序等多种附件。

消息体还可以支持多个part的集合,当这样的消息邮件使用MIME格式编码之后,就可以通过标准的邮件协议,比如SMTP、POP、IMAP等进行发送了。

因为MIME是一个标准,所以只要符合这种标准的邮件都能够被解析成功。

很快,MIME就在邮件世界被广泛应用,但是互联网已经发展到使用流行的HTTP协议来访问万维网的时候了,MIME中定义的各种content types很自然的也成了其他协议中使用的content标准。

这种content types是在MIME头中定义的,应用程序接收到content type之后,会根据类型中指定的消息类型,来采用对应的应用程序对消息内容进行解析。

MIME头

MIME头很重要,是应用程序用来判断消息格式的首要依据。MIME头可以包含下面的字段。

MIME-Version

如果存在这个消息头,说明这个消息是遵循的是MIME格式。它的值通常是1.0。

MIME-Version: 1.0

有细心的小伙伴可以能要问了,既然有1.0,那么有没有1.1或者2.0呢?

很抱歉,答案是没有。因为根据MIME 共同创建者 Nathaniel Borenstein 的说法,虽然引入MIME版本号是为了在后续中对MIME进行修改和升级。但是因为MIME规范并没有为未来MIME版本的升级进行良好的设计,所以不同的人可能对MIME版本升级后的处理方式都是不一样的。从而导致在MIME广泛应用的今天,很难对MIME规范进行升级。

所以,就使用1.0吧。

Content-Type

如果属性HTTP协议的同学,对这个头应该很熟悉了吧,这个头表示的是消息体的类型,包含了类型和子类型,比如:

Content-Type: text/plain

我们常说的MIME type就是指这个标签。

下面是常用的MIME type:

说明后缀类型

超文本标记语言文本

.html

text/html

xml文档

.xml

text/xml

XHTML文档

.xhtml

application/xhtml+xml

普通文本

.txt

text/plain

RTF文本

.rtf

application/rtf

PDF文档

.pdf

application/pdf

Microsoft Word文件

.word

application/msword

PNG图像

.png

image/png

GIF图形

.gif

image/gif

JPEG图形

.jpeg,.jpg

image/jpeg

au声音文件

.au

audio/basic

MIDI音乐文件

mid,.midi

audio/midi,audio/x-midi

RealAudio音乐文件

.ra, .ram

audio/x-pn-realaudio

MPEG文件

.mpg,.mpeg

video/mpeg

AVI文件

.avi

video/x-msvideo

GZIP文件

.gz

application/x-gzip

TAR文件

.tar

application/x-tar

任意的二进制数据

application/octet-stream

Content-Disposition

Content-Disposition是在RFC 2183中添加的一个字段,表示的是消息的展示样式。因为之前的消息只是定义了它的消息格式,并没有考虑消息是如何展示的问题,尤其是对于邮件来说。

比如邮件中插入了一个图片,那么这个图片是在我们读消息的时候内联展示呢?还是以附件的形式,必须要用户下载才能看到呢?

如果是在HTTP中,响应头字段Content-Disposition:attachment 通常用作提示客户端将响应正文呈现为可下载文件。通常,当收到这样的响应时,Web浏览器会提示用户将其内容保存为文件,而不是将其显示为浏览器窗口中的页面。

Content-Transfer-Encoding

这个字段是做什么用的呢?

我们知道,随着数据格式越来越多,传统的ASCII已经不能支持庞大的内容表示形式,所以出现了超出ASCII范围的内容表示形式如Unicode。

但是对于SMTP服务器来说,能够传输或者认识的编码是有限的,如果要传输二进制内容,则需要使用一定的transfer encodings方式对二进制内容进行转换。这就是Content-Transfer-Encoding的意义。

根据RFC和IANA的定义,有下面几个transfer encodings方式:

NameReference

7bit

[RFC2045]

8bit

[RFC2045]

binary

[RFC2045]

quoted-printable

[RFC2045]

base64

[RFC2045]

具体transfer encodings的含义,可以参考我后续的文章,这里只做简单的介绍。

对于普通的SMTP服务器来说,可以支持7bit、quoted-printable和base64这三种编码方式。

对于8BITMIME SMTP extension的SMTP服务器来说,还支持8bit这种编码方式。

对于支持BINARYMIME SMTP extension的SMTP服务器来说,还支持binary这种编码方式。

Encoded-Word

根据RFC 2822,确认消息头中的字段名和值必须使用ASCII字符。如果消息中包含非ASCII字符,则需要进行编码。这个编码就是encoded-word 。

编码的格式如下:

"=?charset?encoding?encoded text?=".

charset表示的是原消息的编码,encoding表示的是使用的编码方式,encoded text是编码后的消息。

Multipart messages

最后,介绍一下Multipart messages,我们知道一个消息是有对应的消息类型:Content-Type的。

如果是复杂的消息,那么它里面的消息类型可能不止一种。所以这时候就需要用到Multipart messages,也就是将消息分为多个部分,每个部分都有一个Content-Type。

这种类型在邮件中比较常见。下面是一个Multipart messages的例子,在Content-Type中指定了一个消息的分割标记boundary。

MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=frontier

This is a message with multiple parts in MIME format.
--frontier
Content-Type: text/plain

This is the body of the message.
--frontier
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64

PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg
Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg==
--frontier--

总结

以上就是MIME的基本介绍,在其中,我们提到了几种transfer encodings方法,敬请期待后续文章。

最后更新于