The web standard is always MIME version 1.0

Introduction

There is no order without rules, and there is no network communication without standards. It is on the basis of various network protocols and standards that the popular Internet we have today is built. Today I will introduce to you a network standard format called MIME, which stands for Multipurpose Internet Mail Extensions.

Some people started to wonder, it turns out to be an extended protocol for email, so what does it have to do with the Internet we use?

Don’t worry, we’ll explain it slowly.

MIME in Detail

A long time ago, one of the popular applications of computers was sending emails. In the beginning, the only encoding method in the computer world was ASCII. However, as time went by and the demand for various applications increased dramatically, the ASCII format could no longer meet our needs. The multiple formats also caused difficulties in mutual communication, so a unified message format standard was created, which is MIME.

MIME allows emails to support not only ASCII but also other encoding methods, and supports multiple attachments such as pictures, audio, video, and applications.

The message body can also support a collection of multiple parts. When such a message email is encoded using the MIME format, it can be sent through standard email protocols such as SMTP, POP, IMAP, etc.

Because MIME is a standard, any email that complies with this standard can be parsed successfully.

Soon, MIME was widely used in the email world, but when the Internet had already developed to use the popular HTTP protocol to access the World Wide Web, the various content types defined in MIME naturally became the content standards used in other protocols.

This content type is defined in the MIME header. After the application receives the content type, it will use the corresponding application to parse the message content according to the message type specified in the type.

MIME Headers

The MIME header is very important and is the primary basis for applications to determine the message format. The MIME header can contain the following fields.

MIME-Version

If this header is present, it indicates that the message is in MIME format. Its value is usually 1.0.

 MIME - Version : 1.0

Some careful friends may ask, since there is 1.0, is there 1.1 or 2.0?

Sorry, the answer is no. According to Nathaniel Borenstein, co-creator of MIME, although the MIME version number was introduced to modify and upgrade MIME in the future, the MIME specification is not well designed for future MIME version upgrades, so different people may handle MIME version upgrades in different ways. As a result, it is difficult to upgrade the MIME specification today when MIME is widely used.

So, just use 1.0.

Content-Type

If you are familiar with the HTTP protocol, you should be familiar with this header. This header indicates the type of the message body, including type and subtype, for example:

 Content - Type : text / plain

The MIME type we often refer to is this tag.

The following are commonly used MIME types:

Content-Disposition

Content-Disposition is a field added in RFC 2183, which indicates the display style of the message. The previous message only defined its message format, but did not consider how the message was displayed, especially for emails.

For example, if an image is inserted into an email, is it displayed inline when we read the message? Or is it in the form of an attachment that the user must download before they can see it?

In the case of HTTP, the response header field Content-Disposition: attachment is usually used as a hint to the client to render the response body as a downloadable file. Typically, when receiving such a response, a web browser will prompt the user to save the content as a file instead of displaying it as a page in the browser window.

Content-Transfer-Encoding

What is this field used for?

As we know, with more and more data formats, traditional ASCII can no longer support a large number of content representations, so content representations beyond the scope of ASCII, such as Unicode, have emerged.

However, the SMTP server has a limited number of encodings that can be transmitted or recognized. If binary content is to be transmitted, it is necessary to use certain transfer encodings to convert the binary content. This is the meaning of Content-Transfer-Encoding.

According to the definitions of RFC and IANA, there are several transfer encodings:

For the specific meaning of transfer encodings, please refer to my subsequent articles. Here I will only give a brief introduction.

For ordinary SMTP servers, three encoding methods can be supported: 7bit, quoted-printable and base64.

For SMTP servers with 8BITMIME SMTP extension, 8bit encoding is also supported.

For SMTP servers that support the BINARYMIME SMTP extension, binary encoding is also supported.

Encoded-Word

According to RFC 2822, the field names and values ​​in the confirmation message header must use ASCII characters. If the message contains non-ASCII characters, it needs to be encoded. This encoding is encoded-word.

The encoding format is as follows:

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

charset indicates the encoding of the original message, encoding indicates the encoding method used, and encoded text is the encoded message.

Multipart messages

Finally, let's introduce Multipart messages. We know that a message has a corresponding message type: Content-Type.

If it is a complex message, then it may contain more than one message type. So at this time, you need to use Multipart messages, that is, divide the message into multiple parts, each part has a Content-Type.

This type is common in emails. The following is an example of Multipart messages, in which a message segmentation marker boundary is specified in Content-Type.

 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--