СПИСОК УПРАВЛЯЮЩИХ ПОСЛЕДОВАТЕЛЬНОСТЕЙ

Расширение сферы использования средств злектронной почты, усложнение предьявляемых к ней требований, при которых сообщение рассматривается не как простой кусок текста, инициировало разработку нового стандарта на передачу информации, содержащую элементы видео и аудио, а также графику. Стандарт MIME (Mutlipurpose Internet Mail Extension), или в терминологии Internet - RFC1341, как раз и регламентирует порядок формирования и описания тела почтового сообщения, проходящего через Internet.

Предшественником MIME является стандарт почтового сообщения ARPA (RFC822), разработанный для обмена текстовыми сообщениями. С момента опубликования стандарта возможности аппаратуры и средств телекоммуникаций ушли далеко вперед и стало ясно, что многие типы информации, уже давно получившие широкое использование в сети, невозможно передать средствами электронной почты без специальных ухищрений. Например, в тело сообщения нельзя включить графику, аудио, видео и другие типы информации. Стандарт RFC822 не предоставляет также возможностей для передачи даже текстовой информации, кодировка которой не умещается в семи битах Естественно, что при использовании RFC822 не может быть и речи о передаче размеченного текста для отображения его различными стилями и шрифтами. Ограничения RFC822 становятся еще более очевидными при необходимости организовать обмен сообщениями в разных почтовых системах. Например, для приема передачи почты из/в Х.400, который позволяет иметь двоичные данные в теле сообщения, ограничения старого стандарта могут стать фатальными. В этом случае старый, испытанный способ кодировки информации процедурой uuencode не работает, так как эти данные для Х.400 и программы рассылки почты в Internet могут иметь различную интерпретацию.

В некотором смысле стандарт MIME ортогонален RFC822 и, если последний подробно описывает в заголовке почтового сообщения тело письма и механизм его рассылки, то MIME, в основном, ориентирован на определение в заголовке структуры тела почтового сообщения и его компоновки из информационных единиц различных типов.

В стандарте зарезервировано несколько способов представления разнородной информации. Для этой цели используются специальные поля заголовка почтового сообщения:

- версия MIME. используется для идентификации сообщения, подготовленного в новом стандарте;

- поле описания типа информации в теле сообщения: позволяет обеспечить правильную интерпретацию данных;

- поле типа кодировки информации в теле сообщения указывает на тип процедуры декодирования;

- два дополнительных поля, зарезервированных для более детального описания тела сообщения.

Стандарт MIME разработан как расширяемая спецификация, в которой подразумевается, что число типов данных будет расти по мере развития форм представления данных. Следует учитывать, что анархия типов в части их безграничного увеличения тоже не допустима. Каждый новый тип в обязательном порядке должен быть зарегистрирован в IANA (Internet Assigned Numbers Authority).

Форма и назначени текстовых полей

Поле версии стандарта MIME (MIME-Version) указывается в заголовке почтового сообщения и позволяет программе рассылки почты определить, что сообщение подготовлено именно в стандарте MIME. Например,

MIME-Version: 1.0

Поле версии указывается в общем заголовке почтового сообщения и относится ко всему сообщению целиком. В отличие от RFC822 стандарт MIME позволяет перемешивать поля заголовка сообщения с телом сообщения, поэтому все поля делятся на два класса: общие поля заголовка, записываемые в начало почтового сообщения и частные поля, которые относятся только к отдельным частям составного сообщения и размещаются непосредственно перед ними.

Поле типа содержания тела почтового сообщения (ContentType) используется для описания типа данных, которые размещаются в теле почтового сообщения. Это поле сообщает программе чтения почты, какого сорта преобразования необходимы для того, чтобы сообщение правильно проинтерпретировать. Эта же информация используется и программой рассылки при кодировании и декодировании почты. Стандарт MIME определяет семь типов данных, которые можно передавать в теле письма: текст (text); смешанный тип (multipart); почтовое сообщение (message); графический образ (image); аудиоинформация (audio); фильм или видео (video); приложение (application). Общая форма записи поля выглядит в записи Бэкуса-Наура следующим образом:

Content-туре := type "/" subtype *[";" parameter]
type := "application" / "audio"
/ "image" / "message"
/ "multipart" / "text>
/ "
tspecials := "(" / ")" / "<" / ">" / "@" ; Обязательно
/ "," / ";" / ":" / "" / <"> / должны быть,
/ "/" / "[" / "]" / "?" / "." ; заключены в
/ "=" у кавычки.

Тип Text указывает на то, что в теле сообщения содержится текст. Основным подтипом данного типа является "plain", что обозначает так называемый планарный текст. Понятие "планарный" текст появилось в связи с тем, что существуют еще размеченный текст или текст со встроенными в него символами управления отображением, а также гипертекст, который можно просматривать не последовательно, а произвольно, следуя гипертекстовым ссылкам. Для обозначения размеченного текста используют подтип "richtext", а для обозначения гипертекста подтип "html". Вообще говоря, "html" - это специальный вид размеченного текста, который используется для представления гипертекстовой информации в системе World Wide Web, получившей сегодня широкое распространение в сети Internet.

Передача и интерпретация размеченного текста являются одной из причин появления стандарта MIME, поэтому на типе "Richtext" следует остановится более подробно. Этот тип определяет текст со встроенными в него специальными управляющими последовательностями, которые согласно стандарту языка разметки документов SGM? называются "тегами". Теги представляют собой последовательность символов типа "<строка-символов>", где "строка - символов" определяет управляющее действие. Теги делятся на теги начала элемента текста ("<......">) и конца элемента текста (""). В качестве примера такой разметки можно привести следующий фрагмент:

Now is the time for
all good men
(and women>) to
 соме
to the aid of their

В этом фрагменте означает выделение "жирным" шрифтом, - курсив, - мелкий шрифт, - знак "<", игнорирование обозначено как , новая строка как . Полный перечень управляющих последовательностей представлен на врезке.

Специальный тип разметки задается подтипом "html", или гипертекст. Разметка гипертекста строится по тому же принципу, как и в "richtext", однако применяются теги, позволяющие описать гипертекстовые ссылки: ".....", , . Тег " ....... определяет следующий, просматриваемый фрагмент текста. Текст между тегом начала и тегом конца будет выделен в программе просмотра цветом или друтим способом и использоваться как контекстная гипертекстовая ссылка. Тег определяет "якорь" или место внутри документа, на которое можно сослаться как на метку. В качестве примера такой разметки текста можно привести следующий фрагмент:

заголовок документа 

параграф.

 встроенный image.

 "якорь" внутри текста документа.

Тип "Multipart" определяет смешанный документ, который может состоять из фрагментов данных разного типа. У него есть ряд подтипов. Подтип "mixed" позволяет создавать сообщение, состоящее из нескольких фрагментов, разделенных между собой границей, задаваемой в качестве параметра подтипа:

From: Nathaniel Borenstein 
To: Ned Freed 
Subject: Sample message
MIME-Version: 1.0
Content-type: multipart/mixed; boundary="simple
boundary"
This is the preamble. It is to be ignored, though it is а handy
place for mail camposers to include an explanatory note to
non-MIME campliant readers.
- simple boundary
This is implicitly typed plain ASCII text. It does NOT end with
а linebreak.
- simple boundary
Content-type: text/plain; charset=us-ascii
This is explicitly typed plain ASCII text. It DOES end with а
linebreak.
- simple boundary -
This is the epilogue. It is also to be ignored.

В данном примере поле "Content-Type" определяет подтип "mixed" и границу между фрагментами как строку " - simple boundary - ". В начале каждого фрагмента может быть задана своя строка с полем "Content-Type". Как видно из примера, существует два фрагмента, которые не отображаются: преамбула и эпилог, куда можно поместить комментарии. Другим подтипом может быть подтип "alternative", позволяющий организовать вариативный просмотр почтового сообщения в зависимости от возможностей программы просмотра. Приведем пример:

From: Nathaniel Borenstein 
To: Ned Freed 
Suhject: Formatted text mail
MIME-Version: 1.0
Content-Туре: multipart/alternative; boundary=boundary42
-houndary42
Content-Туре: text/plain charset=us-aacii
...plain text version of message goes here....
-boundary42
Content-Type: text/richtext
.... richtext version of same message goes here ...
-boundary42
Content-туре: text/x-whatever
.... fanciest formatted version of same message goes here ... -
boundary42-

Первый фрагмент текста в этом примере предназначен для обработки алфавитно-цифровыми программами просмотра, а для вывода второго фрагмента, представляющего собой пример размеченного текста, требуется специальная программа просмотра. Подтип "digest" предназначен для многоцелевого почтового сообщения, когда различным частям требуется приписать более детальную информацию, чем просто тип:

From: Moderator-Address
MIME-Veraion: 1.0
Suhject: Internet Digest, volume 42
Content-туре: multipart/digest;
boundary="- next message -"
- next message -
From: sameone-else
Subject: my opinion
...body goes here ...
- next message -
From: someone-else-again
Subject: my different opinion
... another body goes here...
- next message -

Приведенный пример демонстрирует, как можно воспользоваться подтипом "digest" для рассылки почты разным пользователям и по разному.поводу, используя для этого поля "From" и "Subject" в качестве частных заголовков. Подтип "parallel" предназначен для составления почтового сообщения, части которого отобразятся одновременно, что предполагает запуск сразу нескольких программ просмотра.

Тип "message" предназначен для работы с обычными почтовыми сообщениями, которые по различным причинам нам могут быть переданы по электронной почте обычным образом. Суть этих причин следует из состава подтипов типа "message". Подтип "partial" предназначен для организации передачи одного большого сообщения по частям для последующей его автоматической сборки у получателя. Приведем пример передачи аудиосообщения, разбитого на части:

X-Weird-Header-1: Foo
From: Bi11@host.cam
То: joe@otherhost.cam
Suhject: Audio mail
Message-ID: id1@host.cam
MIME-Version: 1.0
Content-type: message/partial;
id="ABC@host.com";
number=1; total=2
X-Weird-Header-1: Bar
X-Weird-Header-2: Hello
Message-ID: anotherid@foo.com
Content-type: audio/basic
Content-transfer-encoding: base64
... first half of encoded audio data goes here...
and the second half might look samething like this.
From: Bill@host.cam
То: joe@otherhost.cam
Subject: Audio mail
MIME-Version: 1.0
Message-ID: id2@host.cam
Content-type: message/partial;
id="ABC@host.com"; number=2; total=2
... second half of encoded audio data goes here...

Атрибуты подтипа определяют идентификатор сообщения (id), номер порции (number) и общее число порций (total). Следует обратить внимание на то, что каждая часть имеет свое поле "Content-Type". Это означает, что все сообщение может состоять из частей разных типов. Другим подтипом является "External-Body", который позволяет ссылаться на внешние, относительно сообщения, информационные источники. Это нечто типа гипертекстовой ссылки из типа "text", например:

 From: Whomever
Subject: whatever
MIME-Version: 1.0
Message-ID: id1@host,com
Content-Туре: multipart/alternative; boundary=42
-42
Content-туре: message/external-body;
name="BodyFormats.ps";
site="thumper.bellcore.com";
access-type=ANON-FTP;
directory="pub";
mode="image";
expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
Content-type: application/postscript
-42
Content-туре: message/external-body;
name="/u/nsb/writing/rfcs/RFC-XXXX.ps";
site="thumper.bellcore.com";
access-type=AFS
expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
Content-type: application/postscript
-42
Content-туре: message/external-body;
access-type=mail-server
server="listserv@bogus.bitnet";
expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
Content-type: application/postscript
get rfc-xxxx doc
-42-

В приведенном примере используются подтипы "ExternalBody" и "multipart/alternative", а все сообщение разбито на несколько фрагментов, в каждом из которых находится ссылка на внешний файл. Реально в почтовом сообщении нет тела (границы не отображаются), однако если программа просмотра способна работать с внешними протоколами, то можно разрешить ссылки автоматически, запуская соответствующий сервис. Стандартным подтипом типа "message" является также "rfc822", определяющий сообщения в стандарте RFC822.

Типы описания нетекстовой информации

К таким типам относятся следующие:

- "image" для описания графических образов. (Наиболее часто используются файлы форматов GIF и JPEG);

- "audio" для описания аудио информации. Для воспроизведения сообщения данного типа требуется специальное оборудование;

- "video" для передачи фильмов. Наиболее популярным является формат MPEG;

- "application" для передачи данных любого другого формата. Обычно используется для передачи двоичных данных с их последующим преобразованием. Так, если на машине стоит видеокарта с 512 Кбайт памяти, а графика подготовлена в 256 цветах, то сначала ее следует преобразовать, и здесь может помочь тип "application". Основной подтип данного типа - это "octetstream", но применяются также "ODA" и "Postscript".

Назначение этих типов ясно из названия - обозначение данных для последующей обработки в форматах, определяемых подтипом.

Поле типа кодирования

Многие данные передаются по почте в их исходном виде: 7- и 8разрядные символы, 64base символы и т.п.. Однако, при работе в разнородных почтовых средах необходимо определить механизм их представления в стандартном виде US-ASCII. Для этого существуют процедуры кодирования такого сорта данных, - например, uuencode. Для того чтобы данные почтового сообщения были бы правильно распакованы в стандарт MIME, было введено поле "Content-Transfer-Encoding", имеющее следующий синтаксис:

Content-Transfer-Encoding := "BASE64" / "QUOTED-PRINTABLE" /
"8BIT" / "7BIT" /
"BINARY" / x-token

Обычно альтернативы "8bit", "7bit", "BINARY" не требуют никакого преобразования, так как почта передается байтами и SMTP не делает различия между ними. "BASE64" обычно используется в связке с типом "text/ISO-8859-1", а "х-token" дает возможность пользователю описать свою процедуру преобразования.

Стандарт MIME предусматривает еще два дополнительных поля: "Content-ID" и "Content-Description". Первое поле определяет уникальный идентификатор содержания, а второе - служит для комментария содержания. Ни то, ни друтое программами просмотра, обычно, не отображается.

СПИСОК УПРАВЛЯЮЩИХ ПОСЛЕДОВАТЕЛЬНОСТЕЙ

Bold - "жирный" текст.
Italic - курсив.
Fixed - "равноширинный" шрифт .
Smaller - уменьшенный шрифт.
Bigger - увеличенный шрифт.
Underline - подчеркнутый текст.
Center - отцентрированный текст.
FlushLeft - выровненный по левому краю.
FlushRight - выровненный по правому краю.
Indent - отступ от левого края.
IndentRight - отступ от правого края.
Outdent - отмена левого отступа.
OutdentRight - отмена правого отступа.
SamePage - размещение текста на одной странице.
Subscript - подстрочный текст.
Superscript - надстрочный текст.
Heading - заголовок.
Footing - текст ссылки.
ISO-8859-X - текст в кодировке IS0-8859-X.
US-ASCII - текст в кодировке US-ASCII.
Excerpt - цитата.
Paragraph - параграф.
Signature - автограф (подпись).
Comment - комментарий (не отображается).
No-op - нет операции.
It - знак "меньше"("<").
nl - новая строка.
np - новая страница.