名词1

Posted

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了名词1相关的知识，希望对你有一定的参考价值。

1。MIME

多用途互联网邮件扩展（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的框架，标准被扩展为互联网媒体类型。

 

 

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图像）【php中为：image/pjpeg】
  • image/png（PNG图像）【PHP中为：image/x-png】
  • video/mpeg（MPEG动画）
  • application/octet-stream（任意的二进制数据）
  • application/pdf（PDF文档）
  • application/msword（Microsoft Word文件）
  • 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-Transfer-Encoding），这个区域使指定ASCII以外的字符编码方式成为可能。形式如下：

  Content-Transfer-Encoding: [mechanism]

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

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[编辑]

这个值是预留的扩展。

内容标识符（可选）[编辑]

内容描述（可选）[编辑]

参见[编辑]

参考[编辑]

 
备注
RFC 1426 
SMTP Service Extension for 8bit-MIMEtransport. J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker. February 1993.
RFC 1847 
Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted
RFC 3156 
MIME Security with OpenPGP
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 2183 
Communicating Presentation Information in Internet Messages: The Content-Disposition Header. Troost, R., Dorner, S. and K. Moore. August 1997.
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
RFC 1521 
Mechanisms for Specifying and Describing the Format of Internet Message Bodies

外部链接[编辑]

 

 

互联网媒体类型（Internet media type，也称为MIME类型（MIME type）或内容类型（content type））是给互联网上传输的内容赋予的分类类型。一份内容的互联网媒体类型是由其文件格式与内容决定的。互联网媒体类型与文件拓展名相对应，因此计算机系统常常通过拓展名来确定一个文件的媒体类型并决定与其相关联的软件。互联网媒体类型的分类标准由互联网号码分配局（IANA）发布。1996年十一月，媒体类型在RFC 2045中被最初定义，当时仅被使用在SMTP协议的电子邮件中。现在其他的协议（比如HTTP或者SIP）也都常使用MIME类型。 一个MIME类型至少包括两个部分：一个类型（type）和一个子类型（subtype）。此外，它还可能包括一个或多个可选参数（optional parameter）。比如，HTML文件的互联网媒体类型可能是

text/html; charset = UTF-8

在这个例子中，文件类型为text，子类型为html，而charset是一个可选参数，其值为UTF-8。

 

 

命名格式[编辑]

一个MIME类型包括一个类型（type），一个子类型（subtype）。此外可以加上一个或多个可选参数（optional parameter）。其格式为

类型名 / 子类型名 [ ; 可选参数 ]

目前已被注册的类型名有application、audio、example、image、message、model、multipart、text，以及video。chemical是一个非官方的常用类型名。[1]此外，非标准的类型名一般会加上x-前缀，但这种做法已经过时。[2]

子类型名通常是一个媒体形式被冠以的名称，不过子类型名中也会有其它信息，包括厂商信息、产品信息、分类信息（子类型会被归进一个树状的分类结构中）、后缀等等。树结构分类信息以被.相互连接的字符串表示。每一个由.分隔开的部分又可以加上与其以-相连接的附加信息。此外，子类型名中也会有放在最后，与前面的内容以+相连接的后缀。因此，一个媒体类型的格式可以被更加细地表示为：

类型名 / [ 树结构分类信息（中间可能有一个或多个“.”） ] 子类型名（中间可能有一个或多个“-”） [ + 后缀 ] [ ; 可选参数 ]

这些信息遵循注册树（见下）的规定。

注册树（Registration Tree）[编辑]

所有的媒体类型都是通过IANA的流程注册的。为了保证注册流程的灵活性与效率，子类型被归进了一个树结构的分类中。树结构信息被放在了子类型名的最前面，以.与其它部分分隔。现在，存在以下几种树：标准树（Standards Tree）、厂商树（Vendor Tree）、个人树（Personal or Vanity Tree）、以及非标准的x.为前缀的树。这些树最早于1996年十一月随着RFC 2048被定义出来。IETF标准行动（Standard Action）可能会创造新的注册树以满足著名的持续性组织（比如科学社区）的注册和管理需求。

标准树[编辑]

标准树中的子类型名不需要树结构信息（也就是不需要带.的前缀）。[3]

类型名 / 子类型名 [ + 后缀 ] [ ; 可选参数 ]

要注册标准树中的子类型，其必须遵从IESG直接批准的IETF规范，或者被由IANA认证的标准相关组织注册。

厂商树[编辑]

厂商树中包含与公开使用的产品相联系的媒体类型。其使用vnd.前缀。在前缀之后必须是著名厂商的名称或是IANA认证厂商的名称加上表示文件类型和/或内容的文字。

类型名 / vnd.子类型名 [ + 后缀 ] [ ; 可选参数 ]

比如与Debian项目组织提供的dpkg相关联的.deb文件的MIME类型是：

application/vnd.debian.binary-package

其中，debian是厂商（生产方）名称，而binary-package是对文件类型和内容的描述。

“厂商”与“生产方”在这个语境下是相同的概念。工业财团和非盈利组织也可以注册厂商树中的媒体类型。任何想要传播与某种软件紧密联系的文件格式的人都可以注册厂商树中的子类型，但是这个子类型是属于该软件或是文件格式的生产方的。这种情况下，厂商可以选择在任何时间声明自己拥有第三方进行的注册的所有权。[3]

个人树[编辑]

个人树中包含试验性或者不会以商业形式公开的子类型。个人树中的子类型名的前缀是prs.

类型名 / prs.子类型名 [ + 后缀 ] [ ; 可选参数 ]

个人树中的子类型属注册者所有，但也可以转让。[3]

未注册的x.树[编辑]

以x.为第一前缀的子类型名仅能够在私人的、本地的环境中使用。此类型的子类型不能被注册。其只能在相互间同意的各方中传输使用。尽管有时未被注册的MIME类型必须被使用，这是不被推荐的。

类型名 / x.子类型名 [ + 后缀 ] [ ; 可选参数 ]

带有x-的子类型名原先被归到这颗树中，但是这种做法已经不被采用。[2]如果一个带有x-前缀的子类型名被广泛使用和接受，其可能最终会被注册并且归进其它树中[3]，尽管x-本身已经过时。[2]

媒体类型列表[编辑]

IANA维护着一个媒体类型和字符编码的记录列表。他们的列表通过互联网向公众开放。

Type application[编辑]

分别对于不同用途的文件：

  • application/atom+xml：Atom feeds
  • application/ecmascript：ECMAScript/JavaScript;[4]（相当于application/javascript但是严格的处理规则）
  • application/EDI-X12：EDI ANSI ASC X12数据[5]
  • application/EDIFACT：EDI EDIFACT数据[5]
  • application/json：JSON（JavaScript Object Notation）[6]
  • application/javascript：ECMAScript/JavaScript[4]（相当于application/ecmascript但是宽松的处理规则）它不被IE 8或更早之前的版本所支持。虽然可以改用text/javascript，但它却被RFC 4329定义为过时。在HTML5之中，<script>标签的type的属性是可省略的，因为所有的浏览器即使在HTML5以前都一直默认使用JavaScript。
  • application/octet-stream:任意的二进制文件（通常做为通知浏览器下载文件）[7] Generally speaking this type identifies files that are not associated with a specific application. Contrary to past assumptions by software packages such as Apache this is not a type that should be applied to unknown files. In such a case, a server or application should not indicate a content type, as it may be incorrect, but rather, should omit the type in order to allow the recipient to guess the type.[8]
  • application/ogg：Ogg, 视频文件格式[9]
  • application/pdf：PDF（Portable Document Format）[10]
  • application/postscript：PostScript[7]
  • application/rdf+xml：Resource Description Framework[11]
  • application/rss+xml：RSS feeds
  • application/soap+xml：SOAP[12]
  • application/font-woff：Web Open Font Format;（推荐使用；使用application/x-font-woff直到它变为官方标准）
  • application/xhtml+xml：XHTML[13]
  • application/xml：XML文件[14]
  • application/xml-dtd：DTD文件[14]
  • application/xop+xml：XML-binary Optimized Packaging[15]
  • application/zip：ZIP压缩档[16]
  • application/gzip：Gzip[17]

Type audio[编辑]

数字音频文件：

Type image[编辑]

图像文件：

Type message[编辑]

Type model[编辑]

三维计算机图形文件：

Type multipart[编辑]

Type text[编辑]

  • text/css：CSS文件[29]
  • text/csv：CSV文件[30]
  • text/html：HTML文件[31]
  • text/javascript (过时): JavaScript; 在 RFC 4329 中定义并舍弃，以减少使用，并有利于 application/javascript。然而，相比于 application/javascript ，在 HTML 4 和 5 中，可以使用text/javascript ，且有跨浏览器的支持。因为在使用 <script> 时，对于其 "type" 属性 ，所有浏览器都假设会使用正确的默认值（尽管 HTML 4 的规格中明确要求），所以 HTML 5 中定义为选择性的，且没必要。。
  • text/plain:纯文字内容[32]
  • text/vcard：vCard（电子名片）[33]
  • text/xml：XML[14]

Type video[编辑]

视频文件格式文件（可能包含数字视频与数字音频）：

媒体子类型列表[编辑]

vnd前置[编辑]

x前置[编辑]

x-pkcs前置[编辑]

参考文献[编辑]

  1. 跳转^ Leidert, L.; Willighagen, E. The chemical-mime-data project. 2007 [2016-04-28].
  2. ^ 跳转至：2.0 2.1 2.2 Saint-Andre, P.; Crocker, D.; Nottingham, M. Deprecating the "X-" Prefix and Similar Constructs in Application Protocols. Internet Engineering Task Force (IETF). June 2012. 2070-1721 ISSN ISSN: 2070-1721 请检查|issn=值 (帮助).
  3. ^ 跳转至：3.0 3.1 3.2 3.3 Freed, N.; Klensin, J.; Hansen, T. Media Type Specifications and Registration Procedures. Internet Engineering Task Force (IETF). [2015-07-15]. ISSN 2070-1721 （英语）.
  4. ^ 跳转至：4.0 4.1 RFC 4329 - Scripting Media Types
  5. ^ 跳转至：5.0 5.1 RFC 1767 - MIME Encapsulation of EDI Objects
  6. 跳转^ RFC 4627 -The application/json Media Type for JavaScript Object Notation（JSON）
  7. ^ 跳转至：7.0 7.1 RFC 2046 - Multipurpose Internet Mail Extensions (MIME) Part Two: Media types
  8. 跳转^ W3C. RFC 2616: 7. Entity. Hypertext Transfer Protocol -- HTTP/1.1. The Internet Society. June 1999 [28 May 2012].
  9. ^ 跳转至：9.0 9.1 9.2 RFC 5334 - Ogg Media Types
  10. 跳转^ RFC 3778 - The application/pdf Media Type
  11. 跳转^ RFC 3870 - application/rdf+xml Media Type Registration
  12. 跳转^ RFC 3902 - The "application/soap+xml" media type
  13. 跳转^ RFC 3236 - The ‘application/xhtml+xml‘ Media Type
  14. ^ 跳转至：14.0 14.1 14.2 RFC 3023 - XML Media Types
  15. 跳转^ XML-binary Optimized Packaging
  16. 跳转^ MIME SUBTYPE NAME: zip
  17. 跳转^ RFC 6713 - The ‘application/zlib‘ and ‘application/gzip‘ Media Types
  18. 跳转^ RFC 4337 -MIME Type Registration for MPEG-4
  19. 跳转^ RFC 3003 - The audio/mpeg Media Type
  20. 跳转^ RFC 5215 - RTP Payload Format for Vorbis Encoded Audio
  21. 跳转^ Supported Media Formats. RealPlayer Help. RealNetworks. 2010 [28 May 2012].
  22. 跳转^ RFC 2361 - WAVE and AVI Codec Registries
  23. ^ 跳转至：23.0 23.1 RFC 2045, RFC 2046 - Multipurpose Internet Mail Extensions (MIME), parts 1 and 2
  24. 跳转^ RFC 2083 - PNG (Portable Network Graphics) Specification - Version 1.0
  25. 跳转^ SVG Tiny 1.2 Specification Appendix M
  26. 跳转^ RFC 3302 - Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration
  27. 跳转^ RFC 4735 - Example Media Types for Use in Documentation
  28. ^ 跳转至：28.0 28.1 28.2 RFC 2077 - The Model Primary Content Type for Multipurpose Internet Mail Extensions
  29. 跳转^ RFC 2318 - The text/css Media Type
  30. 跳转^ RFC 4180 - Common Format and MIME Type for Comma-Separated Values (CSV) Files
  31. 跳转^ RFC 2854 - The ‘text/html‘ Media Type
  32. 跳转^ RFC 2046与RFC 3676
  33. 跳转^ RFC 6350 - vCard Format Specification
  34. 跳转^ RFC 2045与RFC 2046
  35. 跳转^ RFC 4337 - MIME Type Registration for MPEG-4
  36. 跳转^ Quicktime
  37. 跳转^ Microsoft KB 288102

以上是关于名词1的主要内容，如果未能解决你的问题，请参考以下文章

构建名词解释

vs 2010代码片段

vs 2010代码片段

Nginx配置文件详细介绍

1 代码片段1

sublime text3 增加代码片段(snipper)