Network Standard: Always MIME Version 1.0

Introduction

Without rules, there is no circle, and without standards, there is no network communication. It is on the basis of various network protocols and standards that our current popular Internet is constructed. What I will introduce to you today is a network standard format called MIME. Its full name is Multipurpose Internet Mail Extensions, which translates to Multipurpose Internet Mail Extensions.

Then some friends began to wonder, it turned out to be an extension protocol of mail, so what does it have to do with the Internet network we use?

Don't worry, we'll take it slow.

MIME details

A long, long time ago, a popular application of computers was sending emails. At the beginning, the encoding method in the computer world was only ASCII, but with the passage of time and the surge in various application requirements, the ASCII format has To meet our needs, the multiple types of formats also make it difficult to communicate with each other, so a unified message format standard was produced, which is MIME.

MIME allows mail to support not only ASCII, but other encodings as well. Supports multiple attachments such as pictures, audio, video, and applications at the same time.

The message body can also support a collection of multiple parts. When such message emails are encoded in MIME format, they can be sent through standard email protocols, such as SMTP, POP, and IMAP.

Because MIME is a standard, any mail that conforms to this standard can be parsed successfully.

Soon, MIME was widely used in the mail world, but the Internet had developed to the time when the popular HTTP protocol was used to access the World Wide Web, and the various content types defined in MIME naturally became the content standard 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 header

The MIME header is very important and is the primary basis for the application to judge the format of the message. MIME headers can contain the following fields.

MIME-Version

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

MIME-Version: 1.0

Careful friends may want to ask, since there is 1.0, is there 1.1 or 2.0?

Sorry, the answer is no. Because according to MIME co-creator Nathaniel Borenstein, although MIME version numbers are introduced to modify and upgrade MIME in the future. But because the MIME specification is not well designed for future MIME version upgrades, different people may handle MIME version upgrades differently. As a result, it is difficult to upgrade the MIME specification when MIME is widely used today.

So, just use 1.0.

Content-Type

If you are a student of the attribute HTTP protocol, you should be familiar with this header. This header represents the type of the message body, including types and subtypes, such as:

Content-Type: text/plain

The MIME type we often say refers to this tag.

The following are commonly used MIME types:

illustrate	suffix	Types of
hypertext markup language text	.html	text/html
xml document	.xml	text/xml
XHTML documents	.xhtml	application/xhtml+xml
normal text	.txt	text/plain
RTF text	.rtf	application/rtf
PDF document	.pdf	application/pdf
Microsoft Word file	.word	application/msword
PNG images	.png	image/png
GIF graphics	.gif	image/gif
JPEG graphics	.jpeg,.jpg	image/jpeg
au sound file	.au	audio/basic
MIDI music file	mid,.midi	audio/midi,audio/x-midi
RealAudio Music File	.ra, .ram	audio/x-pn-realaudio
MPEG file	.mpg,.mpeg	video/mpeg
AVI file	.avi	video/x-msvideo
GZIP file	.gz	application/x-gzip
TAR file	.tar	application/x-tar
arbitrary binary data		application/octet-stream

Content-Disposition

Content-Disposition is a field added in RFC 2183 that represents the presentation style of the message. Because the previous message only defines its message format, and does not consider how the message is displayed, especially for mail.

For example, if a picture is inserted into the email, then this picture is displayed inline when we read the message? Or in the form of an attachment, which must be downloaded by the user to see it?

In 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 such a response is received, the web browser prompts the user to save its content as a file, rather than displaying it as a page in the browser window.

Content-Transfer-Encoding

What is this field used for?

We know that with more and more data formats, traditional ASCII can no longer support huge content representations, so there are content representations beyond the ASCII range, such as Unicode.

However, for the SMTP server, the encodings that can be transmitted or recognized are limited. If you want to transmit binary content, you need to use certain transfer encodings to convert the binary content. This is the meaning of Content-Transfer-Encoding.

According to the definition of RFC and IANA, there are the following transfer encodings:

Name	Reference
7bit	[RFC2045]
8bit	[RFC2045]
binary	[RFC2045]
quoted-printable	[RFC2045]
base64	[RFC2045]

For the specific meaning of transfer encodings, you can refer to my follow-up articles, here is just a brief introduction.

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

For the SMTP server of the 8BITMIME SMTP extension, it also supports 8bit encoding.

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

Encoded-Word

According to RFC 2822, field names and values in the acknowledgement header must use ASCII characters. Encoding is required if the message contains non-ASCII characters. This encoding is encoded-word.

The format of the encoding is as follows:

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

charset represents the encoding of the original message, encoding represents 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, there may be more than one message type in it. So at this time, you need to use Multipart messages, that is, the message is divided into multiple parts, each part has a Content-Type.

This type is more common in emails. The following is an example of Multipart messages, specifying a message's segmentation marker boundary in the 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--

Summarize

The above is the basic introduction of MIME. In it, we mentioned several transfer encodings methods, so stay tuned for the follow-up articles.

This article has been included in http://www.flydean.com/12-mime/

The most popular interpretation, the most profound dry goods, the most concise tutorials, and many tricks you don't know are waiting for you to discover!

Welcome to pay attention to my official account: "Program those things", understand technology, understand you better!