MIME TYPE

什么是 MIME TYPE？

MIME(Multipurpose Internet Mail Extensions)多用途互联网邮件扩展类型。是设定某种 扩展名的 文件用一种 应用程序来打开的方式类型，当该扩展名文件被访问的时候， 浏览器会自动使用指定应用程序来打开。多用于指定一些 客户端 自定义的 文件名，以及一些媒体文件打开方式。

它是一个互联网标准，扩展了电子邮件标准，使其能够支持：

非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的框架，标准被扩展为互联网媒体类型。

一、

首先，我们要了解浏览器是如何处理内容的。在浏览器中显示的内容有 HTML、有 XML、有 GIF、还有 Flash ……那么，浏览器是如何区分它们，决定什么内容用什么形式来显示呢？答案是 MIME Type，也就是该资源的媒体类型。

媒体类型通常是通过 HTTP 协议，由 Web 服务器告知浏览器的，更准确地说，是通过 Content-Type 来表示的，例如:

Content-Type: text/HTML


表示内容是 text/HTML 类型，也就是超文本文件。为什么是“text/HTML”而不是“HTML/text”或者别的什么？MIME Type 不是个人指定的，是经过 ietf 组织协商，以 RFC 的形式作为建议的标准发布在网上的，大多数的 Web 服务器和用户代理都会支持这个规范 (顺便说一句，Email 附件的类型也是通过 MIME Type 指定的)。

通常只有一些在互联网上获得广泛应用的格式才会获得一个 MIME Type，如果是某个客户端自己定义的格式，一般只能以 application/x- 开头。

XHTML 正是一个获得广泛应用的格式，因此，在 RFC 3236 中，说明了 XHTML 格式文件的 MIME Type 应该是 application/xHTML+XML。

当然，处理本地的文件，在没有人告诉浏览器某个文件的 MIME Type 的情况下，浏览器也会做一些默认的处理，这可能和你在操作系统中给文件配置的 MIME Type 有关。比如在 Windows 下，打开注册表的“HKEY_LOCAL_MACHINESOFTWAREClassesMIMEDatabaseContent Type”主键，你可以看到所有 MIME Type 的配置信息。

 

二、

在把输出结果传送到浏览器上的时候，浏览器必须启动适当的应用程序来处理这个输出文档。这可以通过多种类型MIME（多功能网际邮件扩充协议）来完成。在HTTP中，MIME类型被定义在Content-Type header中。

例如，架设你要传送一个Microsoft Excel文件到客户端。那么这时的MIME类型就是“application/vnd.ms-excel”。在大多数实际情况中，这个文件然后将传送给Execl来处理（假设我们设定Execl为处理特殊MIME类型的应用程序）。在ASP中，设定MIME类型的方法是通过Response对象的ContentType属性。


多媒体文件格式MIME 

最早的HTTP协议中，并没有附加的数据类型信息，所有传送的数据都被客户程序解释为超文本标记语言HTML 文档，而为了支持多媒体数据类型，HTTP协议中就使用了附加在文档之前的MIME数据类型信息来标识数据类型。

MIME意为多目Internet邮件扩展，它设计的最初目的是为了在发送电子邮件时附加多媒体数据，让邮件客户程序能根据其类型进行处理。然而当它被HTTP协议支持之后，它的意义就更为显著了。它使得HTTP传输的不仅是普通的文本，而变得丰富多彩。

每个MIME类型由两部分组成，前面是数据的大类别，例如声音audio、图象image等，后面定义具体的种类。

常见的MIME类型

超文本标记语言文本 .html,.html text/html 
普通文本 .txt text/plain 
RTF文本 .rtf application/rtf 
GIF图形 .gif image/gif 
JPEG图形 .ipeg,.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 

Internet中有一个专门组织IANA来确认标准的MIME类型，但Internet发展的太快，很多应用程序等不及IANA来确认他们使用的MIME类型为标准类型。因此他们使用在类别中以x-开头的方法标识这个类别还没有成为标准，例如：x-gzip，x-tar等。事实上这些类型运用的很广泛，已经成为了事实标准。只要客户机和服务器共同承认这个MIME类型，即使它是不标准的类型也没有关系，客户程序就能根据MIME类型，采用具体的处理手段来处理数据。而Web服务器和浏览器（包括操作系统）中，缺省都设置了标准的和常见的MIME类型，只有对于不常见的 MIME类型，才需要同时设置服务器和客户浏览器，以进行识别。

由于MIME类型与文档的后缀相关，因此服务器使用文档的后缀来区分不同文件的MIME类型，服务器中必须定义文档后缀和MIME类型之间的对应关系。而客户程序从服务器上接收数据的时候，它只是从服务器接受数据流，并不了解文档的名字，因此服务器必须使用附加信息来告诉客户程序数据的MIME类型。服务器在发送真正的数据之前，就要先发送标志数据的MIME类型的信息，这个信息使用Content-type关键字进行定义，例如对于HTML文档，服务器将首先发送以下两行MIME标识信息,这个标识并不是真正的数据文件的一部分。

Content-type: text/html

注意，第二行为一个空行，这是必须的，使用这个空行的目的是将MIME信息与真正的数据内容分隔开。

MIME (Multipurpose Internet Mail Extensions) 是描述消息内容类型的因特网标准。
MIME 消息能包含文本、图像、音频、视频以及其他应用程序专用的数据。
官方的 MIME 信息是由 Internet Engineering Task Force (IETF) 在下面的文档中提供的：
RFC-822 Standard for ARPA Internet text messages

RFC-2045 MIME Part 1: Format of Internet Message Bodies

RFC-2046 MIME Part 2: Media Types

RFC-2047 MIME Part 3: Header Extensions for Non-ASCII Text

RFC-2048 MIME Part 4: Registration Procedures

RFC-2049 MIME Part 5: Conformance Criteria and Examples

不同的应用程序支持不同的 MIME 类型。

背景介绍

多用途互联网邮件扩展，它是一个互联网标准，在1992年最早应用于 电子邮件系统，但后来也应用到 浏览器。 服务器会将它们发送的多媒体数据的类型告诉 浏览器，而通知手段就是说明该多媒体数据的MIME类型，从而让浏览器知道接收到的信息哪些是MP3 文件，哪些是Shockwave文件等等。 服务器将MIME标志符放入传送的数据中来告诉 浏览器使用哪种 插件读取相关 文件。

MIME能够支持非ASCII 字符、二进制格式附件等多种格式的邮件消息。这个标准被定义在RFC 2045，RFC 2046，RFC 2047，RFC 2048，RFC 2049等RFC中。 由 RFC 822转变而来的RFC 2822，规定 电子邮件标准并不允许在邮件消息中使用7位ASCII 字符集以外的字符。正因如此，一些非英语字符消息和 二进制文件，图像，声音等非文字消息都不能在 电子邮件中传输。MIME规定了用于表示各种各样的数据类型的符号化方法。

浏览器接收到 文件后，会进入 插件系统进行查找，查找出哪种插件可以识别读取接收到的文件。如果 浏览器不清楚调用哪种 插件系统，它可能会告诉用户缺少某插件，或者直接选择某现有插件来试图读取接收到的 文件，或者可能会导致系统的崩溃。传输的信息中缺少MIME标识可能导致的情况很难估计，因为某些 计算机系统可能不会出现什么故障，但某些计算机可能就会因此而崩溃。

检查一个 服务器是否正确设置了MIME类型的步骤是：

1. 在 Netscape浏览器中打开 服务器网页。
2. 进入"Tools"菜单，选择"Page Info"。
3. 在弹出的窗口中点击上层框架中的"EMBED"。

在下层框架中查看MIME的类型是否为"application/x-director"或"application/x-shockwave-flash"，如果是上述信息的话表明 服务器已经正确设置了MIME类型；而如果MIME类型列出的是文本内容、八位一组的数据或是其它形式均表明服务器的MIME类型没有设置正确。

如果 服务器没有正确标明其发送的数据的类型，服务器管理员应该正确添加相关信息，具体操作方法非常简单快捷。

Microsoft公司应用于Windows系统下的 浏览器使用 ActiveX控件，而不是Netscape 插件，这种浏览器不必象其它浏览器那样依靠MIME的编码。"OBJECT"标签的"CLSID"属性准确地标明了应调用哪种程序来读取接收到的 文件，因此浏览器不必象"EMBED"标签那样选择一种读取程序。正因为如此，你往往会在使用带 插件的 浏览器时遇到MIME问题，而使用ActiveX控件的浏览器则很少出现此类麻烦。

正由于上述工作方式的差别也解释了一种现象，不知你是否发现在使用Netscape 浏览器播放WAV 文件时，浏览器会调用LiveConnect 插件进行播放，而其它浏览器一般都使用通用的QuickTime的播放插件等来进行播放，这是因为Netscape浏览器接收文件需要读取MIME标识符，以便决定调用哪种程序来读取接收的文件，而 服务器设置在Netscape浏览器中播放WAV文件应使用LiveConnect插件，因此Netscape浏览器接收到WAV格式的文件时必然就会调用LiveConnect插件，但由于其它浏览器不使用这种方式，因此它们都使用系统默认的播放WAV格式文件的播放器。当然Flash电影 文件并不存在这种问题，因为只有Flash播放器才能够正确读取这种格式的文件。

在把输出结果传送到浏览器上的时候，浏览器必须启动适当的 应用程序来处理这个输出文档。这可以通过多种类型MIME（多功能网际邮件扩充协议）来完成。在HTTP中，MIME类型被定义在Content-Type header中。

例如，假设你要传送一个Microsoft Excel文件到 客户端。那么这时的MIME类型就是“excel”。在大多数实际情况中，这个 文件然后将传送给Excel来处理（假设我们设定Excel为处理特殊MIME类型的 应用程序）。在ASP中，设定MIME类型的方法是通过 Response对象的ContentType属性。

文件格式

最早的 HTTP协议中，并没有附加的 数据类型信息，所有传送的数据都被客户程序解释为 超文本标记语言HTML 文档，而为了支持多媒体数据类型，HTTP协议中就使用了附加在文档之前的MIME数据类型信息来标识数据类型。

MIME意为多功能Internet邮件扩展，它设计的最初目的是为了在发送 电子邮件时附加多媒体数据，让邮件客户程序能根据其类型进行处理。然而当它被HTTP协议支持之后，它的意义就更为显著了。它使得HTTP传输的不仅是普通的文本，而变得丰富多彩。

每个MIME类型由两部分组成，前面是数据的大类别，例如声音audio、图象image等，后面定义具体的种类。

常见的MIME类型(通用型)：

超文本标记语言文本 .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

用于 WAP 服务器 的MIME类型有：
MRP文件（国内普遍的手机）	.mrp application/octet-stream
IPA文件( IPHONE)	.ipa application/iphone-package-archive
	.deb application/x-debian-package-archive
APK文件( 安卓系统)	.apk application/vnd.android.package-archive
CAB文件( Windows Mobile)	.cab application/vnd.cab-com-archive
XAP文件( Windows Phone 7)	.xap application/x-silverlight-app
SIS文件( symbian平台/S60V1)	.sis application/vnd.symbian.install-archive *（下有）
SISX文件(symbian平台/S60V3/V5)	.sisx application/vnd.symbian.epoc/x-sisx-app
JAR、JAD文件( JAVA平台手机通用格式)	.jar .jad下面有

Internet中有一个专门组织IANA来确认标准的MIME类型，但Internet发展的太快，很多 应用程序等不及IANA来确认他们使用的MIME类型为标准类型。因此他们使用在类别中以x-开头的方法标识这个类别还没有成为标准，例如： x-gzip，x-tar等。事实上这些类型运用的很广泛，已经成为了事实标准。只要客户机和 服务器共同承认这个MIME类型，即使它是不标准的类型也没有关系，客户程序就能根据MIME类型，采用具体的处理手段来处理数据。而Web 服务器和 浏览器（包括 操作系统）中，缺省都设置了标准的和常见的MIME类型，只有对于不常见的 MIME类型，才需要同时设置 服务器和客户浏览器，以进行识别。

由于MIME类型与文档的后缀相关，因此 服务器使用文档的后缀来区分不同 文件的MIME类型，服务器中必须定义文档后缀和MIME类型之间的对应关系。而客户程序从 服务器上接收数据的时候，它只是从服务器接受数据流，并不了解文档的名字，因此服务器必须使用附加信息来告诉客户程序数据的MIME类型。 服务器在发送真正的数据之前，就要先发送标志数据的MIME类型的信息，这个信息使用Content-type 关键字进行定义，例如对于HTML文档，服务器将首先发送以下两行MIME标识信息,这个标识并不是真正的数据 文件的一部分。

Content-type: text/html

注意，第二行为一个空行，这是必须的，使用这个空行的目的是将MIME信息与真正的数据内容分隔开。

MIME利用了一个事实就是，RFC 822在消息体的内容中做了一点限制：唯一的限制就是只能使用简单的ASCII文本。所以，MIME信息由正常的Internet文本邮件组成，文本邮件拥有一些特别的符合RFC 822的信息头和格式化过的信息体（用ASCII 的子集来表示的附件）。这些MIME头给出了一种在 邮件中表示附件的特别的方法。

信息剖析

一个普通的文本邮件的信息包含一个头部分（To: From: Subject: 等等）和一个体部分（Hello Mr.,等等）。在一个符合MIME的信息中，也包含一个信息头并不奇怪，邮件的各个部分叫做MIME段，每段前也缀以一个特别的头。MIME邮件只是基于RFC 822邮件的一个扩展，然而它有着自己的RFC规范集。

头字段

MIME头根据在邮件包中的位置，大体上分为MIME信息头和MIME段头。（译者：MIME信息头指整个邮件的头，而MIME段头只每个MIME段的头。）

MIME信息头有：

MIME-Version:

这个头提供了所用MIME的版本号。这个值习惯上为1.0。

Content-Type:

它定义了数据的类型，以便数据能被适当的处理。有效的类型有：text，image，audio，video，applications，multipart和message。注意任何一个二进制附件都应该被叫做application/octet- stream。这个头的一些用例为：image/jpg, application/mswork，multipart/mixed，这只是很少的一部分。

Content-Transfer-Encoding:

这是所有头中最重要的一个，因为它说明了对数据所执行的编码方式，客户/MUA 将用它对附件进行解码。对于每个附件，可以使用7bit，8bit，binary ，quoted-printable， base64和custom中的一种编码方式。7bit编码是用在US ASCII 字符集上的常用的一种编码方式，也就是，保持它的原样。8bit和binary编码一般不用。对人类可读的标准文本，如果传输要经过对格式有影响的 网关时对其进行保护，可以使用quoted printable 。Base64是一种通用方法，在需要决定使用哪一种编码方法时，它提供了一个不用费脑子的选择；它通常用在二进制，非文本数据上。注意，任何非7bit 数据必须用一种模式编码，这样它就可以通过Internet 邮件网关！

Content-ID:

如果Content-Type是message/external-body或multipart/alternative时，这个头就有用了，它超出了本文的范围。

Content-Description:

这是一个可选的头。它是任何信息段内容的自由文本描述。描述必须使用us-ascii码。

Content-Disposition:

一个试验性的头，它用于给客户程序/MUA提供提示，来决定是否在行内显示附件或作为单独的附件。

MIME段头（出现在实际的MIME附件部分的头），除了MIME-Version头，可以拥有以上任何头字段。如果一个MIME头是信息块的一部分，它将作用于整个信息体。例如，如果Content-Transfer-Encoding显示在信息（指整个信息）头中，它应用于整个信息体，但是如果它显示在一个MIME段里，它"只能"用于那个段中。

注意：其可以对自动对收到的 邮件进行解密。