Проект OpenNet: MAN MIME::Tools::primer (3) Библиотечные вызовы (FreeBSD и Linux)

Интерактивная система просмотра системных руководств (man-ов)

MIME::Tools::primer (3)

>> MIME::Tools::primer (3) ( Разные man: Библиотечные вызовы )

NAME

MIME::Tools::primer - introduction to basic MIME concepts

SYNOPSIS

This is part of the MIME-tools documentation. See MIME::Tools for the full table of contents.

DESCRIPTION

So you need to parse (or create) MIME, but you're not quite up on the specifics? No problem. Read on...

A MIME glossary

Here are some definitions adapted from RFC-1521 explaining the terminology we use; each is accompanied by the equivalent in MIME:: module terms.

Start with the ``entity'' entry.

attachment

An ``attachment'' is common slang for any part of a multipart message --- except, perhaps, for the first part, which normally carries a user message describing the attachments that follow (e.g.: ``Hey dude, here's that GIF file I promised you.'').

In the MIME-tools system, an attachment is just a MIME::Entity stored in the parts list of the entity it is ``attached'' to.

See ``parts()'' in MIME::Entity for more details.

body

The ``body'' of an entity is that portion of the entity which follows the header and which contains the real message content. For example, if your MIME message has a GIF file attachment, then the body of that attachment is the base64-encoded GIF file itself.

In the MIME-tools system, a body is represented by an instance of MIME::Body. You get the body of an entity by invoking the bodyhandle() method.

See MIME::Body for more details.

body part

One of the parts in the body of a multipart multipart. This term just accentuates the fact that the entity in question was contained inside a multipart entity.

In the MIME-tools system, a body part is represented by an instance of MIME::Entity, just like any other entity.

See MIME::Entity for more details.

entity

An ``entity'' is the most important thing in the MIME universe: basically, it's just a blob of data (such as a single text or image file) which is accompanied by ancillary information about that data --- the data's content-type (e.g., ``text/plain'', ``image/gif''), a recommended filename to use when storing the data, etc.

The whole point of the MIME standard is to define how entities are represented when they travel through email. Roughly speaking, all entities (even images) are commonly encoded as ASCII text: the ancillary information comes first, then a blank line, then the encoded data.

For this reason, we refer to the ancillary-information portion as the header, and the encoded-data portion as the body. All entities have a header and a body.

In the MIME-tools system, an entity is represented by an instance of MIME::Entity. The entity's header is represented by an instance of MIME::Head. If the entity contains simple data, then the body is represented by an instance of MIME::Body; if, however, it is a special type of ``multipart'' entity which just contains other entities, then it will have no body object but a list of ``parts'' instead.

See MIME::Entity, MIME::Head, and MIME::Body for more details.

header

This is the top portion of the MIME message, which contains the ``Content-type'', ``Content-transfer-encoding'', etc. Every MIME entity has a header.

In the MIME-tools system, a header is represented by an instance of MIME::Head. You get the header of an entity by invoking the head() method.

See MIME::Head for more details.

message

A ``message'' generally means the complete (or ``top-level'') message being transferred on a network; e.g., an email message.

In the MIME-tools system, messages are what we parse from filehandles to obtain MIME::Entity objects.

Content types

This indicates what kind of data is in the MIME message, usually as majortype/minortype. The standard major types are shown below. A more-comprehensive listing may be found in RFC-2046.

application: Data which does not fit in any of the other categories, particularly data to be processed by some type of application program. "application/octet-stream", "application/gzip", "application/postscript"...
audio: Audio data. "audio/basic"...
image: Graphics data. "image/gif", "image/jpeg"...
message: A message, usually another mail or MIME message. "message/rfc822"...
multipart: A message containing other messages. "multipart/mixed", "multipart/alternative"...
text: Textual data, meant for humans to read. "text/plain", "text/html"...
video: Video or video+audio data. "video/mpeg"...

Content transfer encodings

This is how the message body is packaged up for safe transit. There are the 5 major MIME encodings. A more-comprehensive listing may be found in RFC-2045.

7bit: No encoding is done at all. This label simply asserts that no 8-bit characters are present, and that lines do not exceed 1000 characters in length (including the CRLF).
8bit: No encoding is done at all. This label simply asserts that the message might contain 8-bit characters, and that lines do not exceed 1000 characters in length (including the CRLF).
binary: No encoding is done at all. This label simply asserts that the message might contain 8-bit characters, and that lines may exceed 1000 characters in length. Such messages are the least likely to get through mail gateways.
base64: A standard encoding, which maps arbitrary binary data to the 7bit domain. Like ``uuencode'', but very well-defined. This is how you should send essentially binary information (tar files, GIFs, JPEGs, etc.).
quoted-printable: A standard encoding, which maps arbitrary line-oriented data to the 7bit domain. Useful for encoding messages which are textual in nature, yet which contain non-ASCII characters (e.g., Latin-1, Latin-2, or any other 8-bit alphabet).

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру