Mobile phone Development Combat 66--mime Introduction 1

Introduction

A MIME type is a type of file that sets an extension that is opened by an application, and the browser automatically opens with the specified application when the extension file is accessed. Many are used to specify some client-customized file names, as well as some ways to open media files. MIME provides a way for a Web browser to consult a multi-format file.

The full name of the MIME is the "Multipurpose Internet Mail Extensions" Multi-functional Internet Message expansion service, a multipurpose e-mail expansion protocol that was first applied to the email system in 1992, but was later applied to the browser. The server will tell the browser the type of multimedia data that they send, and the notification means that it describes the MIME type of the multimedia data, allowing the browser to know what the MP3 file is, which is the shockwave file, and so on. The server puts the MIME marker in the transferred data to tell the browser which plug-in to use to read the relevant file.

MIME can support mail messages in many formats, such as non-ASCII characters, binary format attachments, and so on. This standard is defined in RFC 2045,; RFC 2046,; RFC 2047,; RFC 2048,; RFC 2049 and other RFCs. RFC 2822, which is a transition from RFC 822, stipulates that e-mail standards do not allow the use of characters other than the 7-bit ASCII character set in mail messages. Because of this, some non-English character messages and binary files, images, sounds and other non-text messages cannot be transmitted in e-mail. MIME defines a symbolic method for representing a wide variety of data types.

In HTTP, MIME types are defined in the Content-type header.

For example, suppose you want to transfer a Microsoft Excel file to a client. Then the MIME type is "application/vnd.ms-excel". In most practical situations, this file will then be routed to EXECL (assuming we set EXECL to handle special MIME-type applications). In ASP, the method of setting the MIME type is through the ContentType property of the response object.

MIME Information Composition

In the earliest HTTP protocol, there was no additional data type information, all transmitted data was interpreted by the client as Hypertext Markup Language HTML documents, and in order to support the multimedia data type, the HTTP protocol used the MIME data type information appended to the document to identify the data type.

MIME is intended to be a multi-mesh Internet Mail extension designed to append multimedia data when sending e-mail, allowing mail clients to process according to their type. However, when it is supported by the HTTP protocol, its meaning is even more pronounced. It makes the HTTP transfer not only the ordinary text, but also become colorful.

Each MIME type consists of two parts, preceded by a large category of data, such as audio audio, image image, and so on, followed by a specific category.

Common MIME Types

Hypertext Markup Language text. HTML text/html

XML document. XML Text/xml

XHTML documentation. XHTML Application/xhtml+xml

Plain 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 files Mid,.midi Audio/midi,audio/x-midi

RealAudio music files. RA,. Ram Audio/x-pn-realaudio

MPEG files. 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

The Internet has a special organization IANA to confirm the standard MIME type, but the internet is growing too fast, and many applications can't wait for the IANA to confirm that they use the MIME type as the standard type. So they use a method that begins with X in the category to identify that the category has not yet become a standard, such as X-gzip,x-tar. In fact, these types are widely used and have become the standard of fact. As long as both the client and the server recognize this MIME type, even if it is not a standard type, the client program can handle the data according to the MIME type using specific processing methods. Both the standard and common MIME types are set by default in Web servers and browsers (including operating systems), and only for uncommon MIME types, you need to set up both the server and the client browser for identification purposes.

Because the MIME type is related to the suffix of the document, the server uses the document's suffix to differentiate between MIME types for different files, and the server must define the correspondence between the document suffix and the MIME type. When the client receives data from the server, it simply accepts the data stream from the server and does not know the name of the document, so the server must use additional information to tell the client the MIME type of the data. Before sending real data, the server sends the MIME-type information of the flag data, which is defined using the Content-type keyword, for example, in an HTML document, the server will first send the following two lines of MIME identity information, which is not part of a real data file.

Content-type:text/html

Note that the second behavior is a blank line, which is required, and the purpose of using this empty line is to separate the MIME information from the true data content.

MIME exploits the fact that RFC 822 makes a little restriction on the content of the message body: The only limitation is that simple ASCII text can only be used. Therefore, the MIME information consists of normal Internet text messages, which have special RFC 822-compliant headers and formatted information bodies (attachments represented by subsets of ASCII). These MIME headers give a special way to represent attachments in a message.

　　Profiling of MIME information

The information for an ordinary text message consists of a header section (To:From:Subject: etc.) and a body part (Hello Mr., etc.). In a MIME-compliant message, it is not surprising that the various parts of the message are called MIME segments, and each paragraph is prefixed with a special header. MIME messages are only an extension based on RFC 822 messages. However, it has its own set of RFC specifications.

Header field

The MIME header is broadly divided into MIME headers and MIME segment headers, depending on the location in the mail packet. (Translator: The MIME information header refers to the header of the entire message, while the MIME segment header is only the header of each MIME segment.) ）

　　The MIME information headers are:

Mime-version:

This header provides the version number of the MIME used. This value is customarily 1.0.

Content-type:

It defines the type of data so that the data can be handled appropriately. Valid types are: Text,image,audio,video, Applications,multipart, and message. Note that any binary attachment should be called Application/octet-stream. Some of the use cases for this header are: Image/jpg, application/mswork,multipart/mixed, which is only a very small part.

Content-transfer-encoding:

This is the most important of all the headers, because it illustrates how the data is encoded, and the customer/mua will use it to decode the attachment. For each attachment, you can use one of the encoding methods in 7bit,8bit,binary, Quoted-printable,base64, and custom.

7bit encoding is a common encoding used in the US ASCII character set, that is, to keep it as it is. 8bit and binary encoding are generally not used. For human-readable standard text, quoted printable can be used if the transmission is to be protected by a gateway that has an impact on the format.

Base64 is a general-purpose approach that provides a no-brainer option when deciding which encoding method to use, usually on binary, non-textual data. Note that any non-7bit data must be encoded in a pattern so that it can pass through the Internet Mail Gateway.

Content-id:

This head is useful if Content-type is message/external-body or multipart/alternative. It is beyond the scope of this article.

Content-description:

This is an optional header. It is a free-text description of the content of any information segment. Description must use US-ASCII code.

Content-disposition:

A pilot head, which is used to provide a hint to the client program/mua to determine whether an attachment is displayed in a row or as a separate attachment.

MIME Segment Header (the header that appears in the actual MIME attachment section), in addition to the Mime-version header, can have any of these header fields. If a MIME header is part of an information block, it will act on the entire body of information. For example, if content-transfer-encoding is displayed in the header of the information (referring to the entire information), it is applied to the entire body of information, but if it is displayed in a MIME segment, it "can only" be used in that segment.

Note: It is possible to decrypt incoming messages automatically