mime_content_type — определяет MIME Content-type файла


Содержание

Mime_content_type — определяет MIME Content-type файла

Типы доступа «ftp» и «tftp» Тип доступа по FTP или TFTP означает, что тело сообщения доступно как внешний файл по протоколу FTP [RFC-959] или TFTP [RFC-783] соответственно. Для этих типов доступа обязательны следующие дополнительные параметры:

NAME — Имя файла, содержащего данные тела письма.

SITE — Полный доменный адрес или псевдоним компьютера, с которого файл может быть получен по указанному протоколу.

Перед тем, как начнется считывание данных по FTP, пользователь обычно должен быть спрошен на предмет логина и пароля для машины, указанной в параметре ‘site’. По причинам безопасности логин и пароль не указываются как параметры Content-Type и должны быть получены от получателя письма.

Дополнительно определены следующие необязательные параметры:

DIRECTORY — каталог, содержащий тело письма на удаленной машине.

MODE — Нечувствительное к регистру букв строка, указывающая режим передачи данных. Допустимые эначения для типа доступа TFTP:

NETASCII, OCTET и MAIL. Для типа доступа FTP: ASCII, EBCDIC, IMAGE и LOCALn , где n — десятичное целое число, обычно 8. Эти значения соответствуют типам представления A, E, I и Ln, определенным FTP-протоколом. Заметьте, что «BINARY» и «TENEX» не являются допустимыми значениями для параметра MODE. Вместо них должны использоваться «OCTET», «IMAGE» или «LOCAL8». Если параметр MODE отсутствует, значением по умолчанию является «NETASCII» для TFTP и «ASCII» для FTP.

Способ досупа «anon-ftp» Этот способ доступа идентичен «ftp», за исключением того, что пользователю не требуется указывать свой логин и пароль для удаленной машины. FTP-протокол будет использоваться с логином «anonymous» и email-адресом получателя вместо пароля.

Способы доступа «local-file» и «afs» Способ доступа «local-file» означает, что тело письма доступно как файл на локальной машине. «afs» означает, что тело доступно как файл через общую файловую систему AFS. В обоих случаях требуется единственный обязательный параметр:

NAME — Имя файла, содержащего данные тела письма.

Следующий необязательный параметр может быть использован для локализации ссылки на файл и содержит адрес сайта или сайтов, на которых данный файл виден:

SITE — Доменный адрес машины или машин, на которых возможен доступ к файлу данных. Допускаются маски с использованием звездочки вместо части доменного имени, например, «*.bellcore.com», для обозначения набора машин, на которых файл виден напрямую. Единственная звездочка вместо всего доменного имени может означать, что файл, где би он ни был, виден через глобальную файловую систему.

Способ доступа «mail-server» Применяется, когда тело письма доступно через почтовый сервер. Обязательный параметр для этого способа доступа:

SERVER — email-адрес mail-сервера, с которого могут быть запрошены данные тела письма.

Так как почтовые серверы предполагают множество различных синтаксисов, некоторые из них могут быть многострочными, полная команда, которую нужно послать на mail-сервер, не включается как параметр в однострочное поле ‘content-type’. Вместо этого она помещается в мнимое тело, когда значением поля ‘content-type’ является ‘message/external-body’, и параметр ‘access-tyoe’ имеет значение ‘mail-server’.

Необязательный параметр для этого способа доступа:

SUBJECT — Subject, который будет использован в заголовке письма-запроса, которое почторый клиент получателя пошлет на указанный почтовый сервер для получения данных тела письма. Заметьте, что помещение адреса сервера в subject не рекомендуется, однако, известны mail-серверы, требующие этого.

MIME -стандарт не определяет синтаксиса обращения к почтовому серверу. Поэтому он допускает включение полной команды для mail-сервера в мнимое тело.

В отличие от других способов доступа, доступ через mail-сервер не синхронен, и данные могут быть получены в непредсказуемый момент в будущем. По этой причине важно иметь механизм, обеспечивающий вставку полученных от mail-сервера данных в исходное письмо. Mail-сервер при отправке запрошенных данных должен использовать то же самое значение поля Content- >Стандартным подтипом типа «message» является «rfc822». Этот подтип указывает, что тело письма содержит вложенное письмо в стандарте RFC 822, однако, в отличие от заголовка RFC 822 верхнего уровня, для каждой части, являющейся письмом RFC 822, не требуется наличия полей «From», «Subject» и, по крайней мере, одного поля «To».

Не смотря на использование числа «822», тело, имеющее подтип ‘message/rfc822’, может включать дополнительную информацию в соответствии со стандартом MIME. Другими словами, письмо ‘message/rfc822’ может быть MIME-письмом.

В заключение опишем формальный синтаксис поля заголовка ‘content-type’ для данных типа ‘message’

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

  • «image» для описания графических образов. Наиболее часто используются файлы форматов GIF и JPEG.
  • «audio» для описания аудио информации. Для воспроизведения сообщения данного типа требуется специальное оборудование.
  • «video» для передачи фильмов. Наиболее популярным является формат MPEG.
  • «application» для передачи данных любого другого формата, обычно используется для передачи двоичных данных для последующего промежуточного преобразования. Так если на машине стоит видео-карта с 512Kb памяти, а графика подготовлена в 256 цветах, то сначала ее следует преобразовать и здесь может помочь тип «application».

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

Тип «Application»
Этот тип используется для данных, неподпадающих под остальные категории, в частности, для данных, обрабатываемых прикладными почтовыми программами. Это информация, которая должна быть обработана соответствующим приложением для того, чтобы принять наглядную либо исполняемую для получателя форму. Предполагаемое использование для этого типа включает в себя пересылку файлов по почте, таблицы, данные для почтовых систем расписания, языки лдя «активной» (вычислительной) почты. (Последняя, в частности, может поднять проблемы безопасности, которые должны быть поняты разработчиками ПО и рассмотрены ниже в параграфе «Application/PostScript»).

Например, тот, кто занимается расписанием встреч, может определить стандартное представление информации о датах запланированных встреч. «Умный» пользовательский почтовый агент может использовать эту информацию для проведения диалога с пользователем, и может затем посылать в дальнейшем почту, основанную на том диалоге. Вообще, существует несколько «активных» почтовых языков, разработанных для специализированных программ, которые посылаются по почте и автоматчески запускаются в системе получателя.

Подобные приложения могут быть определены как подтипы для типа «application». Изначально предопределено два подтипа: «octet-stream» и «PostScript».

В общем, подтип для ‘application’ зачастую может быть именем приложения, для которого предназначены пересылаемые данные. Однако, это не означает, что любое имя прикладной программы может свободно использоваться как подтип для ‘application’. Такие употребления (кроме подтипов, начинающихся с «x-«) должны быть зарегестрированы в IANA.

Основной подтип ‘Application/Octet-Stream’

Используется для обозначения того, что тело содержит бинарные данные. Набор возможных параметров включает следующие (но не ограничивается ими):

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

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

Дополнительный параметр, «conversions», определенный в [RFC-1341], был исключен в последствии.

В RFC 1341 также определен параметр «NAME», указывающего имя файла, которое должно быть использовано при сохранении данных на диск. Но он опять же был отменен в ожидании введения отдельного поля заголовка Content-Disposition, которое будет определено в ближайшем будущем.

Рекомендуемое действие для почтовой программы, получившей почту типа application/octet-stream, — просто предложить записать данные в файл без какого-либо преобразования, или. возможно, произвести его в соответствии с указанием пользователя.

Для уменьшения опасности передачи вирусных и других намеренно разрушающих систему программ по почте, строго рекомендуется, чтобы почтовая программа получателя не производила запуск программы, заданной в параметре поля «Content-Type» (например, в параметре «interpreter=»), использующей в качестве входных данных тело письма.

Подтип «Aplication/PostScript» Тип «application/postscript» означает, что пересылается PostScript-документ и требует специальной программы для его обработки. В настоящий момент используются два языка — level 1 и более поздний — level 2.

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

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

Другие подтипы типа Application Ожидается, что многие подтипы типа ‘Application’ будут введены в будущем. MIME-совместимые почтовые программы должны интерпретировать любой незнакомый им подтип как эквивалент ‘application/octet-stream’.

Формальный синтаксис дла поля ‘content-type’ для данных типа ‘application’ дается следующим образом. Тип ‘Image’ Этот тип означает, что тело письма содержит графический объект. Его подтипы соответствуют конкретным графическим форматам. Их значения нечувствительны к регистру букв. Два предопределенных подтипа — «jpeg» для формата JPEG с кодированием JFIF, и «gif» — для формата GIF.

Формальный синтаксис поля ‘Content-Type’: Тип ‘Audio’ Этот подтип означает, что тело содержит аудио-данные. Хотя пока еще нет консенсуса по «идеальному» аудио-формату для компьютеров, сейчас имеется сильная потребность в универсальном формате.

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

Содержимое тела, имеющего подтип «audio/basic», — аудио-данные в 8-битной форме, кодированные с использованием ISDN mu-law. Формат, соответствующий этому подтипу, предполагает максимальную частоту звучания 8000 Hz и единственный канал.

Формальный синтаксис лдя поля ‘Content-Type’: Тип ‘V >Хотя MIME-стандарт запрещает смешение разнородных мультимедийных данных в одном теле (письма или части письма), многие так называемые «video»-форматы включают синхронизированный звук, что допускается для подтипов типа «video».

Формальный синтаксис лдя поля ‘Content-Type’: Экспериментальные значения поля ‘Content-Type’ Значение типа, начинающееся с «X-«, считается частным, предназначенным для использования по договоренности между двумя или более почтовыми системами. Публично определенные (регестрированные) значения никогда не должны начинаться с префикса «X-«.

В общем, использование X-типов верхнего уровня не рекомендуется. Производители почтового ПО должны по возможности обходиться использованием X-подтипов для предопределенных типов. Во многих случаях использование экспериментального подтипа более приемлимо, нежели типа верхнего уровня.

Таблица 2. Все определенные на сегодняшний день типы и подтипы поля Content — Type

ТИП ПОДТИП
text plain
richtext
enriched
tab-separated-values
multipart mixed
alternative
digest
parallel
appledouble
header-set
message rfc822
partial
external-body
news
application octet-stream
postscript
oda
atomicmail
andrew-inset
slate
wita
dec-dx
dca-rft
activemessage
rtf
applefile
mac-binhex40
news-message-id
news-transmission
wordperfect5.1
pdf
zip
macwriteii
msword
remote-printing
image jpeg
gif
ief
tiff
audio basic
video mpeg
quicktime

Значения полей Content-Type и subtype, а также другие параметры заголовка являются чувствительными к регистру букв, если только не оговорены исключения для конкретного значения параметра.

Дополнительные необязательные поля.

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

В заключении обсуждения стандарта MIME комплексный пример без комментариев:

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

Mime_content_type — определяет MIME Content-type файла

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

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

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

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

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

Поле версии MIME (MIME-Version)

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

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

Поле типа содержания тела почтового сообщения (Content-Type)

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

Text. Этот тип указывает на то, что в теле сообщения содержится текст. Основным подтипом типа «text» является «plain», что обозначает так называемый планарный текст . Понятие планарного текста появилось в связи с тем, что существует еще размеченный текст, т.е. текст со встроенными в него символами управления отображением, и гипертекст, т.е. текст, который можно просматривать не последовательно, а произвольно, следуя гипертекстовым ссылкам. Для обозначения размеченного текста используют подтип «richtext», а для обозначения гипертекста подтип «html». Вообще говоря, «html» — это специальный вид размеченного текста, который используется для представления гипертекстовой информации в системе World W >«Richtext» определяет текст со встроенными в него специальными управляющими последовательностями, которые в соответствии со стандартом языка разметки документов SGML называются тагами. Таги представляют из себя последовательность символов типа » «. «Строка-символов» определяет управляющее действие. Таги делятся на таги начала элемента текста (» «) и таги конца элемента текста (» «). В качестве примера такой разметки можно привести следующий фрагмент текста:

В этом фрагменте означает выделение «жирным» шрифтом, — курсив, — мелкий шрифт, — знак » , новая строка как .

Специальный тип разметки задается подтипом «html». Это так называемый гипертекст. Разметка гипертекста строится по тому же принципу как и в тексте типа «richtext». Однако применяются таги, позволяющие описать гипертекстовые ссылки. К таким тагам относятся «. «, , . Таг » . определяет следующий фрагмент текста, который будет просматриваться. При этом текст между тагом начала и тагом конца будет выделен в программе просмотра цветом или другим способом и используется как контекстная гипертекстовая ссылка. Таг задет встроенный в текст документа графический образ. В некотором смысле этот таг аналогичен «multipart», который разрешает комбинировать сообщение из нескольких фрагментов разного типа. Таг определяет «якорь», т.е. место внутри документа, на которое можно сослаться как на метку. В качестве примера такой разметки текста можно привести следующий фрагмент:

«Multipart». Этот тип содержания тела почтового сообщения определяет смешанный документ. Смешанный документ может состоять из фрагментов данных разного типа. Данный тип имеет ряд подтипов.

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

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

Другим подтипом может быть подтип «alternative». Данный подтип позволяет организовать вариабельный просмотр почтового сообщения в зависимости от типа программы просмотра. Приведем пример:

В этом примере для работы с планарным текстом при использовании алфавитно-цифровых программ просмотра предназначен первый фрагмент текста. Для просмотра размеченного текста используется второй фрагмент, для специальной программы просмотра может быть подготовлен специальный вариант (фрагмент 3).

Подтип «digest» предназначен для многоцелевого почтового сообщения, когда различным частям хотят приписать более детальную информацию, чем просто тип:

Приведенный пример показывает как можно воспользоваться подтипом «digest» для рассылки почты разным пользователям и по-разному поводу, используя поля «From:» и «Subject» в качестве частных заголовков.

Подтип «parallel» предназначен для составления такого почтового сообщения, части которого должны отображаться одновременно, что предполагает запуск сразу нескольких программ просмотра. Синтаксис такого сообщения аналогичен рассмотренным выше.

Тип «message». Данный тип предназначен для работы с обычными почтовыми сообщениями, которые однако не могут быть переданы по почте по разного рода причинам. Эти причины объясняются подтипами данного типа.

Подтип «partial» предназначен для передачи одного большого сообщения по частям для последующей автоматической сборки у получателя. Приведем пример передачи аудио сообщения разбитого на части:

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

Другим подтипом является «External-Body», который позволяет ссылаться на внешние, относительно сообщения, информационные источники. Этот подтип похож на гипертекстовую ссылку из типа «text». Приведем конкретный пример:

В данном примере приведено использование «External-Body» и «multipart/alternative». Все сообщение разбито на несколько фрагментов. В каждом из фрагментов находится ссылка на внешний файл. Реально тела почтового сообщения нет (границы программами просмотра не отображаются). Однако если программа просмотра способна работать с внешними протоколами, то можно ссылки разрешить автоматически, запуская соответствующий сервис.

Стандартным подтипом типа «message» является «rfc822». Данный подтип определяет сообщения стандарта RFC822.

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

  • «image» для описания графических образов. Наиболее часто используются файлы форматов GIF и JPEG.
  • «audio» для описания аудио информации. Для воспроизведения сообщения данного типа требуется специальное оборудование.
  • «video» для передачи фильмов. Наиболее популярным является формат MPEG.
  • «application» для передачи данных любого другого формата, обычно используется для передачи двоичных данных для последующего промежуточного преобразования. Так если на машине стоит видео-карта с 512Kb памяти, а графика подготовлена в 256 цветах, то сначала ее следует преобразовать и здесь может помочь тип «application». Основной подтип данного типа — «octet-stream», но существуют «ODA» и «Postscript».

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

Поле типа кодирования почтового сообщения (Content-Transfer-Encoding). Многие данные передаются по почте в их исходном виде. Это могут быть 7bit символы, 8bit символы, 64base символы и т.п. Однако при работе в разнородных почтовых средах необходимо определить механизм их представления в стандартном виде — US-ASCII. Для этого существуют процедуры кодирования такого сорта данных. Наиболее широко применяемая — uuencode. Для того, чтобы при получении данные были бы правильно распакованы и введено в стандарт поле «Сontent-Transfer-Encoding». Синтаксис этого поля следующий:

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

Дополнительные необязательные поля. Как уже говорилось ранее, стандарт определяет еще два дополнительных поля: «Content-ID» и «Content-Description». Первое поле определяет уникальный идентификатор содержания, а второе служит для комментария содержания. Ни то, ни другое программами просмотра обычно не отображаются.

В заключении обсуждения стандарта MIME комплексный пример без комментариев:

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

Почтовый стандарт «MIME» (RFC1521)

Документ предсталяет собой неполный русский перевод спецификации RFC 1521 «MIME — Multipurpose Internet Mail Extensions. Part one. Mechanismes for Specifying and Describing the Format of Internet Message Bodies» , а также конспект некоторых других документов, касающихся применения стандарта MIME.

MIME означает «Multipurpose Internet Mail Extensions» (Многоцелевые расширения почтового стандарта Internet). Этот стандарт описывает как пересылать по электронной почте исполняемые, графические, мультимедийные, смешаные данные. Типичные применения MIME — пересылка графических изображений, аудио, документов Word, программ и даже просто текстовых файлов, то есть, когда важно, чтобы входе пересылки не производилось никаких преобразований над данными. MIME также позволяет размечать письмо на части различных типов так, чтобы получатель (почтовая программа) мог определить, что делать с каждой из частей письма.

Как читать письма в стандарте MIME? Т.к. MIME используется всего несколько лет, еще существуют старые почтовые программы, которые не понимают MIME. Однако, растет число почтовых программ, имеющих встроенную поддержку MIME (одна из самых популярных — «Pine», разработанная в Вашингтонском университете и реализованная для платформ UNIX, VMS, DOS, Windows). К тому же в некоторых почтовых системах имеются специальные шлюзы, обеспечивающие MIME-трансляцию. Но даже если у вас нет возможности использовать MIME-совместимую почтовую программу и нет доступа к подобному шлюзу, то можно также воспользоваться рядом программ, способных интерпретировать письма в MIME, сохраненные рпочтовой программой в файле. Например, програма «munpack», созданная в университете Carnegie Mellon. Существуют ее версии для Unix, PC, Macintosh, Amiga.

Долгое время для кодирования бинарных файлов в 7-битный формат (чтобы обеспечить их пересылку по почтовой системе Internet) использовалась кодировка UUENCODE, имеющая ряд технических ограничений. Стандарт MIME предполагает использовние более устойчивой кодировки «Base64», которая специально разработана для обеспечения сохранности данных, пересылаемых по email, при различных преобразованиях, имиеющих место в ходе прохождения почтовых шлюзов.

Стандарт MIME полностью описан в RFC-1521



    I. Почтовый стандарт MIME

  • 1. Введение
  • 2. Замечания, соглашения и обобщения
  • 3. Поле заголовка ‘MIME-Version’
  • 4. Поле заголовка ‘Content-Type’
  • 5. Поле заголовка ‘Content-Transfer-Encoding’
  • 5.1. Механизм конвертации «Quoted-Printable»
  • 5.2. Механизм конвертации Base64
  • 6. Дополнительные поля ‘Content-‘
  • 6.1. Необязательное поле заголовка ‘Content-ID’
  • 6.2. Необязательное поле заголовка ‘Content-Description’
  • 7. Предопределенные значения поля ‘Content-Type’
  • 7.1. Тип ‘Text’
  • 7.1.1. Параметр ‘charset’
  • 7.1.2. Подтип ‘Text/plain’
  • 7.2. Тип ‘Multipart’
  • 7.2.1. Тип Multipart: общий синтаксис
  • 7.2.2. Подтип ‘Multipart/mixed’ (основной)
  • 7.2.3. Подтип ‘Multipart/alternative’
  • 7.2.4. Подтип ‘Multipart/digest’
  • 7.2.5. Подтип ‘Multipart/parallel’
  • 7.2.6. Друтие подтипы типа ‘Multipart’
  • 7.3. Тип ‘Message’
  • 7.3.1. Подтип ‘Message/rfc822’ (основной)
  • 7.3.2. Подтип ‘Message/Partial’
  • 7.3.3. Подтип ‘Message/External-Body’
  • 7.3.3.1. Способы доступа «ftp» и «tftp»
  • 7.3.3.2. Способ доступа «anon-ftp»
  • 7.3.3.3. Способы доступа «local-file» и «afs»
  • 7.3.3.4. Способ доступа «mail-server»
  • 7.3.3.5. Примеры и дополнительные пояснения
  • 7.4. Тип ‘Application’
  • 7.4.1. Подтип ‘Application/Octet-Stream’ (основной)
  • 7.4.2. Подтип ‘Application/PostScript’
  • 7.4.3. Другие подтипы типа ‘Application’
  • 7.5. Тип ‘Image’
  • 7.6. Тип ‘Audio’
  • 7.7. Тип ‘Video’
  • 7.8. Экспериментальные значения поля ‘Content-Type’

    II. Применение возможностей MIME в транспортных почтовых системах

  • 1. Непринятая почта
  • 2. Разбиение (фрагментация) и сборка больших писем
  • 3. Использование или удаление указателей External-Body (внешнего тела)
  • 4. Преобразование графических и других форматов
  • 5. Надежное кодирование данных
  • 1. Введение

    Со времени опубликования в 1982 г., стандарт RFC 822 определил и полностью или частично внедрил формат текстовых писем в почтовой системе Internet. Но с расширением его использования, обнаружился ряд ограничений, заметно ограничивающих удовлетворение пользовательских потребностей. В частности, возможность пересылки нетекстовых данных, например, аудио и графики, посто не была упомянута в RFC822, описывавшем лишь формат текстовых сообщеий. И даже в случае текста, RFC 822 обошел вниманием нужды пользователей, использующих расширенный набор символов, что характерно для азиатских и большинства европейских языков. Итак, требовалась дополнительная спецификация. Основное ограничение RFC822 — относительно короткие строки и 7-битная символьная таблица. Пользователям дляотправки нетекстовых данных приходилось конвертировать тело своего письма в 7-битную форму с помощью UUENCODE, BINHEX и др.

    Более очевидными стали ограничения RFC 822 при разработке почтовых шлюзов между хостами, использующими стандарт RFC822 и хостами, использующими стандарт X.400. X.400 имеет механизмы для включения нетекстовых данных в тело письма. В настоящее время стандарты для перевода почтовых сообщений из X.400 в RFC822 предполагают, что нетекстовые части тела письма должны быть сконвертированы (но не закодированы) в ASCII формат, либо должны быть «выброшены» из письма с уведомлением об этом получателя. А потеря информации крайне не желательна для пользователя.

    MIME разработан как расширяемый механизм с расчетом на то, что набор пар content-type/subtype будет расти со временем. Некоторые другие поля заголовка MIMЕ, включая имена наборов символов, также , вероятно, получат большее число возможных значений. С этой целью MIME определяет процесс регистрации через Internet Assigned Numbers Authority (IANA), как центр регистрации этих значений. Описание процесса регистрации можно найти в приложении E RFC 1521.

    2. Замечания, соглашения и обобщения

    Термины «сообщение» и «письмо» являются синонимами. Термин «часть письма» или «часть тела письма» подразумевает одну из частей письма, разбитого на части разных типов данных. Часть тела письма, в свою очередь, имеет тело и заголовок, так что имеет смысл говорить о теле части тела письма. В дальнейшем, при отсутствии оговорок, «телом» будем называть тело рассматриваемого в данный момент объекта — части письма либо всего письма. Как уже ясно, формат MIME-сообщения, в общем случае, рекурсивен.

    3. Поле заголовка «MIME-Version»

    Поскольку старый стандарт RFC 822 все еще используется, а MIME возможно, изменится и дополнится в будущем, почтовой программе необходимо знать, применен ли новый стандарт в конкретном письме или нет. Поэтому в заголовок ввелено новое поле «MIME-Version», объявляющее версию стандарта, в соответствии с которым написано данное письмо.

    Все почтовые сообщения, составленные в соответствии с MIME-стандартом, должны иметь это поле в своем заголовке, напрмер:

    Так как возможно, в будущем формат заголовка письма может расшириться, формально содержание поля «MIME-version» дается следующим образом:

    Т.о., будущие значения версии формата, коорые могут заменить «1.0», должны быть целыми числами, разделенными точкой. Если письмо получено со значением версии MIME, отличным от «1.0», оно не будет рассматриваться почтовой программой, как соответствующее данной спецификации.

    Важно, что поле заголовка «MIME-Version», должно располагаться в самам начале письма. Это не обязательно для каждой из частей тела письма в случае многочастевого письма, но обязательно для заголовков частей типа «message», если и только если эта часть сама по себе декларирована как соответствующая спецификации MIME.

    Не возможно полностью определить как почтовая программа, поддерживающая MIME, должна интерпретировать письмо, имеющее значение MIME-version, отличное от «1.0». Но, как минимум, почтовая программа должна предупредить пользователя о том, что письмо написано в незнакомом ей формате.

    Все поля заголовка, включая MIME-Version, Content-type, и т.д., должны соответствовать общим синтаксическим правилам, определенным в RFC 822. В частности, допускается включение комментариев (т.е., следующие 2 примера эквивалентны):

    4. Поле заголовка «Content-Type»

    Назначение этого поля — наиболее полное описание данных, содержащихся в теле, с тем, чтобы почтовый агент (программа) получателя могла выбрать соответствующий механизм для их обаботки. Впервые это поле было определено в RFC 1049, но имело более простой синтаксис.

    Данное поле включает в себя идентификаторы типа и подтипа, а также может содержать некоторую вспомогательную информацию, которая может потребоваться для конкретного типа данных. После идентификаторов типа и подтипа оставшаяся часть поля — просто набор парамеров, заданных в порядке «атрибут/значение». Набор параметров зависит от типа данных. (В частности, не может быть глобально-значимых параметров, справедливых сразу для всех типов содержимого ьела письма. Глобальные механизмы в MIME-модели реализованы с помощью введения дополнительных полей «Content-*»). Очередность параметров значения не имеет. В числе определенных параметров — «charset», декларирующий символьный набор (кодировку, кодовую страницу — это все синонимы) тела письма. Комментарии допускаются.

    Вообще, поле Content-Type самого верхнего уровня используется для объявления общего типа данных, в то время как подтип определяет специальный формат для данных этого типа. Так, значение «image/xyz» поля Content-Type сообщает пользовательской программе, что данные являются графическим изображением (image), даже если эта почтовая программа не имеет понятия о специальном формате «xyz» этой картинки. Но эта информация может быть использована программой, например, чтобы решить, показывать ли пользователю строкоые данные неизвестного подтипа — показ таких данных может быть оправдан для незнакомых подтипов текста, но не для незнакомых подтипов графики, аудио или видео. По этой причине, данные зарегистрированного подтипа аудио, графики, текста или видео не должны содержать внутри себя части другого подтипа — для содержания в письме данных одного типа, но разных подтипов следует использовать тип «multipart» или «application».

    Хотя многие параметры (модификаторы подтипов) имеют смысл лишь для конкретного типа, некоторые все же являются глобальными в том смысле. что они применимы ко всем типам (например, параметр «boundary» применим только с типом «multipart», а параметр «charset» может использоваться с несколькими типами).

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

    Правильное заполнение поля Content-Type:

    Здесь набор специальных символов отличается от набора, определенного в RFC 822 только наличием символов «/», «?», «=» и отсутствием символа «.».

    Указание подтипа в данном поле является обязательным, т.к. нет подтипов по умолчанию. В отличие от имен типов, подтипов и параметров, значения параметров в общем случае являются чувствительными к регистру букв, но могут быть и нечувствительными — в зависимости от параметра. Например, значения границ multipart-письма являются чувствительными, а значение «access-type» для message/External-body не является.

    Существует два приемлимых механизма для введения новых подтипов для поля Content-Type:


      Нестандартные значения (начинающиеся с «X-«) могут быть опредлены по договоренности для двух или более общающихся друг с другом почтовых агентов (программ) без какой-либо внешней регистрации и стандартизации.

  • Новые стандартные значения подтипов должны быть документированы, зарегистрированы и опробованы в IANA, как описано в приложении «E» RFC 1521. Если новй подтип предлагается для широкого использования, формат, описываемый им, должен быть описан в опубликованной спецификации и, возможно, предложен к стандартизации.
  • Семь предопределенных типов верхнего уровня, более детально, представляют собой следующее:

    text — текстовая информация. Основой подтип — «plain» — соответствует обычному неформатировнному тексту и не требует специального программного обеспечения для отображения этого текста за исключением поддержки национальных кодировок. Другие подтипы используются в случае размеченного текста, когда с помощью специальной программы можно улучшить его визуалзацию, но для понимания идеи содержания можно обойтись и без дполнительного ПО. Возможные подтипы могут описывать легкочитаемые форматы различных текстовых процессоров.

    multipart — содержимое письма состоит из некоторого множества частей, содержащих данные различных взаимонезависимых типов. Изначально определено четыре подтипа:

    1. «mixed» — основной;
    2. «alternative» — для представления одних и тех же данных в разных форматах;
    3. «parallel» — если разные части документа должны просматриваться одновременно;
    4. «digest» — если каждая из частей тела письма имеет тип «message».

    message — письмо в письме. Тело, содержащее данные типа «message», само является письмом или частью письма, полностью отформатированного в соответствии со стандартом RFC 822, которое, в свою очередь, может содержать свое собственное поле заголовка «Content-Type».
    Подтипы:

    1. «rfc822» — основной;
    2. «partial» — определен для частично-цитируемых писем для предотвращения фрагментирования тел содержащихся писем в случае слишком большой их общей длины для возможностей почтового транспорта;
    3. «External-body» — используется, чтобы указать, что тело письма очень большое и находится вне письма.

    image — графические данные. Графика требует соответствующего устройства вывода (графический дисплей, принтер, факс) для отображения своей информации. Изначально определены два подтипа для наиболее распространенных графических форматов — jpeg и gif.

    audio — звуковая информация. Требует звуковое устройство (динамик или наушники) для вывода информации. Основной подтип — «basic» .

    video — видео. Требует специальных аппаратных и программных возможностей для отображения видео-информации. Единстванный изначально определенный подтип — «mpeg» .

    application — как правило, неинтерпретируемый двоичный код либо информация, предназначенная для обработки почтовой программой.
    Подтипы:

    1. «octet-stream» — основной подтип; предназначен для неинтерпретируемых двоичных данных, для которых рекомендуемым действием является предложение пользователю сохранить в файл на диске.
    2. «PostScript» — дополнительный подтип; применяется при пересылке PostScript-документов в теле письма.

    По умолчанию, письма, как и в стандарте RFC 822 пишутся простым (неразмеченным) текстом в языковой кодировке US-ASCII, что по спецификации MIME может быть описано как «Content-type: text/plain; charset=us-ascii». Это значение полагается, если поле Content-type не определено. Поэтому почтовая программа получателя может неверно истолковать содержимое письма, если при отправке не было указано поле Content-type, но на самом деле текст письма имеет другую кодировку или даже тип.

    При отсутствии поля Content-type или поля MIME-Version в заголовке MIME-письма нельзя быть точно уверенным, что письмо имеет языковую кодировку именно US-ASCII, поскольку могут еще встречаться почтовые программы, не использующие соглашения MIME. Но хотя возможно, что письмо, не содержащее в заголовке полей MIME-Version и Content-Type, может содержать все, что угодно, например, юниксовский tar-архив, сжатый gzip’ом и обработаный uuencode, все же, создателям почтовых программ рекомендуется оставлять этот факт без внимания и ориентироваться на значение по умолчанию, т.е. «text/plain; charset=us-ascii».

    Необходимо учесть, что в будущем ожидается заметное увеличение числа регистрированных типов и особенно подтипов содержимого писем. Если почтовая программа встретит неизвестное ей значение поля Content-type, она должна интерпретировать содержимое этого письма как «application/octet-stream» (см.выше).

    5. Поле заголовка Content-Transfer-Encoding

    Многие типы данных, пересылаемых через email требуют «натурального» представления, то есть, 8-битный набор символов либо двоичный код (что для машины — одно и то же, только представимо для пользователя по-разному). В таком виде данные не могут быть пересланы по 7-битным почтовым протоколам, например, RFC 821, который, к тому же, ограничивает длину строки 1000 символами.

    Стандартные механизмы конвертирования почты в 7-битный короткострочный формат, приемлимый для почтового транспорта, описывает поле заголовка Content-Transfer-Encoding.

    В отличие от типов содержимого, увеличение множества значений Content-Transfer-Encoding не является необходимым и даже нежелательно. Но установление единого механизма конвертирования не представляется возможным. Существует противоречие между желанием эффективно «ужать» бинарные данные и желанием трансформировать данные, которые, хотя бы частично являются 7-битным текстом, так, чтобы их все-таки можно было читать. По этой причине необходимы по крайней мере 2 механизма конвертации: «читабельный» и «плотно ужимающий».


    Данное поле не было определено в предыдущих стандартах. Его значение должно быть строкой без пробелов, определяющей тип конвертации, как показано ниже:

    Значения не чувствительны к регистру букв, то есть, Base64, BASE64 и bAsE64 — одно и то же. Значение «7BIT» означает, что тело письма уже имеет 7-битный формат и не тренбует дополнительной обработки для пересылки по почте. Это значение полагается по умолчанию, если поле заголовка Content-Transfer-Encoding отсутствует.

    Значения «8bit», «7bit» и «binary» означают, что никакой трансформации содержимого не производится. Однако, они сделаны различными для индикации того, что из себя представляет содержимое письма, и, соответственно, способа обработки, который может потребоваться для данной транспортной системы. В частности:

    «7bit» означает, что данные являются текстом, имеют короткие строки и языковую кодировку US-ASCII.

    «8bit» означает короткие строки, но в них могут содержаться не-ASCII символы (128-255).

    «Binary» означает, что тело письма может содержать не-ASCII символы, но строки могут быть произвольной длины, т.е. слишком длинными для SMTP-транспорта, и может несоблюдаться соглашение по признаку конца строки (CRLF), принятое в SMTP-транспорте.

    Хотя на первый взгляд разница в значениях Content-Transfer-Encoding может показатся неважной — ведь все они означают, что никакого преобразования нет, но четкая разметка важна для почтовых шлюзов между разными почтовыми системами, имеющими разные возможности и особенности работы, число которых со временем растет.

    Спецификация на почтовый транспорт для пересылки некодированных 8-битных данных дана в RFC-1426. Однако, нет стандартизованных транспортов рочты Internet, для которых является приемлимым включение в тело письма некодированных двоичных данных. Таким образом, значение «binary» фактически не является легальным в Internet. Но в соответствии с MIME, при использовании почтовой системой транспорта, умеющего работать с двоичными данными, в случае, когда необходимо послать двоичные данные по e-mail, необходимо указать это в заголовке в поле Content-Transfer-Encoding.

    Пять значений, определенных для поля Content-Transfer-Encoding, ничего не говорят о типе содержимого кроме указания алгоритма кодирования либо требований к почтовому транспорту в случае некодированных данных.

    Производители почтового ПО, если необходимо, могут определить новые значения поля Content-Transfer-Encoding, но эти значения должны иметь префикс «X-» («x-«), чтобы подчеркнуть их нестандартный характер. Однако, в отличие от типов и подтипов поля Content-Type, введение новых значений Content-Transfer-Encoding настоятельно не рекомендуется, так как может оказаться помехой для взаимосовместимости почтовых систем. Использование X-значений позволяется только как результат взаимосоглашения между взаимодействующими системами.

    Если поле Content-Transfer-Encoding появляеися в заголовке тела какой-то части письма, оно применяется только к содержимому этой части. Если письмо (часть письма) имеет тип «multipart» или «message», то поле Content-Transfer-Encoding может иметь в качестве своего значения только длину символа («7bit», «8bit» и т.д.) или «binary».

    Необходимо заметить. что электронная почта является символьно-ориентированной, так что механизмы конвертации работают с данными как с потоком символов, а не битов. Если битовый поток должен быть кодирован посредством какого-либо из этих механизмов, сначала он должен быть конвертирован в 8-битный поток байтов, используя порядок битов, стандартный для сетей (старшие разряды в конце). То есть, передние биты в потоке становятся битами высшего порядка в байте. Если битовый поток оканчивается неполным байтом, недостающие разряды заполняются нулями.

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

    то это означает, что тело письма представляет собой ASCII-код base64 текстовых данных, которые в нормальном виде имеют языковую кодировку ISO-8859-1, и будут в этой языковой кодировке после декодирования.

    Все множество определенных значений поля content-transfer-encoding кроме начинающихся с префикса «X-«, зарезервировано в IANA для будущего использования. Частные соглашения по значениям content-transfer-encoding также настоятельно не рекомендуются.

    Некоторые значения Content-transfer-encoding могут использоваться только с определенными типами (поле Content-Type). В частности, запрещено использовать любые значения кроме «7bit», «8bit», или «binary» с любым типом, рекурсивно включающим заголовки с полем Content-Type (как правило, это типы «multipart» и «message»). Все кодирования, необходимые для содержимого тел многочастного письма должны быть произведены на более низком уровне.

    Замечания по ограничениям конвертации:

    ЗАМЕЧАНИЕ ПО ПЕРЕВОДУ КОДОВ: Конверторы quoted-printable и base64 разработаны так, что данные после их применения легко взаимоконвертируемы. Единственный нюанс, возникающий в подобной ретрансляции — признак конца строки. При конвертации из quoted-printable в base64 перевод строки должен быть заменен последовательностью CRLF. Соответственно и наоборот, но ТОЛЬКО при конвертации текстовых данных.

    5.1. Механизм конвертации «Quoted-Printable»

    Этот механизм предназначен для представления данных, в основном состоящих из байтов, соответствующих символам, имеющим изображение в символьном наборе ASCII. В результате данного кодирования все байты будут иметь такие значения, гарантированные от дальнейшей модификации почтовым транспортом. Если конвертируемые данные в основном представляют собой ASCII-текст, то конечная их форма остается узнаваемой и читаемой для человека. Тело, полностью состоящее из ASCII-символов, также может быть конвертироавано в Quoted-Printable, что гарантирует его содержимому целостность при прохождении через всякие шлюзы, в которых происходит языковая перекодировка символов или преобразование концов строк и т.д.

    В Quoted-Printable байты должны быть рпедставлены в соответствии со следующими правилами:

    ПРАВИЛО #1: (обычное 8-битное представление). Каждый байт, кроме тех, которые используются для обозначения конца строки, может быть представлен с помощью двух шестнадцатиричных цифр, предворяемых знаком «=». При написании шестнадцатиричных цифр с A по F должны использоваться заглавные буквы. Кроме тех случаев, когда нижеследующие правила позволяют альтернативное кодирование, данное правило является обязательным.

    ПРАВИЛО #2: (Буквенное представление). Байты с десятичным значением с 33 по 60 и с 62 по 126 МОГУТ быть представлены ASCII-символами, соответствующими этим значениям (с ‘!’ по ‘ ‘ по ‘

    ПРАВИЛО #3: (Пробелы): Байты со значениями 9 и 32 МОГУТ быть представлены как ASCII-символы «Табуляция» и «Пробел», но НЕ ДОЛЖНЫ быть представлены так в конце строки. Везде, где они представлены соответствующими ASCII-символами, за ними должен следовать символ, имеющий графическое изображение (печатный символ). В конце же строки символы табуляции и пробела должны быть представлены в соответствии с правилом #1, так как некоторые почтовые транспорты могут убирать пробелы в конце строки.

    ПРАВИЛО #4: (Конец строки): Конец строки в тексте письма должен быть представлен (в соответствии с RFC 822) последовательностью CRLF. Так как в каноническом представлении текста не требуется визуального отображения символов конца строки, в Quoted-Printable не используется видимых символов для обозначения конца строки. Для представления бинарных данных более предпочтительной является кодировка base64.

    Необходимо заметить, что многие реализации почтовых программ могут кодировать по-своему. В частности, при представлеии текста в системах, использующих другие соглашения по обозначению конца строки (отличные от CRLF). Такие реализации недопустимы, и генерация концов строки должна быть стандартизована везде, чтобы не требовалось распознавать, используется ли какое-либо альтернативное представление.

    ПРАВИЛО #5: (Мягкий конец строки): В соответствии с Quoted-Printable длина строки не должна превышать 76 символов. В противном случае используется ‘мягкий’ перевод строки, представимый знаком равенства. Например, если исходная строка имела вид:

    то в Quoted-Printable encoding он может быть представлена следующим образом:

    Это обеспечивает механизм восстановления исходной длины строки пользовательским почтовыи агентом.

    Поскольку символ дефиса («-«) представляется в Quoted-Printable в обычном виде, особую осторожность нужно соблюдать при заключении тела в Quoted-Printable в многочастное письмо, чтобы удостовериться, что граница этого включения не проявляется нигде внутри этого включения (лучше всего выбрать обозначение границы в виде последовательности символов «=_», которая никогда не появляется в теле, закодированном в Quoted-Printable. См. определение многочастного письма далее.)

    ЗАМЕЧАНИЕ: Quoted-Printable представляет собой нечто вроде компромисса между читабельностью и сохранностью при пересылке. Тела в Quoted-Printable будут надежно защищены при прохождении многих почтовых шлюзов, но могут быть не очень хорошо переданы через некоторые шлюзы, использующие трансляцию в EBCDIC. (Теоретически, EBCDIC-шлюз должен кодировать тело из quoted-printable в base64 и затем декодировать обратно, но таких шлюзов пока не существует). Единственный способ добится действительно надежной транспортировки через EBCDIC-шлюз — экранировать ASCII-символы

    в соответствии с правилом #1.

    Так как данные в quoted-printable являются строчно-ориентированными, можно ожидать, что представление концов строки в Quoted-Printable будет изменено почтовым транспортом таким же образом, как и обычный текст может измениться при пересылке по Internet-почте между системами с разными соглашениями по представлению концов строки. Если подобные изменения могут нарушить целостность данных, то имеет смысл пользоваться кодировкой base64, а не Quoted-Printable.

    Вниманию создателей ПО: Если двоичные данные пересылаются в Quoted-Printable, то надо соблюдать осторожность при кодировании символов CR и LF. В частности, последовательность CRLF должна быть представлена как «=0D=0A», в противном случае, если CRLF означает конец строки, то она может быть неверно интерпретирована в платформах с другими соглашениями по концу строки.

    Синтаксис данных в quoted-printable описывается следующим образом:

    5.2. Механизм конвертации Base64

    Этот алгоритм разработан для представления произвольных последовательностей байтов в форму, читаемую для человека. Кодирующий и декодирующий алгоритмы очень просты, но закодированные данные примерно на 33% больше, чем некодированные. этот метод идентичен тому, который используется в приложениях PEM (Privacy Enhanced Mail), описанной в RFC 1421 с одним отличием: base64 не приемлит встроенного «чистого» текста.

    Base64 использует 65-символьный поднабор из US-ASCII, выделяя 6 бит на каждый печатный символ. (65-й символ «=» используется для обозначения функции спец. обработки).

    ПРИМЕЧАНИЕ: этот поднабор имеет важное свойство: он идентичен всем версиям языковой кодировки ISO 646, включая US ASCII, а также всем версиям EBCDIC. Другие популярные механизмы кодирования (uuencode, base85 — часть уровня 2 PostScript) не разделяют этих свойств и поэтому не удовлетворяют требованиям переносимости для двоичных данных электронной почты.

    Процесс кодирования преобразует 4 входных символа в виде 24-битной группы, обрабатывая их слева направо. Эти группы затем рассматриваются как 4 соединенные 6-битные группы, каждая из которых транслируется в одиночную цифру алфавита base64. При кодировании base64, входной поток байтов должен быть упорядочен старшими битами вперед.

    Каждая 6-битная группа используется как индекс для массива 64-х печатных символов. Символ, на который указывает значение индекса, помещается в выходную строку. Эти символы выбраны так, чтобы быть универсально представимыми и исключают символы, имеющие специальное значение для SMTP-транспорта («.», CR, LF) и для синтаксиса вложенных тел MIME («-«).

    Выходной поток (закодированные бфайты) должен иметь длину строк не более 76 символов. Все признаки перевода строки и другие символы, отсутствующие в таблице 1, должны быть проигнорированы декодером base64. Среди данных в Base64 символы, не перечисленные в табл. 1, переводы строки и т.п. должны говорить об ошибке передачи данных, и, соответственно, почтовая программа должна оповестить пользователя о ней.

    Если в хвосте потока кодируемых данных осталось меньше, чем 24 бита, справа добавляются нулевые биты до образования целого числа 6-битных групп. А до конца 24-битной группы остается от 0 до 3-х недостающих 6-битных групп, вместо каждой из которых ставится символ-заполнитель ‘=’. Поскольку весь входной поток представляет собой целое число 8-битных групп (т.е., просто байтных значений), то возможны лишь следующие случаи: (1) входной поток как раз оканчивается 24-битной группой. В таком случае, выходной поток будет оканчиваться четырьмя символами Base64 без символа ‘=’; (2) хвост входного потока имеет длину 8 бит. Тогда в конце выходного кода быдут два символа Base64, с добавлением двух символов ‘=’; (3) хвост входного потока имеет длину 16 бит. Тогда в конце выходного будут стоять три символа Base64 и один символ ‘=’.

    Т.к. символ ‘=’ является хвостовым заполнителем, его появление в теле письма может означать только то, что конец данных достигнут. Но такой гарантии нет, если число переданных битов кратно 24.

    Любые бессмысленные последовательности в коде Base64 вроде «=====» должны быть игнорированы.

    Если кодируемый текст не находится в канонической форме. то перед конвертацией в Base64 необходимо сначала все концы строк заменить стандартной последовательностью CRLF. Предпочтительнее эту функцию встроить в кодировщик Base64, нежели заставлять пользователя производить предварительную канонизацию текста другими средствами.

    Нет нужды экранировать вложенные тела внутри многочастного тела (multipart) при кодировании его в Base64, так как в коде Base64 отсутствует символ ‘-‘.

    6. Дополнительные Content- поля заголовка


    6.1. Необязательное поле Content-ID

    Как и значения поля Message-ID, значения поля Content-ID должны быть абсолютно уникальными (для всего мира).

    Такой идентификатор может быть использован для идентификации тела письма (части письма) в нескольких контекстах, в часности, для кэширования данных, указываемых с помощью механизма message/external-body. Хотя поле Content-ID является необязательным в общем случае, его использование необходимо в реализациях, генерирующих данные, имеющие дополнительный тип «message/external-body» (поле Content-type). Каждое тело такого типа должно обязательно иметь в своем заголовке поле Content-ID для обеспечения ссылки на такие данные.

    Значение поля Content-ID имеет специальную семантику в случае типа multipart/alternative. (См. соотв. пункт).

    6.2. Необязательное поле Content-Description

    Возможность ассоциировать некоторую описательную информацию с данными часто очень желательна. например, может быть полезным описать тело, содержащее графическое изображение, как «a picture of the Space Shuttle Endeavor.» Этот текст и может быть помещен в поле заголовка Content-Description.

    Описание должно иметь языковую кодировку US-ASCII, хотя механизм, определенный в RFC-1522 может быть использован для не-US-ASCII значений.

    7. Предопределенные значения поля Content-Type


    7.1 Тип ‘Text’

    Тип ‘text’ предназначен для пересылки текстовых материалов. Это значение поля — по умолчанию. Для обозначения языковой кодировки текста используется параметр «charset» для некоторых подтипов, включая основной подтип, «text/plain», соответствующий простому (неформатированному) тексту. В Internet’овской почте значением Content-Type по умолчанию является следующее: «text/plain; charset=us-ascii». Если текст является размеченным и нет соответствующего ПО для корректного визуального представления этого текста пользователю, имеет смысл сообщить ему подтип этих текстовых данных.

    7.1.1. Параметр ‘charset’

    В отличие от других значений, значения этого параметра не являются чувствительными к регистру букв.

    Спецификации любых новых подтипов типа ‘text’ должны определять, будет ли этот новый подтип использовать параметр «charset» либо наоборот, будет запрещать его использование. Любое тело, не содержащее внутри себя других, должно целиеом быть в одной языковой кодировке. В частности, создатели новых подтипов должны уделить внимание многбайтным символьным наборам.

    Дополнительно к предопределенным новые языковые кодировки могут быть зарегистрированы через IANA, хотя стандартизация их использования требует опробирования IESG (см. RFC-1340). Если используется 8-битная языковая кодировка (например, koi8 или cp866), то необходимо наличие поля заголовка Content-Transfer-Encoding для обеспечения передачи через ряд протоколов, в частности, SMTP.

    Необходимо заметить, что управляющие символы (0-31, 127), включая DEL, не имеют определенного значения за исключением последовательности CRLF (13,10), означающей конец строки. Два символа де-факто широко употребляются: FormFeed (12), означающий, что следующий за ним текст должен начинаться на новой странице; и TAB (9), часто, но не всегда означающий «перевести курсор на следующий ближайший столбец после данной позиции, где номер столбца кратен воьсми». Любое другое использование управляющих символов или DEL в теле должно быть в рамках частного соглашения между отправителем и получателем. Но такие соглашения крайне не рекомендуются и по возможности должны быть заменены другими возможностями MIME.

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

    • US-ASCII
    • ISO-8859-X — где «X» — цифра от 1 до 9 включительно, означающая номер версии кодировки ISO-8859

    Параметр «charset» был определен в основном для текстовых данных, но возможно, для бинарных данных тоже может потребоваться указать языковую кодировку, в этом случае должен использоваться тот же синтаксис те же значения.

    Почтовое программное обеспечение должно руководствоваться принципом наименьшего набора символов, то есть, если письмо пишется как-бы в восьмибитной ISO-8859-1, но в письме используются символы лишь некоторого поднабора, например, семибитного US-ASCII, то почтовая программа должна автоматически определить имя символьной кодировки как US-ASCII. В этом случае уменьшится нагрузка в сети и увеличаися шансы, что получатель прочтет письмо без искажений.

    7.1.2. Подтип ‘Text/plain’

    Это основной подтип, соответствующий простому (неформатированному) тексту. Значение поля Content-Type для почты Internet по умолчанию — «text/plain; charset=us-ascii». Это тип данных, соответствующий RFC 822.

    Других предопределенных подтипов для типа ‘text’ нет.

    Формальный синтаксис для типа ‘text’:

    7.2. Тип ‘multipart’

    Этот тип используется, если один или более различных наборов данных заключены в одном письме. Каждая часть тела должна иметь синтакс письма RFC 822 (то есть, иметь заголовок,ь пустую строку и тело), но должна иметь открывающую и закрывающую границы.

    Часть письма не должна интерпретироваться как настоящее письмо RFC 822. Вообще, для части письма наличие заголовка не обязательно, так что она может начинаться и с пустой строки, но при этом, все признаки, описываемые в заголовке, имеют значение по умолчанию. Для частей письма имеют смысл только поля, описывающие содержимое, то есть. начтинающиеся с «Content-«. Все остальные поля, необходимые в заголовке верхнего уровня, обычно игнорируются в частях письма при обработке почты, более того, в некоторых почтовых шлюзах они могут быть просто удалены. Для экспериментальных и частных целей могут использоваться «X-» поля, но информация, в них заложенная, может быть потеряна при прохождении некоторых почтовых шлюзов.

    ЗАМЕЧАНИЕ: Различие между письмом RFC 822 и частью письма MIME является маленькой, но важной. Шлюз между почтой Internet и X.400, например, должен иметь возможность отличить часть письма, содержащую графическое изображение, от части письма, содежащей вложенное письмо, телом которого является графическое изображение. Для представления последнего соответствующая часть письма должна иметь «Content-Type: message» и ее тело после пустой строки должно являться вложенным письмом со своим собственным полем заголовка «Content-Type: image». Схожесть синтаксиса обеспечивает легкость конверсии от письма к части письма, но различие между ними должно быть усвоено производителями ПО.

    Граница части письма не должна появляться внутри самой части письма.

    Все существующие и будущие подтипы типа «multipart» должны иметь идентичный синтаксис. Они могут различаться своей семантикой. Это требование гарантирует, что совместимые пользовательские агенты смогут по крайней мере распознать и разделить части многочастного письма, даже имеющего неизвестный им подтип.

    Как упомянуто в определении поля Content-Transfer-Encoding, использование других значений кроме «7bit», «8bit» или «binary» запрещено для типа «multipart». Почтовые шлюзы и другие почтовые агенты часто вносят изменения в заголовки верхнего уровня. В частности, они могут добавлять, убирать, переупорядочивать определенные поля. Такие изменения запрещены для заголовков частей письма, находяшихся внутри тела типа «multipart».

    7.2.1. Multipart: общий синтаксис

    Поле Content-Type многочастного письма требует одного параметра, «boundary», который определяет границы вложения. Границей является строка, состоящая из двух символов «-» (десятичный код 45) и значения параметра ‘boundary’ из поля заголовка Content-Type.

    ЗАМЕЧАНИЕ: Два символа «-» используются для совместимости с более ранним методом вложения писем, описанным в RFC 934 и для облегчения поиска границ. Однако, многочастные письма MIME не полностью совместимы с RFC 934; в частности, они не подчиняются соглашению RFC 934 по экранированию строк символом «-«, так как с каждым новым уровнем экранирования длина строк увеличивается. А поскольку SMTP-транспорты часто обрезают длинные строки, этот механизм становится неприменимым в случае многоуровневой структуры письма типа ‘multipart’.

    ВНИМАНИЮ ПРОИЗВОДИТЕЛЕЙ ПО: синтаксис параметров поля Content-Type таков, что зачастую необходимо значения границ в параметре ‘boundary’ заключать в кавычки. Это не всегда требуется, но никогда не повредит. Программистам следует изучить синтаксис внимательно, чтобы не допустить ошибок в поле Content-Type. Типичное поле Content-Type для типа ‘multipart’ может выглядеть следующим образом:

    Но в следующем примере содержится ошибка:

    (из-за двоеточия), которая может быть исправлена следующим образом:

    Это означает, что тело письма состоит из нескольких частей, каждая из которых соответствует синтаксису письма RFC 822, за исключением того. что область заголовка может быть абсолютно пустой и начальная граница каждой части отмечена последовательностью:

    Нужно обратить внимание, что метка границы части письма должна располагаться в начале строки, то есть, сразу же после признака конца строки CRLF. Причем, последовательность CRLF полагается элементом метки границы, а не последним элементом тела предыдущей части (так как тело предыдущей части может неоканчиваться концом строки, что принципиально важно в случае бинарных данных. Если же тело предыдущей части оканчивается концом строки, то метке границы соответственно должны предшествовать два конца строки). Сразу за меткой границы должен следовать конец строки (CRLF), или при отсутствии заголовка следующей части письма, два конца строки.

    Метка границы не должна иметь длину более 70 символов, не считая два начальных дефиса.

    Метка границы, следующая за последней частью письма, должна отличаться от предыдущих меток, чтобы показать, что далее не последует другой части письма. Отличие последней метки состоит в добавлении двух дефисов в конец:

    Обычно оставляется пространство для дополнительной информации перед первой меткой границы и после последней. Обычно его следует оставлять пустым, и обработчики почты должны игнорировать все, что в этом пространстве содержится.

    ЗАМЕЧАНИЕ: Эти области приамбулы и эпилога обычно не используются из-за отсутствия точной семантики для обработки этих областей почтовыми шлюзами, однако, многие программные MIME-продукты считают удобным помещать туда пояснительную информацию для получателей, которые пользуются до-MIME’овским ПО. По этой причине, MIME-совместимые программы должны игнорировать эти области.

    ЗАМЕЧАНИЕ: Поскольку метки границы не должны появляться внутри тел частей письма, почтовая программа, создающая письмо, должна иметь алгоритм, позволяющий автоматически подобрать уникальную последовательность, не встречающуюся в теле ни одной из частей, либо имеющую минимальную вероятность появления, если данные предварительно не сканируются на наличие таковой.

    В качестве простого примера предлагается двухчастное письмо, вторая часть которого оканчивается признаком конца строки, а первая нет:

    Часть письма, в свою очередь, также может иметь тип ‘multipart’, то есть. быть многочастным телом, но при этом метки границ, использующиеся во внешнем и во внутреннем multipart-телах, должны отличаться друг от друга.

    Использование типа ‘multipart’ в одночастном письме может быть полезно в некоторых контекстах и не запрещено.

    Единственным обязательным параметром для типа ‘multipart’ является параметр ‘boundary’, состоящий из 1-70 символов без хвостовых пробелов (которые могут быть удалены в процессе пересылки, и тогда почтовая программа получателя не сможет разделить вложенные части).

    Общий вид многочастного тела — следующий:


    ЗАМЕЧАННИЕ: В некоторых транспортах такие ограничения RFC 822, как использование тольеко печатных символов в теле, могут не действовать. Ослабления таких ограничений должны быть истолкованы как локальные расширения определения тела письма настолько, насколько они поддерживаются почтовым транспортом и адекватно документированы в поле заголовка Content-Transfer-Encoding. Однако, ни при каких обстоятельствах в заголовках как письма, так и его частей, не должно содержаться каких-либо символов, кроме US-ASCII.

    7.2.2. Основной подтип «multipart/mixed»

    Это основной подтип для типа ‘multipart’, он предназначен для случая, когда части письма взаимонезависимы. Любые новые подтипы, неизвестные почтовой программе, должны быть истолкованы аналогично подтипу ‘mixed’.

    7.2.3. Подтип «multipart/alternative»

    Этот подтип синтаксически идентичен предыдущему, но имеет несколько другую семантику.

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

    Multipart/alternative может быть использована, к примеру, для пересылки текста в некотором гипотетическом формате:

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

    Обычно пользовательский агент, создающий письмо в multipart/alternative, должны располагать альтернативные части в порядке увеличения предпочтительности формата, то есть, предполагая, что наш гипотетический формат является самым удобным для конкретных данных (иначе зачем было бы его изобретать?), пользовательский агент должен располагать альтернативу в простейшем формате первой, а самую размеченную последней. Агент получателя должен отобразить последнюю из понимаемых им альтернатив. В случае, если одна из альтернатив сама имеет тип ‘multipart’ и содержит подчасти неизвестных типов, пользовательский агент может выбрать, показывать ли эту альтернативу, предыдущую или обе.

    ЗАМЕЧАНИЕ: С точки зрения программиста, может показаться более удобным располагать альтернативы в обратном порядке, но данный порядок позволяет устаревшим не-MIME’овским почтовым программам отобразить в первую очередь наиболее понятный вариант.

    ЗАМЕЧАНИЕ ПО СЕМАНТИКЕ ПОЛЯ ‘CONTENT-ID’ В ПИСЬМЕ MULTIPART/ALTERNATIVE: Рекомендуется, чтобы каждая часть имела уникальное значение поля Content-ID в случае, если содержимое этих частей не является идентичным. Однако, там, где содержащаяся информация идентична (например, если несколько частей типа «application/external- body» определяют альтернативные пути доступа к одним и тем же внешним по отношению к письму данным), должно использоваться одно и то же значение Content-ID, чтобы оптимизировать работу кэширующего механизма на системе получателя. Однако, не рекомендуется, чтобы значения Content-ID, использующиеся для частей, отличались от значения Content-ID, использующегося в заголовке верхнего уровня, если такое поле в нем присутствует.

    7.2.4. Подтип «multipart/digest»

    Этот подтип идентичен подтипу ‘multipart/mixed’, но имеет другую семантику. Например, для ‘digest’ значением по умолчанию является не «text/plane», а «message/rfc822».

    В соответствии с этим подтипом, письмо-дайджест может выглядеть следующим образом:

    7.2.5. Подтип «multipart/parallel»

    Отличие этого подтипа от «multipart/mixed», в частности, состоит в том, что порядок расположения частей письма не принципиален.

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

    7.2.6. Другие подтипы типа «multipart»

    В будущем ожидается введение новых подтипов. Программистам рекомендуется интерпретировать незнакомые подтипы типа ‘multipart’ аналогично «multipart/mixed».

    Формальный синтаксис поля Content-Type для данных типа «multipart»:

    Полный пример Multipart-письма

    Данный пример иллюстрирует письмо из пяти частей: две — простой текст, одна — вложенное multipart-письмо, одна — размеченный текст и одна — вложенное письмо, содержащее текст в не-US-ASCII языковой кодировке. Третья часть (вложенное multipart-письмо) состоит из двух частей, требующих параллельного представления пользователю, — графическое изображение и звуковой фрагмент.

    7.3. Тип ‘message’

    При пересылке почты часто возникает необходимость включить внутрь письма другое письмо. Для этого и используется тип ‘message’.

    Основной подтип — «rfc822» — не требует параметров в поле Content-Type. Дополнительные подтипы — «partial» и «External-body» — предполагают наличие параметров.

    ЗАМЕЧАНИЕ: Для перенаправляемой и возвращаемой почты можно было бы определить отдельные подтипы, однако, такая почта может пересылаться как multipart-письмо, в котором первая часть содержит некоторую пояснительную текстовую информацию, а другая, имеющая тип ‘message/rfc822’, содержит перенаправляемое/возвращаемое письмо. Подобный способ перенаправления/возвращения почты сохраняет информацию о типе оригинального письма и позволяет ему быть корректно представленным получателю, и поэтому настоятельно рекомендуется.

    7.3.1. Основной подтип ‘message/rfc822’

    Этот подтип указывает, что тело письма содержит вложенное письмо в стандарте RFC 822, однако, в отличие от заголовка RFC 822 верхнего уровня, для каждой части, являющейся письмом RFC 822, не требуется наличия полей «From», «Subject» и, по крайней мере, одного поля «To».

    Не смотря на использование числа «822», тело, имеющее подтип ‘message/rfc822’, может включать дополнительную информацию в соответствии со стандартом MIME. Другими словами, письмо ‘message/rfc822’ может быть MIME-письмом.

    7.3.2. Подтип ‘message/partial’

    Этот подтип определен с целью обеспечения возможности пересылки очень больших объектов в виде нескольких раздельных частей, автоматичски «склеиваемых» почтовой программой получателя. Этот механизм может пригодиться, когда промежуточные почтовые шлюзы ограничивают индивидуальный размер пересылаемых писем. Т.о., этот подтип говорит о том, что письмо содержит лишь часть большого послания.

    Для этого подтипа необходимо указание трех параметров:

    1. «id» — уникальный идентификатор, позволяющий обнаружить остальные части послания.
    2. «number» — целое число, означающее номер части послания.
    3. «total» — целое число, означающее общее количество частей. Требуется лишь в последней части и не обязателен (хотя рекомендуется) для предыдущих частей. Эти параметры могут следовать в произвольном порядке.

    Пример: часть 2 3-х частного послания имеет следующие варианты заголовка:

    Но часть 3 обязательно должна содержать параметр «total»:

    Необходимо заметить, что нумирация частей начинается с 1, а не с 0.

    Когда подобным образом разбитые части собираются вместе, они образуют полное MIME-письмо, содержимое которого может иметь любой другой тип и, соответственно, свое поле заголовка Content-Type, описывающее этот тип.

    Семантика partial-письма должна быть та же, как в обычном письме с содержимым данного типа, а не как в письме, содержащем «внутреннее» письмо. Это позволяет, например, переслать большой аудио-файл ввиде нескольких более мелких, остающихся, тем не менее, видимыми получателю как обычные аудио-письма, а не как вложенные аудио-письма.

    При «сборке» таких посланий в пункте назначения должны учитываться следующие правила:

    (1) Все поля заголовка части 1, кроме начинающихся с «Content-» и специальных «Message-ID», «Encrypted» и «MIME-Version» должны быть скопированы в заголовок нового (общего) письма.

    (2) Только поля заголовка ВЛОЖЕННОГО письма, начинающиеся с «Content-«, а также поля «Message-ID», «Encrypted» и «MIME-Version», должны быть добавлены к заголовку нового общего письма, все остальные поля должны игнорироваться.

    (3) Заголовки второй и последующих частей целиком игнорируются.

    Например, если письмо с аудио-данными было разбито на две части, первая из них может выглядеть следующим образом:

    А вторая может выглядеть так:

    From: Bill@host.com To: joe@otherhost.com Subject: Audio mail MIME-Version: 1.0 Message-ID: Content-type: message/partial; ; number=2; total=2 . здесь имеет место быть вторая часть закодированных аудио-данных .

    После того, как расколотое послание воссоздано заново для отображения получателю, оно должно выглядеть следующим образом:

    Замечание по кодированию тела MIME-письма, заключенного внутри тела message/partial: так как данные типа «message» никогда не могут быть кодированы в Base64 или Quoted-Printable, следующая проблема может возникнуть в случае, если тела писем типа message/partial созданы в системе, поддерживающей 8-битный транспорт. Двоичные данные будут разбиты на несколько message/partial-объектов, каждому из которых требуется транспортировка в двоичном виде. Если бы таким объектам пришлось пройти через шлюз в 7-битную транспортную среду, их невозможно было бы перекодировать в сеимбитную форму без ожидания прибытия всех частей послания, собирания их воедино и затем кодирования целого послания в 7-битную кодировку (base64 или quoted-printable). Поскльку существует вероятность, что разные части пойдут разными путями (через различные шлюзы), то подобное решение не приемлимо. Поэтому MIME определяет, что письма типа message/partial должны иметь 7-битную кодировку и соответствующее ей значение поля content-transfer-encoding. Даже для систем с транспортом, поддерживающим «8-бит» и «binary», запрещается их использование для данных message/partial.

    Многие почтовые агенты могут автоматически фрагментировать большие письма.

    Включение поля «References» в заголовки второй и последующих частей, ссылающегося на идентификатор предыдущей части, может оказаться полезным для почтовых программ, понимающих и обрабатывающих ссылки. Однако, наличие этого поля не обязательно.

    Поле заголовка «Encrypted» вышло из употребления, но вышеприведенные правила обеспечивают корректную его интерпретацию, если оно встречается при обработке фрагментов типа message/partial.

    7.3.3. Подтип ‘Message/External-Body’

    Письмо (часть письма) этого подтипа состоит из заголовка, двух последовательных концов строки и заголовка вложенного письма. Если встречается другая пара концов строки, она означает конец заголовка вложенного письма. Однако, поскольку тело вложенного письма является внешним, оно не следует за концом заголовка. Например,

    Область в конце, которую можно назвать «призрачным телом», игнорируется для большинства писем подтипа ‘external-body’. Однако, в нее можно помещать дополнительную информацию, как например, в случае, когда параметр ‘access-type’ равен «mail-server». Во всех остальных случаях призрачное тело игнорируется.

    Единственный всегда обязательный параметр для ‘message/external-body’ — «access-type». Остальные параметры могут быть или не быть обязательными в зависимости от значения параметра «access-type».

    Значение этого параметра — слово, нечувствительное к регистру букв, означающее механизм доступа, с помощью которого файл или данные могут быть получены. Значения могут быть следующими (но не ограничиваются этим рядом): «FTP», «ANON-FTP», «TFTP», «AFS», «LOCAL-FILE» и «MAIL-SERVER». Будущие возможные значения, кроме экспериментальных, начинающихся с «X-«, должны быть зарегистрированы в IANA.

    Дополнительно, следующие три параметра являются необязательными для всех способов доступа:

    EXPIRATION — Дата (RFC 822 «date-time» синтаксис допускает 4 цифры в этом поле), после которой существование внешних данных не гарантируется.

    SIZE — размер (в байтах) данных. Позволяет получателю решить, расходовать ли ресурсы на считывание внешних данных. Размер указывается для канонической формы данных (то есть, до применения каких-либо преобразований).

    PERMISSION — нечувствительное к регистру букв поле, говорящее о том, ожидается или нет, что клиент может перезаписывать данные. По умолчанию или когда этот параметр имеет значение «read», полагается, что клиент не имеет на это права, и что если данные однажды считаны, то больше они не понадобятся. Если PERMISSION имеет значение «read-write», любая локальная копия может рассматриваться не более как кэш. «read» и «write» — единственные предопределенные значения для PERMISSION.

    Вложенные заголовки во ВСЕХ телах типа message/external-body ДОЛЖНЫ включать поле заголовка Content-ID для задания уникального идентификатора, указывающего на внешние данные.

    Обозначения, описывающие данные типа external-body, такие как имена файлов или команды mail-сервера, должны быть в символьном наборе US-ASCII.

    Как и для типа message/partial, тело типа message/external-body должно иметь значение content-transfer-encoding «7-bit» (по умолчанию). В частности, даже в системах, поддержиавющих 8-битный транспорт, применение content-transfer-encoding «8-bit» и «binary» запрещено для данных типа message/external-body.

    7.3.3.1. Типы доступа «ftp» и «tftp»

    Тип доступа по FTP или TFTP означает, что тело сообщения доступно как внешний файл по протоколу FTP [RFC-959] или TFTP [RFC-783] соответственно. Для этих типов доступа обязательны следующие дополнительные параметры:

    NAME — Имя файла, содержащего данные тела письма.

    SITE — Полный доменный адрес или псевдоним компьютера, с которого файл может быть получен по указанному протоколу.

    Перед тем, как начнется считывание данных по FTP, пользователь обычно должен быть спрошен на предмет логина и пароля для машины, указанной в параметре ‘site’. По причинам безопасности логин и пароль не указываются как параметры Content-Type и должны быть получены от получателя письма.

    Дополнительно определены следующие необязательные параметры:

    DIRECTORY — каталог, содержащий тело письма на удаленной машине.

    MODE — Нечувствительное к регистру букв строка, указывающая режим передачи данных. Допустимые эначения для типа доступа TFTP:

    NETASCII, OCTET и MAIL . Для типа доступа FTP: ASCII, EBCDIC, IMAGE и LOCALn, где n — десятичное целое число, обыч- но 8. Эти значения соответствуют типам представления A, E, I и Ln , определенным FTP-протоколом. Заметьте, что «BINARY» и «TENEX» не являются допустимыми значениями для параметра MODE. Вместо них должны использоваться «OCTET», «IMAGE» или «LOCAL8». Если параметр MODE отсутствует, значением по умолчанию является «NETASCII» для TFTP и «ASCII» для FTP.

    7.3.3.2. Способ досупа «anon-ftp»

    Этот способ доступа идентичен «ftp», за исключением того, что пользователю не требуется указывать свой логин и пароль для удаленной машины. FTP-протокол будет использоваться с логином «anonymous» и email-адресом получателя вместо пароля.

    7.3.3.3. Способы доступа «local-file» и «afs»

    Способ доступа «local-file» означает, что тело письма доступно как файл на локальной машине. «afs» означает, что тело доступно как файл через общую файловую систему AFS. В обоих случаях требуется единственный обязательный параметр:

    NAME — Имя файла, содержащего данные тела письма.

    Следующий необязательный параметр может быть использован для локализации ссылки на файл и содержит адрес сайта или сайтов, на которых данный файл виден:

    SITE — Доменный адрес машины или машин, на которых возможен доступ к файлу данных. Допускаются маски с использованием звездочки вместо части доменного имени, например, «*.bellcore.com», для обозначения набора машин, на которых файл виден напрямую. Единственная звездочка вместо всего доменного имени может означать, что файл, где би он ни был, виден через глобальную файловую систему.

    7.3.3.4. Способ доступа «mail-server»

    Применяется, когда тело письма доступно через почтовый сервер. Обязательный параметр для этого способа доступа:

    SERVER — email-адрес mail-сервера, с которого могут быть запрошены данные тела письма.

    Так как почтовые серверы предполагают множество различных синтаксисов, некоторые из них могут быть многострочными, полная команда, которую нужно послать на mail-сервер, не включается как параметр в однострочное поле ‘content-type’. Вместо этого она помещается в мнимое тело, когда значением поля ‘content-type’ является ‘message/external-body’, и параметр ‘access-tyoe’ имеет значение ‘mail-server’.

    Необязательный параметр для этого способа доступа:

    SUBJECT — Subject, который будет использован в заголовке письма-запроса, которое почторый клиент получателя пошлет на указанный почтовый сервер для получения данных тела письма. Заметьте, что помещение адреса сервера в subject не рекомендуется, однако, известны mail-серверы, требующие этого.

    MIME-стандарт не определяет синтаксиса обращения к почтовому серверу. Поэтому он допускает включение полной команды для mail-сервера в мнимое тело.

    В отличие от других способов доступа, доступ через mail-сервер не синхронен, и данные могут быть получены в непредсказуемый момент в будущем. По этой причине важно иметь механизм, обеспечивающий вставку полученных от mail-сервера данных в исходное письмо. Mail-сервер при отправке запрошенных данных должен использовать то же самое значение поля Content-ID в заголовке письма с возвращаемыми данными, какое было в первоначальном «бестелесном» письме, чтобы облегчить работу этого механизма.

    7.3.3.5. Примеры и дополнительные пояснения

    С появлением возможности очень широких (протяженных) файловых систем стало непредсказуемым, на каком наборе машин файловой системы данный файл будет доступен напрямую, а на каком — нет. Поэтому, имеет смысл указывать как имя файла, так и сетевой адрес (адреса) машин, на которых файл доступен.

    Если внешнее тела письма доступно посредством нескольких различных механизмов, отправитель может включить несколько частей типа message/external-body в письмо типа multipart/alternative.

    Однако, механизм external-body не должен быть ограничен получением удаленных файлов. Например, можно представить использование видеосервера с внешними ссылками на видеофрагменты.

    Если письмо / часть письма имеет тип «message/external-body», то оно / она будет содержать поля заголовка вложенного письма. Тело само по себе неходится где-либо во вне. Это значит, что если тело типа «message/external-body» содержит два последовательных конца строки (CRLF), то все, что идет далее, не является чстью сообщения и просто должно игнорироваться. Однако, этот «хвост» — удобное место для каких-либо дополнительных данных, которые не могут быть помещены в поле заголовка Content-Type. В частности, если значение «access-type» есть «mail-server», то «хвост» может содержать команды, посылаемые затем mail-серверу по адресу, на который указывает параметр SERVER.

    Поля заголовка вложенного письма, которые на самом деле являются телом общего письма типа «message/external-body», должны нести информацию о типе содержимого внешнего (удаленного) тела, если оно не является простым ASCII-текстом (что подразумевается по умолчанию), поскольку эти внешние данные сами по себе не имеют заголовка, опрпеделяющего их тип. Также, необходимо указывать Content-transfer-encoding, если он имеет значение, отличное от «7-bit». Так, полное письмо типа message/external-body, ссылающееся на документ в формате PostScript, может выглядеть следующим образом:

    В приведенных примерах значение Content-transfer-encoding для внешних данных в формате postscript полагается по умолчанию как «7bit».

    Заголовки общего и вложенного(их) писем (имеющих внешнее тело) должны удовлетворять тем же правилам, что и для типа message/partial во избежание путаницы.

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

    Тело письма типа «message/external-body» обрабатывается в сответствии с основным синтаксисом стандарта RFC 822, в частности, все, что идет до первой последовательной пары концов строки (CRLF), является заголовком письма, а все, что идет после, является «мнимым» телом письма, которое игнорируется для большинства типов доступа.

    Формальный синтаксис поля заголовка ‘content-type’ для данных типа ‘message’ — следующий:


    7.4. Тип ‘Application’

    Этот тип используется для данных, неподпадающих под остальные категории, в частности, для данных, обрабатываемых прикладными почтовыми программами. Это информация, которая должна быть обработана соответствующим приложением для того, чтобы принять наглядную либо исполняемую для получателя форму. Предполагаемое использование для этого типа включает в себя пересылку файлов по почте, таблицы, данные для почтовых систем расписания, языки лдя «активной» (вычислительной) почты. (Последняя, в частности, может поднять проблемы безопасности, которые должны быть поняты разработчиками ПО и рассмотрены ниже в параграфе «Application/PostScript»).

    Например, тот, кто занимается расписанием встреч, может определить стандартное представление информации о датах запланированных встреч. «Умный» пользовательский почтовый агент может использовать эту информацию для проведения диалога с пользователем, и может затем посылать в дальнейшем почту, основанную на том диалоге. Вообще, существует несколько «активных» почтовых языков, разработанных для специализированных программ, которые посылаются по почте и автоматчески запускаются в системе получателя.

    Подобные приложения могут быть определены как подтипы для типа «application». Изначально предопределено два подтипа: «octet-stream» и «PostScript».

    В общем, подтип для ‘application’ зачастую может быть именем приложения, для которого предназначены пересылаемые данные. Однако, это не означает, что любое имя прикладной программы может свободно использоваться как подтип для ‘application’. Такие употребления (кроме подтипов, начинающихся с «x-«) должны быть зарегестрированы в IANA.

    7.4.1. Основной подтип ‘Application/Octet-Stream’

    Используется для обозначения того, что тело содержит бинарные данные. Набор возможных параметров включает следующие (но не ограничивается ими):

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

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

    Дополнительный параметр, «conversions», определенный в [RFC-1341], был исключен в последствии.

    В RFC 1341 также определен параметр «NAME» , указывающего имя файла, которое должно быть использовано при сохранении данных на диск. Но он опять же был отменен в ожидании введения отдельного поля заголовка Content-Disposition, которое будет определено в ближайшем будущем.

    Рекомендуемое действие для почтовой программы, получившей почту типа application/octet-stream, — просто предложить записать данные в файл без какого-либо преобразования, или. возможно, произвести его в соответствии с указанием пользователя.

    Для уменьшения опасности передачи вирусных и других намеренно разрушающих систему программ по почте, строго рекомендуется, чтобы почтовая программа получателя не производила запуск программы, заданной в параметре поля «Content-Type» (например, в параметре «interpreter=»), использующей в качестве входных данных тело письма.

    7.4.2. Подтип ‘Application/PostScript’

    Тип «application/postscript» означает, что пересылается PostScript-документ и требует специальной программы для его обработки. В настоящий момент используются два языка — level 1 и более поздний — level 2.

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

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

    7.4.3. Другие подтипы типа Application

    Ожидается, что многие подтипы типа ‘Application’ будут введены в будущем. MIME-совместимые почтовые программы должны интерпретировать любой незнакомый им подтип как эквивалент ‘application/octet-stream’.

    Формальный синтаксис дла поля ‘content-type’ для данных типа ‘application’ дается следующим образом.

    7.5. Тип ‘Image’

    Этот тип означает, что тело письма содержит графический объект. Его подтипы соответствуют конкретным графическим форматам. Их значения нечувствительны к регистру букв. Два предопределенных подтипа — «jpeg» для формата JPEG с кодированием JFIF, и «gif» — для формата GIF.

    Формальный синтаксис поля ‘Content-Type’:

    7.6. Тип ‘Audio’

    Этот подтип означает, что тело содержит аудио-данные. Хотя пока еще нет консенсуса по «идеальному» аудио-формату для компьютеров, сейчас имеется сильная потребность в универсальном формате.

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

    Содержимое тела, имеющего подтип «audio/basic», — аудио-данные в 8-битной форме, кодированные с использованием ISDN mu-law. Формат, соответствующий этому подтипу, предполагает максимальную частоту звучания 8000 Hz и единственный канал.

    Формальный синтаксис лдя поля ‘Content-Type’:

    7.7. Тип ‘Video’

    Этот тип означает, что в теле письма содержится анимационное изображение, возможно, со звуком и цветом. Термин «video» используется безотносительно к технологии получения подвижного во времени изображения. Подтип «mpeg» указывает на видео, кодированное в соответствии со стандартом MPEG.

    Хотя MIME-стандарт запрещает смешение разнородных мультимедийных данных в одном теле (письма или части письма), многие так называемые «video»-форматы включают синхронизированный звук, что допускается для подтипов типа «video».

    Формальный синтаксис лдя поля ‘Content-Type’:

    7.8. Экспериментальные значения поля ‘Content-Type’

    Значение типа, начинающееся с «X-«, считается частным, предназначенным для использования по договоренности между двумя или более почтовыми системами. Публично определенные (регестрированные) значения никогда не должны начинаться с префикса «X-«.

    В общем, использование X-типов верхнего уровня не рекомендуется. Производители почтового ПО должны по возможности обходиться использованием X-подтипов для предопределенных типов. Во многих случаях использование экспериментального подтипа более приемлимо, нежели типа верхнего уровня.

    Все определенные на сегодняшний день типы и подтипы

    ТИП ПОДТИП
    text plain
    richtext
    enriched
    tab-separated-values
    multipart mixed
    alternative
    digest
    parallel
    appledouble
    header-set
    message rfc822
    partial
    external-body
    news
    application octet-stream
    postscript
    oda
    atomicmail
    andrew-inset
    slate
    wita
    dec-dx
    dca-rft
    activemessage
    rtf
    applefile
    mac-binhex40
    news-message-id
    news-transmission
    wordperfect5.1
    pdf
    zip
    macwriteii
    msword
    remote-printing
    image jpeg
    gif
    ief
    tiff
    audio basic
    video mpeg
    quicktime

    Значения полей Content-Type и subtype, а также другие параметры заголовка являются чувствительными к регистру букв, если только не оговорены исключения для конкретного значения параметра.

    Применение возможностей MIME в транспортных почтовых системах

    Хотя новые возможности, предоставляемые MIME, ориентированы в основном на пользовательские почтовые программы, однако, транспортные системы тоже могут воспользоваться преимуществами MIME.

    Усилия создателей MIME были максимально сфокусированы на том, чтобы не требовать абсолютно никаких изменений на уровне транспортировки сообщений. Потому почта в MIME-формате проходит прозрачно на всех интернет- и интернет-подобных системах. То есть, при разработке и установке почтовых транспортов можно (хотя и не обязательно) полностью игнорировать существование MIME. Однако, MIME предоставляет некоторые возможности, которые могут быть полезными ответственным за транспортные услуги лицам. Используя эти возможности, транспортные системы могут обеспечить дополнительные виды услуг, недоступных в настоящее время недоступных, но могущих смягчить существующие проблемы.

    Чтобы заниматься реализацией любого из механизмов, описанных ниже, необходимо ознакомиться с отличием между службой почтового транспорта и шлюзовой службой. В основном, почтовый транспорт ответственен за перемещение почтовых сообщений в пределах пространства почтовых сетей, подобных друг другу. С другой стороны, почтовые шлюзы совершают обмен почтой между двумя принципиально отличными почтовыми пространствами, в том числе и через неэлекторнные службы (как бумажная почта, например).

    Общеполагается для почтовых транспортных систем неприемлимым изменять содержимое сообщений. В случае почтовых шлюзов, изменения зачастую неизбежно. Таким образом, многие из механизмов, описаных ниже, применяются только к шлюзам, и не должны использоваться в простых транспортных системах. Однако, возможно, что в некоторых специфических ситуациях (таких как в случае SMTP-соединений через межконтинентальную связь) может потребоваться изменять содержимое для обеспечения приемлимого обслуживания для таких ситуаций, и потому такой почтовый транспорт должен считаться уже фактически шлюзом. То есть, почтовые транспорты, которые намерены использовать описанные ниже функции, должны переклассифицировать себя как шлюзы.

    1. Непринятая почта

    К сожалению частой обязанностью транспортных служб является отсылка почты обратно отправителю. Такое может произойти, если почту невозможно доставить или если она не удовлетворяет требованиям шлюза (слишком большой объем, например).

    Раньше не было стандартных правил для отказа от принятия почтовых сообщений. Это было досадной, но не главной проблемой для текстовых сообщений. Для нетекстовых, однако, недостаток в стандартном формате отказа от приема является более критичным, потому что типично возвращенные пиьсма представляются их отправителю как текст, и пользователь, просматривающий картинку или звук, как если бы они были текстом, редко бывает счастлив от этого.

    MIME позволяет легко инкапсулировать письма в том смысле, что полностью сохраняется их семантика. Простейший путь добиться этого — каждое возвращаемое письмо помещать в тело письма с типом «multipart/mixed», которое содержало бы две части — текстовую, содержащую пояснение причины отказа в принятии оригинального письма и вложение самого этого письма.

    Подчеркивается, что транспорные программы вообще не нуждаются в распознавании структуры возвращаемого письма. От них лишь требуется правильно вложить его. Следующий пример показывает, как любое MIME-письмо может быть вложено (инкапсулировано) в письмо возврата так, что вся информация в нем будет корректно воспроизведена, если получатель (он же первый отправитель) будет читать его с помощью MIME-ориентированной почтовой программы:

    В данном примере единственная вещь, которая не берется из стандартного набора фраз, это выбор метки границы. Фраза «unique-boundary» должна быть заменена строкой, не появляющейся ни в одной из частей сообщения.

    ВАЖНО: Формат, приведенный выше, — лишь один из возможных путей отсылки непринятых писем с использованием MIME.

    2. Разбиение (фрагментация) и сборка больших писем

    Одна из проблем, встречающихся все чаще и чаще в Internet-почте, возврат писем из-за ограничений по их объему. Особенный рост этой проблемы обусловлен расширением использования MIME, так как MIME позволяет посылать очень большие объекты, такие как звук, видео, графику. К счастью, MIME также обеспечивает механизмы, которые могут помочь ослабить эту проблему.

    В частности, к ним относится MIME-тип «message/partial», который можно использовать для автоматического разбиения и сборки больших писем. Эта функция может поддерживаться полностью как на уровне пользовательских почтовых агентов, так и транспортными службами, которые могут его использовать для обеспечения полее разумного поведения при шлюзовании почты.

    Ниже приводится пример, показывающий, как простое коротенькое письмо может быть разбито на два письма типа «message/partial». На практике, конечно, данное свойство разумно применять лишь для очень больших писем.

    может быть обратимо преобразовано в следующие два message/partial- -письма:

    Фрагментирование таких писем, вместо их отсылки обратно, было бы вполне обусловлено для применения шлюзовыми службами. Конечно, шлюзу часто неизвестны ограничения по размеру в другой системе, но разумные предположения всегда возможны.

    Фрагментирование и сборка писем могут быть выполнены, в зависимости от обстоятелств, как отправляющей, так и принимающей системой, в зависимости от того, какая из них знает больше о способностях другой.

    3. Использование или удаление указателей External-Body (внешнего тела)

    Другой MIME-тип, ориентированный на слишком большие письма, это «message/external-body». Он обеспечивает почтовым транспортным службам, оптимизировать почтовый траффик в своей системе. Однако, когда почта пересекает медленный и дорогой участок, например, звено спутниковой связи через Тихий океан, может иметь смысл считать указываемые данные и передать их в качестве действительного тела письма, либо скопировать в новое, более доступное место, соответствующим образом изменив ссылку в заголовке письма. Поскольку спецификация данного типа допускает наличие даты аннулирования ресурса, почтовый транспорт может идти на компромисс между пропускной способностью своей системы и ее дисковым пространством, отданным под хранение внешних данных писем, чтобы оптимизировать использование этих внешних данных.

    Такое поведение требует осторожного анализа соотношения затрат и выгоды. Однако, потенциальные выгоды очевидны, так что разумное использование таких возможностей не повредит.

    Например, приведенное ниже письмо содержит ссылку на внешние PostScript-данные:

    Этот пример предполагает как выгоду (немедленно доступные получателю данные), так и возможные затраты (если список рассылки велик, то письмо придется разослать всем, хотя только некотоые из получателей обратились бы за данными письма в ближайшее время).

    Кроме того, вместо замены ссылки на внешние данные их натуральным включением в письмо, можно трансформировать оригинальное письмо в письмо типа «multipart/alternative», содержащее как ссылку на внешние данные, так и копию этих данных. Это означает, что при перенаправлении письма другому пользователю перенаправлена будет только та часть, которая содержит ссылку. Кроме того, получатель, хоть и получит данные сразу целиком, все равно не потеряет информацию о местоположении оригинального ресурса, и при необходимости сможет скачать более новую его версию в будущем. Это иллюстрируется следующим примером:

    Аналогично, в случае, когда внешние данные копируются транспортной системой на локальный FTP, можно сделать в письме две части типа ‘external-body’, что позволит получателю выбрать, с какого из FTP предпочтительнее забирать тело письма.

    4. Преобразование графических и других форматов

    В настоящее время MIME определяет два графических формата — image/gif и image/jpeg. Первый — более удобен для многих пользователей, понятен многим системам, и отображается довольно быстро. Последний гораздо более компактен и потому менее сказывается на увеличении траффика.

    Почтовые транспортные системы могут оптимизировать и траффик, и удобства получателей разумной трансляцией этих форматов (а также других, которые могут быть добавлены в будущем). Если письмо типа image/gif пересылается на длинную дистанцию, оно может быть перетранслировано в image/jpeg. Когда же данные типа image/jpeg получены системой, в которой находится получатель, для конечной доставки, они снова могут быть перетранслированы в GIF для удобств получателя.

    Подобные преобразования форматов также рекомендуются и для аудио-данных.

    Если преобразование выполнено, настоятельно рекомендуется добавлять каким-либо образом (например, в поле заголовка Received) информацию об истории преобразований документа, в письме содержащегося.

    Однако, трансляция форматов обычно ограничивается шлюзовыми службами и менее предпочтительна для обычных транспортных служб. Причем, те службы, которые выполняют преобразования, должны распознавать поле Conterent-Conversion, в котором отправитель может разрешить либо запретить любые преобразования форматов данных, поскольку многие пользователи принципиально неприемлют преобразования, так как считают, что при некоторые из них могут привести к ухудшению качества документа:

    По умолчанию (если это поле отсутствует) предполагается значение ‘permitted’.

    5. Надежное кодирование данных

    В некоторых случаях при прохождении через шлюз данные могут не сохранить своего вида к следующему шагу транспортировки. К примеру, почта проходящая через шлюз ASCII -> EBCDIC, может потерять информацию, содержащую некоторые спецсимволы. В подобных случаях шлюз может обеспечить данным сохранность, применив один из MIME-алгоритмов — base64 или quoted-printable к телу письма или его части. Это, как правило, трансформация без потерь, но необходимо добиться, чтобы результирующее письмо целиком отвечало стандарту MIME, даже если изначально оно таковым не было (в частности, должно быть добавлено поле заголовка MIME-Version).

    Блог Vaden Pro

    • 1193 просмотра

    Характеристика значения

    Общее определение

    На сегодняшний день очень популярен обмен сообщениями в сети интернет. Начало этому положила электронная почта, которая стала праотцом для социальных сетей, в которой молодежь днем и ночью обменивалась сообщениями.

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

    Управление и контроль этим процессом осуществляется благодаря Многоцелевым расширениям почты Интернета (сокращенно MIME от английского языка).

    MIME – особый список данных и расширений для них, с помощью которых осуществляется пересылка информации в сети Интернет различного вида. Касательно языка программирования HTML, данная спецификация используется для управления отправкой форм и других информационных объектов, с возможностью их размещения на веб странице.

    Перечень MIME-типов

    Тип файла Тип данных
    ai application/postscript
    aif audio/aiff
    aif audio/x-aiff
    aiff audio/aiff
    aiff audio/x-aiff
    ani application/x-navi-animation
    aos application/x-nokia-9000-communicator-add-on-software
    aps application/mime
    arc application/octet-stream
    arj application/arj
    arj application/octet-stream
    art image/x-jg
    asf video/x-ms-asf
    asm text/x-asm
    asp text/asp
    asx application/x-mplayer2
    asx video/x-ms-asf
    asx video/x-ms-asf-plugin
    au audio/basic
    au audio/x-au
    avi application/x-troff-msvideo
    avi video/avi
    avi video/msvideo
    avi video/x-msvideo
    bin application/mac-binary
    bin application/macbinary
    bin application/octet-stream
    bin application/x-binary
    bin application/x-macbinary
    bm image/bmp
    bmp image/bmp
    bmp image/x-windows-bmp
    boo application/book
    book application/book
    c text/x-c
    c++ text/plain
    ccad application/clariscad
    class application/java
    class application/java-byte-code
    class application/x-java-class
    com application/octet-stream
    com text/plain
    conf text/plain
    cpp text/x-c
    cpt application/mac-compactpro
    cpt application/x-compactpro
    cpt application/x-cpt
    css application/x-pointplus
    css text/css
    dcr application/x-director
    def text/plain
    dif video/x-dv
    dir application/x-director
    dl video/dl
    dl video/x-dl
    doc application/msword
    dot application/msword
    drw application/drafting
    dvi application/x-dvi
    dwg application/acad
    dwg image/vnd.dwg
    dwg image/x-dwg
    dxf application/dxf
    dxf image/vnd.dwg
    dxf image/x-dwg
    dxr application/x-director
    exe application/octet-stream
    gif image/gif
    gz application/x-compressed
    gz application/x-gzip
    gzip application/x-gzip
    gzip multipart/x-gzip
    h text/plain
    h text/x-h
    hlp application/hlp
    hlp application/x-helpfile
    hlp application/x-winhelp
    htc text/x-component
    htm text/html
    html text/html
    htmls text/html
    htt text/webviewhtml
    ice x-conference/x-cooltalk
    ico image/x-icon
    inf application/inf
    jam audio/x-jam
    jav text/plain
    jav text/x-java-source
    java text/plain
    java text/x-java-source
    jcm application/x-java-commerce
    jfif image/jpeg
    jfif image/pjpeg
    jfif-tbnl image/jpeg
    jpe image/jpeg
    jpe image/pjpeg
    jpeg image/jpeg
    jpeg image/pjpeg
    jpg image/jpeg
    jpg image/pjpeg
    jps image/x-jps
    js application/x-javascript
    js application/javascript
    js application/ecmascript
    js text/javascript
    js text/ecmascript
    latex application/x-latex
    lha application/lha
    lha application/octet-stream
    lha application/x-lha
    lhx application/octet-stream
    list text/plain
    lsp application/x-lisp
    lsp text/x-script.lisp
    lst text/plain
    lzh application/octet-stream
    lzh application/x-lzh
    lzx application/lzx
    lzx application/octet-stream
    lzx application/x-lzx
    m3u audio/x-mpequrl
    man application/x-troff-man
    mid application/x-midi
    mid audio/midi
    mid audio/x-mid
    mid audio/x-midi
    mid music/crescendo
    mid x-music/x-midi
    midi application/x-midi
    midi audio/midi
    midi audio/x-mid
    midi audio/x-midi
    midi music/crescendo
    midi x-music/x-midi
    mod audio/mod
    mod audio/x-mod
    mov video/quicktime
    movie video/x-sgi-movie
    mp2 audio/mpeg
    mp2 audio/x-mpeg
    mp2 video/mpeg
    mp2 video/x-mpeg
    mp2 video/x-mpeq2a
    mp3 audio/mpeg3
    mp3 audio/x-mpeg-3
    mp3 video/mpeg
    mp3 video/x-mpeg
    mp4 video/mp4
    mpa audio/mpeg
    mpa video/mpeg
    mpeg video/mpeg
    mpg audio/mpeg
    mpg video/mpeg
    mpga audio/mpeg
    pas text/pascal
    pcl application/vnd.hp-pcl
    pcl application/x-pcl
    pct image/x-pict
    pcx image/x-pcx
    pdf application/pdf
    pic image/pict
    pict image/pict
    pl text/plain
    pl text/x-script.perl
    pm image/x-xpixmap
    pm text/x-script.perl-module
    pm4 application/x-pagemaker
    pm5 application/x-pagemaker
    png image/png
    pot application/mspowerpoint
    pot application/vnd.ms-powerpoint
    ppa application/vnd.ms-powerpoint
    pps application/mspowerpoint
    pps application/vnd.ms-powerpoint
    ppt application/mspowerpoint
    ppt application/powerpoint
    ppt application/vnd.ms-powerpoint
    ppt application/x-mspowerpoint
    ppz application/mspowerpoint
    ps application/postscript
    psd application/octet-stream
    pwz application/vnd.ms-powerpoint
    py text/x-script.phyton
    pyc applicaiton/x-bytecode.python
    qt video/quicktime
    qtif image/x-quicktime
    ra audio/x-pn-realaudio
    ra audio/x-pn-realaudio-plugin
    ra audio/x-realaudio
    ram audio/x-pn-realaudio
    rm application/vnd.rn-realmedia
    rm audio/x-pn-realaudio
    rpm audio/x-pn-realaudio-plugin
    rtf application/rtf
    rtf application/x-rtf
    rtf text/richtext
    rtx application/rtf
    rtx text/richtext
    rv video/vnd.rn-realvideo
    sgml text/sgml
    sgml text/x-sgml
    sh application/x-bsh
    sh application/x-sh
    sh application/x-shar
    sh text/x-script.sh
    shtml text/html
    shtml text/x-server-parsed-html
    ssi text/x-server-parsed-html
    tar application/x-tar
    tcl application/x-tcl
    tcl text/x-script.tcl
    text application/plain
    text text/plain
    tgz application/gnutar
    tgz application/x-compressed
    tif image/tiff
    tif image/x-tiff
    tiff image/tiff
    tiff image/x-tiff
    txt text/plain
    uri text/uri-list
    vcd application/x-cdlink
    vmd application/vocaltec-media-desc
    vrml application/x-vrml
    vrml model/vrml
    vrml x-world/x-vrml
    vsd application/x-visio
    vst application/x-visio
    vsw application/x-visio
    wav audio/wav
    wav audio/x-wav
    wmf windows/metafile
    xla application/excel
    xla application/x-excel
    xla application/x-msexcel
    xlb application/excel
    xlb application/vnd.ms-excel
    xlb application/x-excel
    xlc application/excel
    xlc application/vnd.ms-excel
    xlc application/x-excel
    xld application/excel
    xld application/x-excel
    xlk application/excel
    xlk application/x-excel
    xll application/excel
    xll application/vnd.ms-excel
    xll application/x-excel
    xlm application/excel
    xlm application/vnd.ms-excel
    xlm application/x-excel
    xls application/excel
    xls application/vnd.ms-excel
    xls application/x-excel
    xls application/x-msexcel
    xlt application/excel
    xlt application/x-excel
    xlv application/excel
    xlv application/x-excel
    xlw application/excel
    xlw application/vnd.ms-excel
    xlw application/x-excel
    xlw application/x-msexcel
    xm audio/xm
    xml application/xml
    xml text/xml
    z application/x-compress
    z application/x-compressed
    zip application/x-compressed
    zip application/x-zip-compressed
    zip application/zip
    zip multipart/x-zip

    В случае не определения одного из перечисленных форматов в спецификации файлу автоматически присвоится тип text/plain.

    Что касается файлов HTML, то они распознаются протоколом без особых проблем. Им присваивается расширением text/html. Особая ситуация возникает при отправке файла формата XHTML. Для использования всех возможностей такого файла необходимо указывать для файла расширение application/xhtml+xml. В противном случае файлу присвоится согласно протоколам MIME расширение файла HTML, то есть text/plain.

    Для примера рассмотрим работу с сервером Apache. Используем особую команду для работы в корневой папке сайта в файле .htaccess. Запись будет выглядеть следующим образом

    Запись для работы с языком PHP выглядит несколько иначе. В заголовок записывается конструкция следующего плана

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

    Internet Explorer версией не выше 9.0 не может распознать документы типа application/xhtml+xml. остальные версии этого браузера считывают эту запись нормально, в том числе и все остальные браузеры.

    Также не стоит злоупотреблять использования файла такого типа. Он станет полезным только если используется математическая символика MathML. Также такой формат будет очень полезен при использовании модуля графиков-векторов — SVG. В противном случае рациональней ограничиться файлом HTML, который расширит число браузеров, которые без проблем считают информацию с вашего веб-ресурса.

    Также стоит отметить еще одну важную особенность работы MIME. Она заключается в том, что протокол позволяет осуществлять передачу файлов с несколькими вложениями. Проще говоря, позволяет осуществить передачу папки внутри которой находится еще несколько папок с файлами разнообразных форматов.

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

    Интересный факт про историю развития MIME-протокола.

    Правообладатели MIME были очень удивлены и восторженны после того, как получили письмо от создателя протокола IMAP – Марка Криспина. Он прислал им письмо форматом mbox в качестве проверки MIME-протокола. По словам представителей MIME, это было сумасшедшее письмо с тридцатью вложенными друг в друга составляющими частями. Однако, они также отметили, что это лучшая проверка для протокола MIME.

    Солянка сборная от wmas


    Как определить MIME-тип файлы средствами PHP?

    Что такое MIME-тип файла? Как определить MIME-тип файла средствами PHP? Как установить модуль Fileinfo и настроить локальный сервер, сборка Денвер.

    Учи матчасть

    Как таковой, определение MIME-типа того или иного файла строится на основе его (файла) расширения. Как вы понимает, это достаточно условное определение MIME-типа. Например, файлу image.jpg (даже будь он чем-то иным), по расширению jpg, будет определён MIME-тип: image/jpeg. Конечно, можно проанализировать содержание файла и на его основе определить правильный MIME-тип, но данное решение не входит в рамки моей заметки.

    Главное, что сейчас нужно понять, так это необходимость наличия серверного magic.mime файла, где описываются MIME-типы. Как таковой, он входит в состав PHP. Бывает, что и в папках сервера Apache можно найти этот файл. В общем, кто ищет, тот найдёт. По идее, узнать, где находится magic.mime можно считав значение опции mime_magic.magicfile из php.ini. Например:

    Однако у меня эта опция ничего не возвращает, тем не менее – попробуйте.

    Следует отметить, для того, чтобы определить MIME-тип файла, в PHP имеется модуль Fileinfo. Другими словами, вы всегда можете сориентироваться, имеется ли у вас возможность что-то узнать или нет, по наличию этого модуля. Например:

    Так что если модуль есть, то есть и шанс, что оно всё будет работать. В крайнем случае, можно указать путь к своему magic.mime файлу.

    Практика

    Самым простым способом определения MIME-типа файла средствами PHP является использование php-функции mime_content_type() из модуля Fileinfo. Например:

    В результате мы должны получить строку: image/jpeg. Конечно, если файл image.jpg — существует, модуль Fileinfo подключен и magic.mime доступен.

    Обратите внимание, что значение функции mime_content_type() должно представлять собой полный путь и имя файла, для чего я использовал конструкцию dirname(__FILE__) . ‘image.jpg’ . Также следует помнить, что эта функция считается устаревшей (англ. deprecated) и в дальнейшем будет исключена из PHP. Альтернативой может служить решение, написанное с использованием php-функций из того же Fileinfo модуля:

    Здесь, функция finfo_open() создаёт Fileinfo ресурс ($finfo). С учётом константы FILEINFO_MIME_TYPE , доступной в PHP версии не ниже 5.3.0, мы сможем получить MIME-тип файла(-ов).

    Думаю, уже понятно, что php-функция finfo_file() , используя Fileinfo ресурс ($finfo), возвращает нам информацию для указанного файла ($filename). В нашем случае это MIME-тип: image/jpeg.

    Ну и если всё выше сказанное не принесло результата, можно написать свой парсер. Здесь тоже много вариантов. Одним из таковых является парсер magic.mime файла. Не важно где он находится, главное чтоб он был.

    Думаю, расписывать, что да как здесь не имеет смысла – и так всё более чем понятно. Хочу лишь обратить ваше внимание на указанный мной путь к файлу mime.types. Как вы уже наверно догадались, речь идёт о локальном сервере. Ещё точнее, о сборке Денвер. И вот тут, мы плавно переходим к установке модуля и настройке сервера.

    Установка и настройка

    Ещё раз напомню: речь идёт о локальном сервере, сборка Денвер. Как вы понимает, нам понадобится обратиться к файлу php.ini. У меня он находится в папке: С:\WebServer\usr\local\php5\. В нём нам надо подключить два расширения: php_fileinfo.dll и php_mime_magic.dll. Например, так:

    Обращаю внимание на то, что данные расширения должны существовать. У меня они находятся в папке: С:\WebServer\usr\local\php5\ext\.

    Далее нам понадобится настроить опции mime_magic , относящиеся к секции «Data Handling». В частности:

    Список MIME типов для всех типов файлов

    При загрузке файла на сайт WordPress проверят миме-тип файла. Иногда полезно знать как конкретно называется mime тип файла у определенного расширения файла. К примеру .zip файл может иметь разные MIME типы, в зависимости от сервера на котором работает код.

    Список ниже поможет быстро собрать нужные варианты MIME-типов для любого формата файла.

    В WordPress такой список значительно меньше и найти его можно в описании wp_get_mime_types()

    mime_content_type

    (PHP 4 >= 4.3.0, PHP 5, PHP 7)

    mime_content_type — Определяет MIME-тип содержимого файла (устаревшее)

    Описание

    Возвращает MIME-тип содержимого файла, используя для определения информацию из файла magic.mime .

    Список параметров

    Путь к проверяемому файлу.

    Возвращаемые значения

    Возвращает тип содержимого в формате MIME, например text/plain или application/octet-stream.

    Примечания

    Эта функция является устаревшей, поскольку PECL-расширение Fileinfo обеспечивает ту же (а то и большую) функциональность более простым способом.

    Примеры

    Пример #1 Пример mime_content_type()

    Результат выполнения данного примера:

    Смотрите также

    Коментарии

    The function mime_content_type only worked for me on Microsoft Windows after I added the directive «mime_magic.debug» to my php.ini with the value of «On». The default value appears to be «Off». Exampe:

    [mime_magic]
    mime_magic.debug = On
    mime_magic.magicfile = «c:\php\extras\magic.mime»

    I added these two lines to my magic.mime file:

    0 string \ / x — httpd — php
    0 string xml text / xml

    The first one may not work if » is not at the very beginning of your file , e . g ., if some HTML preceeds the first bit of PHP code . The second one should work because » * should * be the first thing in every XML file .

    The correct little correction:

    exec will return the mime with a newline at the end, the trim() should be called with the result of exec, not the other way around.

    if ( ! function_exists ( ‘mime_content_type ‘ ) )
    <
    function mime_content_type ( $f )
    <
    return trim ( exec ( ‘file -bi ‘ . escapeshellarg ( $f ) ) ) ;
    >
    >

    For me mime_content_type didn’t work in Linux before I added

    to php.ini (remember to find the correct path to mime.magic)

    Since I enabled the mime_magic extension on my IIS, I also got the error message «invalid magic file, disabled» in my phpinfo. After I add these lines to my php.ini, the message disappeared and it works great!

    mime_magic.debug = Off
    mime_magic.magicfile =»D:\PHP5\extras\magic.mime»

    mime_magic.debug is by default off but without this line it fails. I’m using PHP 5.2.5.

    Regarding serkanyersen’s example : It is advisable to change the regular expression to something more precise like

    This makes sure that only the last few characters are taken. The original expression would not work if the filename is a relative path.

    I also had issues with this function.

    The issue was that it would almost always return «text/plain».

    echo ini_get(‘mime_magic.magicfile’); // returns /etc/httpd/conf/magic

    I found that I needed the OS’ magic.mime file instead.

    You can either copy it to the existing location, or update your php.ini, you cannot use ini_set().

    [root@blade conf]# mv magic magic.old
    [root@blade conf]# cp /usr/share/magic.mime magic
    [root@blade conf]# apachectl graceful

    Note: you will see that I have gracefully restarted apache to ensure it has taken affect.

    Lukas V is IMO missing some point. The MIME type of a file may not be corresponding to the file suffix.

    Imagine someone would obfuscate some PHP code in a .gif file, the file suffix would be ‘GIF’ but the MIME would be text/plain or even text/html.

    Another example is files fetched via a distant server (wget / fopen / file / fsockopen. ). The server can issue an error, i.e. 404 Not Found, wich again is text/html, whatever you save the file to (download_archive.rar).

    His provided function should begin by the test of the function existancy like :

    function MIMEalternative($file)
    <
    if(function_exists(‘mime_content_type’))
    return mime_content_type($file);
    else
    return ($file);
    >

    if(! function_exists ( ‘mime_content_type’ )) <

    function mime_content_type ( $filename ) <

    ‘txt’ => ‘text/plain’ ,
    ‘htm’ => ‘text/html’ ,
    ‘html’ => ‘text/html’ ,
    ‘php’ => ‘text/html’ ,
    ‘css’ => ‘text/css’ ,
    ‘js’ => ‘application/javascript’ ,
    ‘json’ => ‘application/json’ ,
    ‘xml’ => ‘application/xml’ ,
    ‘swf’ => ‘application/x-shockwave-flash’ ,
    ‘flv’ => ‘video/x-flv’ ,

    // images
    ‘png’ => ‘image/png’ ,
    ‘jpe’ => ‘image/jpeg’ ,
    ‘jpeg’ => ‘image/jpeg’ ,
    ‘jpg’ => ‘image/jpeg’ ,
    ‘gif’ => ‘image/gif’ ,
    ‘bmp’ => ‘image/bmp’ ,
    ‘ico’ => ‘image/vnd.microsoft.icon’ ,
    ‘tiff’ => ‘image/tiff’ ,
    ‘tif’ => ‘image/tiff’ ,
    ‘svg’ => ‘image/svg+xml’ ,
    ‘svgz’ => ‘image/svg+xml’ ,

    // archives
    ‘zip’ => ‘application/zip’ ,
    ‘rar’ => ‘application/x-rar-compressed’ ,
    ‘exe’ => ‘application/x-msdownload’ ,
    ‘msi’ => ‘application/x-msdownload’ ,
    ‘cab’ => ‘application/vnd.ms-cab-compressed’ ,

    // audio/video
    ‘mp3’ => ‘audio/mpeg’ ,
    ‘qt’ => ‘video/quicktime’ ,
    ‘mov’ => ‘video/quicktime’ ,

    // adobe
    ‘pdf’ => ‘application/pdf’ ,
    ‘psd’ => ‘image/vnd.adobe.photoshop’ ,
    ‘ai’ => ‘application/postscript’ ,
    ‘eps’ => ‘application/postscript’ ,
    ‘ps’ => ‘application/postscript’ ,

    // ms office
    ‘doc’ => ‘application/msword’ ,
    ‘rtf’ => ‘application/rtf’ ,
    ‘xls’ => ‘application/vnd.ms-excel’ ,
    ‘ppt’ => ‘application/vnd.ms-powerpoint’ ,

    // open office
    ‘odt’ => ‘application/vnd.oasis.opendocument.text’ ,
    ‘ods’ => ‘application/vnd.oasis.opendocument.spreadsheet’ ,
    );

    $ext = strtolower ( array_pop ( explode ( ‘.’ , $filename )));
    if ( array_key_exists ( $ext , $mime_types )) <
    return $mime_types [ $ext ];
    >
    elseif ( function_exists ( ‘finfo_open’ )) <
    $finfo = finfo_open ( FILEINFO_MIME );
    $mimetype = finfo_file ( $finfo , $filename );
    finfo_close ( $finfo );
    return $mimetype ;
    >
    else <
    return ‘application/octet-stream’ ;
    >
    >
    >
    ?>

    Here’s a simple function to return MIME types, based on the Apache mime.types file. [The one in my previous submission, which has since been replaced by this one] only works properly if mime.types is formatted as Windows text. The updated version below corrects this problem. Thanks to Mike for pointing this out.

    function get_mime_type ( $filename , $mimePath = ‘../etc’ ) <
    $fileext = substr ( strrchr ( $filename , ‘.’ ), 1 );
    if (empty( $fileext )) return ( false );
    $regex = «/^([\w\+\-\.\/]+)\s+(\w+\s)*($fileext\s)/i» ;
    $lines = file ( «$mimePath/mime.types» );
    foreach( $lines as $line ) <
    if ( substr ( $line , 0 , 1 ) == ‘#’ ) continue; // skip comments
    $line = rtrim ( $line ) . » » ;
    if (! preg_match ( $regex , $line , $matches )) continue; // no match to the extension
    return ( $matches [ 1 ]);
    >
    return ( false ); // no match at all
    >
    ?>

    Notes:
    [1] Requires mime.types file distributed with Apache (normally found at ServerRoot/conf/mime.types). If you are using shared hosting, download the file with the Apache distro and then upload it to a directory on your web server that php has access to.

    [2] First param is the filename (required). Second parameter is path to mime.types file (optional; defaults to home/etc/).

    [3] Based on MIME types registered with IANA (http://www.iana.org/assignments/media-types/index.html). Recognizes 630 extensions associated with 498 MIME types.

    [4] Asserts MIME type based on filename extension. Does not examine the actual file; the file does not even have to exist.

    [5] Examples of use:
    >> echo get_mime_type(‘myFile.xml’);
    >> application/xml
    >> echo get_mime_type(‘myPath/myFile.js’);
    >> application/javascript
    >> echo get_mime_type(‘myPresentation.ppt’);
    >> application/vnd.ms-powerpoint
    >> echo get_mime_type(‘http://mySite.com/myPage.php);
    >> application/x-httpd-php
    >> echo get_mime_type(‘myPicture.jpg’);
    >> image/jpeg
    >> echo get_mime_type(‘myMusic.mp3’);
    >> audio/mpeg
    and so on.

    To create an associative array containing MIME types, use:
    function get_mime_array ( $mimePath = ‘../etc’ )
    <
    $regex = «/([\w\+\-\.\/]+)\t+([\w\s]+)/i» ;
    $lines = file ( «$mimePath/mime.types» , FILE_IGNORE_NEW_LINES );
    foreach( $lines as $line ) <
    if ( substr ( $line , 0 , 1 ) == ‘#’ ) continue; // skip comments
    if (! preg_match ( $regex , $line , $matches )) continue; // skip mime types w/o any extensions
    $mime = $matches [ 1 ];
    $extensions = explode ( » » , $matches [ 2 ]);
    foreach( $extensions as $ext ) $mimeArray [ trim ( $ext )] = $mime ;
    >
    return ( $mimeArray );
    >
    ?>

    Fast generation of uptodate mime types:

    function generateUpToDateMimeArray ( $url ) <
    $s =array();
    foreach(@ explode ( «\n» ,@ file_get_contents ( $url ))as $x )
    if(isset( $x [ 0 ])&& $x [ 0 ]!== ‘#’ && preg_match_all ( ‘#([^\s]+)#’ , $x , $out )&&isset( $out [ 1 ])&&( $c = count ( $out [ 1 ]))> 1 )
    for( $i = 1 ; $i $c ; $i ++)
    $s []= ‘ \» . $out [ 1 ][ $i ]. ‘\’ => \» . $out [ 1 ][ 0 ]. ‘\» ;
    return @ sort ( $s )? ‘$mime_types = array(
    ‘ . implode ( $s , ‘,
    ‘ ). ‘
    );’ : false ;
    >

    Системное программное обеспечение

    7.1 Что такое MIME?

    MIME означает «Multipurpose Internet Mail Extensions» (Многоцелевые расширения почтового стандарта Internet). Этот стандарт описывает, как пересылать по электронной почте исполняемые, графические, мультимедийные, смешанные данные. Типичные применения MIME — пересылка графических изображений, аудио, документов Word, программ и даже просто текстовых файлов, то есть, когда важно, чтобы входе пересылки не производилось никаких преобразований над данными. MIME также позволяет размечать письмо на части различных типов так, чтобы получатель (почтовая программа) мог определить, что делать с каждой из частей письма.

    Хотя формат первоначально создан для электронной почты, он также используется для службы WWW.

    7.2 Для чего это нужно?

    Так как файлы могут быть разными (.gif, .doc, .pdf . ), браузер должен понимать, что с ними делать. Эту проблему решает стандарт «MIME — типы». Он сообщает клиенту, какой тип файлов получен, например:
    Content-type: image/gif (графика GIF)
    Content-type: image/jpeg (графика JPG)

    7.3 Как это работает?

    Браузеры используют MIME-типы в своих HTTP-заголовках Accept для того, чтобы сообщить, в каких форматах они предпочитают принимать данные (если сервер может выдать файл в разных форматах). Серверы используют MIME-типы в HTTP-заголовках Content-Type, чтобы сообщить клиенту о том, в каком формате передается прилагаемое содержимое: то ли это HTML, который нужно форматировать, то ли это GIF или JPEG, требующий визуализации, то ли это данные в формате PDF, для которого нужно открывать внешнюю программу просмотра или использовать дополнительное приложение.

    Формат MIME-типа — тип/подтип. Можно использовать символ *; например, следующий заголовок клиента означает, что принимаются документы во всех форматах:

    Следующий заголовок клиента означает, что принимаются все типы формата text независимо от подтипа:

    Серверы должны проверять данные о принимаемых типах, содержащиеся в заголовке Accept, и по возможности выдавать данные соответствующего типа. Большинство серверов определяют формат документа по расширению имени файла. Например, файлы с расширениями .htm и .html — это файлы в формате HTML, поэтому сервер посылает такой документ с типом text/html в заголовке Content-Type, пример:


    Действия клиента при получении файла:

    При получении клиентом файла, анализируется HTTP заголовок, если в нем находится Content-Type, то клиент производит действие с файлом, учитывая эту информацию.

    Если записи нет, то клиент использует свой список MIME-типов, в котором тип определяется по расширению имени файла.

    Если тип в файле не найден, то клиент не знает что делать с этим файлом. Браузер в таком случае предлагает вам выбрать сами программу, которой надо передать файл.

    7.4 Некоторые основные типы и подтипы MIME.

    Первый стандарт — RFC1341 MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies N. Borenstein, N. Freed June 1992

    Последняя версия (состоит из четырех частей) :

    RFC2049 (Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples N. Freed, N. Borenstein November 1996)

    RFC2048 (Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures N. Freed, J. Klensin, J. Postel November 1996)

    RFC2047 (MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text K. Moore November 1996)

    RFC2046 (Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types N. Freed, N. Borenstein November 1996)

    RFC2045 (Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies N. Freed, N. Borenstein November 1996)

    Text – текстовые типы.

    Тип ‘text’ предназначен для пересылки текстовых материалов. Для обозначения языковой кодировки текста используется параметр «charset» для некоторых подтипов, включая подтип, «text/html», соответствующий простому (неформатированному) тексту.

    Content-Type: text/html; charset=windows-1251

    Основные подтипы:
    Content-Type: text/html — html текст.
    Content-Type: text/plain — простой текст.
    Content-Type: text/x-server-parsed-html — файл созданный с помощью SSI
    Content-Type: text/css — файл содержащий стили — css

    Multipart — данные состоят из несколько частей разных типов.

    Основные подтипы:
    Content-Type: multipart/mixed — несколько частей разных типов (используется в e-mail)
    Content-Type: multipart/alternative — одна из частей (используется в e-mail)
    Content-Type: multipart/x-mixed-replace — после загрузки следующая часть заменяет предыдущею (используется в анимации)

    Message — инкапсулированное почтовое сообщение (используется в e-mail)

    Image — графические типы.

    Основные подтипы:
    Content-Type: image/gif — изображение gif.
    Content-Type: image/jpeg — изображение jpeg.
    Content-Type: image/tiff — изображение tiff.
    Content-Type: image/bmp — изображение bmp

    Audio — звуковые типы.

    Основные подтипы:
    Content-Type: audio/wav — звук в формате wav.
    Content-Type: audio/midi — звук в формате midi
    Content-Type: audio/mpeg — звук в формате mp3.
    Content-Type: audio/vqf — звук в формате vqf
    Content-Type: audio/x-pn-realaudio — звук в формате ram rm
    Content-Type: audio/x-realaudio — звук в формате ra
    Content-Type: audio/x-wav — звук в формате wav

    Основные подтипы:
    Content-Type: video/avi — видео в формате avi.
    Content-Type: video/mpeg — видео в формате mpeg.

    Application — представляет данные какого-нибудь приложения.

    application/msword – приняв такое сообщение, браузер запустит MS Word для открытия этих данных. Если в системе нет MS Word, то браузер попросит сохранить данные в файле имя файла может находиться в параметре name. Например:

    Content-Type: application/msword; name=”Mydoc.doc”

    Основные подтипы:
    Content-Type: application/msword — программа MS Word
    Content-Type: application/pdf — программа Acrobat Reader
    Content-Type: application/rtf — программа MS Word
    Content-Type: application/zip — разархиватор ZIP-архивов

    7.5 Серверные приложения.

    Приложения на сервер можно использовать для создания счетчиков, форумов, чатов, обработки статистики, организации доступа к базам данных и т.д.

    Для этого нужно чтобы клиенты могли запускать или работать с приложениями на сервере.

    7.5.1 Методы использования серверных приложений.

    Запуск через CGI-шлюз. Эти приложения могут быть написаны на любых языках.
    Преимущества:
    — используются обычные программы (в случае Windows .bat, .exe и тд.)
    — стандартизовано
    Недостатки:
    — при каждом вызове программы происходит ее запуск, что не есть быстро, и при большом количестве запросов, появляется много запущенных программ.

    Приложения, встроенные в сервер HTTP, как модули. Как правило, написанные на С.
    Преимущества:
    — быстрота (т.к. всегда работает, не нужен запуск).
    Недостатки:
    — необходимость писать модуль для конкретного сервера HTTP.

    Приложения, работающие через модули-шлюзы встроенные в сервер HTTP.
    Преимущества:
    — шлюз написан для конкретного приложения (например, для СУБД MySQL)
    Недостатки:
    — необходимость писать модул-шлюз для конкретного приложения.

    Приложения, написанные на скриптовых языках (SSI, PERL, PHP, ASP и др.), для выполнения которых должны быть встроенные интерпретаторы, как модули сервера HTTP. Код этих приложений встраивается непосредственно в HTML страницы. Сервер распознает эти страницы по расширению (.php, .asp, .shtml, .pl).
    Преимущества:
    — быстрота (выше чем у CGI, но ниже чем у модуля, т.к. интерпретаторы).
    — удобно использовать
    Недостатки:
    — ограниченность возможностей

    Приложения, работающие через Java Servlet.
    Преимущества:
    — платформо-независимость
    — серверо-независимость
    Недостатки:
    — приложения на Java работаю медленнее

    Приложения, написанные на Java и встроенные в HTML страницы (с расширением .JSP (JavaServer Pages)). В принципе это аналог скриптовых языков работающих через модуль (в место модуля в данном случае Java Servlet, а язык Java)
    Преимущества:
    — платформо-независимость
    — серверо-независимость
    — удобно использовать
    Недостатки:
    — приложения на Java работаю медленнее

    7.5.2 Архитектура WWW сервера с учетом серверных приложений

    Архитектура современного WWW сервера. На выходе с сервера всегда HTML, но сгенерированный приложением.

    7.5.3 Примеры запросов к приложениям

    В результате через CGI шлюз

    Будет запущено приложение search.cgi

    и будет передан запрос «text=сотрудники» приложению search.cgi

    Приложение search.cgi вернет результат работы CGI-шлюзу

    Будет передан запрос «text=сотрудники» интерпретатору PHP.

    Интерпретатор будет выполнять команды search.php.

    Интерпретатор вернет результат работы WWW-серверу.

    Common Gateway Interface — стандарт для обмена данными между сервером и прикладной программой, которая запускается из-под сервера.

    7.6.1 Механизмы обмена данными

    Механизм можно разделить на четыре части:

    7.6.1.1 Переменные окружения

    При запуске внешней программы сервер создает специфические переменные окружения, через которые передает приложению, как служебную информацию, так и данные.

    SERVER_NAME — определяет доменное имя сервера.

    GATEWAY_INTERFACE — определяет версию протокола CGI.

    SERVER_PROTOCOL — протокол сервера.

    SERVER_SOFTWARE — версия сервера.

    SERVER_PORT — определяет порт, по которому осуществляется взаимодействие.

    REQUEST_METHOD — определяет метод, значения GET, POST, HEAD и т. п.

    PATH_INFO — передает программе путь с переменными, часть URL переданный клиентом (т.е. относительный путь с переменными).

    PATH_TRANSLATED — абсолютный путь, путь расположения программы на диске сервера.
    Пример для запроса http://ipm.kstu.ru/cgi-bin/search?text=ipm:
    PATH_INFO = «/cgi-bin/search?text=ipm»
    PATH_TRANSLATED = «/usr/local/etc/httpd/cgi-bin/search».

    SCRIPT_NAME — относительный путь без переменных.
    Пример для запроса http://ipm.kstu.ru/cgi-bin/search?text=ipm:
    PATH_INFO = «/cgi-bin/search?text=ipm»
    SCRIPT_NAME = «/cgi-bin/search»

    QUERY_STRING — переменная определяет содержание запроса к скрипту (все что после ?).
    Пример для запроса http://ipm.kstu.ru/cgi-bin/search?text=ipm:
    QUERY_STRING —— «text=ipm»

    Идентификация пользователя и его машины:

    REMOTE_HOST — доменный адрес машины клиента.

    REMOTE_ADDR — IP-адрес машины клиента.

    AUTH_TYPE — тип идентификации пользователя.

    REMOTE_USER — используется для идентификации пользователя.

    REMOTE_IDENT — данная переменная порождается сервером, если он поддерживает идентификацию пользователя по протоколу RFC-931. Рекомендовано использование этой переменной для первоначального использования скрипта.

    Тип и длина передаваемой информации от клиента к серверу.

    CONTENT_TYPE — определяет MIME-тип данных.

    CONTENT_LENGTH — определяет размер данных в байтах.

    Переменные заголовка HTTP.

    HTTP_ACCEPT — поле ACCEPT.

    HTTP_USER_AGENT — поле USER-AGENT.

    HTTP_HOST — поле HOST.

    7.6.1.2 Командная строка

    Командная строка используется только при запросах типа ISIN-DEX.

    MIME File Type Checker / Val >

    A handy tool to check what type of file you are dealing with by checking the Multipurpose Internet Mail Extension. This is especially useful for developers who are working on val >

    This File Type is:

    What does this tool do?

    It takes your upload and stores a temporary file, which is then inspected to see what the MIME type is. It does not rely on the file extension to complete the task. All files uploaded via the https protocol and are immediately deleted after inspection. Max file upload size: 50MB (this can be raised).

    Complete List of MIME Types

    Well, at least the ones you are most commonly going to encounter. There is an untold number of more exotic MIME’s such as application/x-bittorrent and application/x-iso9660-image etc.

    Get MIME type from filename extension

    How can I get the MIME type from a file extension?

    21 Answers 21

    For ASP.NET or other

    The options were changed a bit in ASP.NET Core, here they are (credits):

    • new FileExtensionContentTypeProvider().TryGetContentType(fileName, out contentType); (vNext only)
      • Never tested, but looks like you can officially expand the mime types list via the exposed Mappings property.
    • Use the MimeTypes NuGet package
    • Copy the MimeMappings file from the reference source of the .NET Framework

    For .NET Framework >= 4.5:

    Use the System.Web.MimeMapping.GetMimeMapping method, that is part of the BCL in .NET Framework 4.5:

    If you need to add custom mappings you probably can use reflection to add mappings to the BCL MimeMapping class, it uses a custom dictionary that exposes this method, so you should invoke the following to add mappings (never tested tho, but should prob. work).

    Anyway, when using reflection to add MIME types, be aware that since you’re accessing a private field, its name might change or even be totally removed, so you should be extra cautious and add double checks and provide fail safe action for every step.

    Илон Маск рекомендует:  Что такое код getgraphmode
    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL