Вместо введения - кусок перевода comp.mail.mime FAQ :
MIME - Multi-purpose Internet Mail Extensions. Свободно-доступный набор спецификаций, предлагающий способ обмена текстами с различным набором символов и multimedia e-mail среди множества различных компьютерных систем, которые используют стандарты Internet для обмена почтой.
Если Вы уже имели дело с обычной текстовой электронной почтой, теперь, благодаря MIME Вы можете создавать и читать сообщения, имеющие следующие дополнительные возможности :
MIME поддерживает не только некоторые, раз и навсегда заданные типы нетекстовой информации, например 8-bit 8000Hz-sampled mu-LAW audio, или GIF images, или PostScript-программы, но и позволяет Вам также определять Ваши собственные типы данных.
Перед тем, как стандарт MIME стал широко распространенным, у Вас также была возможность создавать сообщения, содержащие, скажем, PostScript документы и звуковое сопровождение, но чаще всего сообщение было закодировано в собственном, не переносимом формате. Это означало, что Вы не могли прочитать это сообщение на системе от другого поставщика, даже если оно прошло неповрежденным через почтовый шлюз. Теперь же, в зависимости от совершенства Вашей MIME почтовой системы, есть неплохой шанс, что это будет "просто работать".
Самое ценное в MIME то, что это "четырехколесный протокол". Протокол MIME был аккуратно разработан для выживания в среде самых разнообразных SMTP, UUCP и других Procrustean протоколов передачи почты, которые любят перемешивать, перепутывать и перекодировать заголовки и текст почтового сообщения.
. . .
Стандарт MIME определен в :
RFC 2045: MIME Part One: Format of Internet Message Bodies RFC 2046: MIME Part Two: Media Types RFC 2047: MIME Part Three: Message Header Extensions for Non-ASCII Text RFC 2048: MIME Part Four: Registration Procedures RFC 2049: MIME Part Five: Conformance Criteria and Examples
Или см. напрмер на Yahoo! :
http://www.yahoo.com/Computers_and_Internet/Standards/RFCs/
Для пользователя здесь выигрыш в том,
что у сообщения (или части сообщения) типа text/plain,
text/html появился параметр charset=Xxxxx
, однозначно задающий кодировку сообщения. Если charset=
не проставлен, кодировка предполагается ISO_8859-1
(набор символов Latin-1).
Другое полезное свойство MIME
- закодированные заголовки. Дело в том, что
стандартный RFC-822 предполагал, что заголоки писем
From: , To: и т.д. 7-ми битные. Для обхода этой проблемы
была предложена схема MIME. И теперь
заголовки могут иметь вид :
Subject: Re: =?KOI8-R?Q?=C1?=
Предположим теперь, что наша операционная система - UNIX (POSIX). Здесь мы имеем дело с 3-мя различными объектами:
Само по себе, текущее значение locale ( установленное через LANG=) ( а точнее значение категорий LC_CTYPE и LC_COLLATE ) оказывает влияние только на обработку символов, но никак не на ввод/вывод.
Как мы уже знаем, средствами locale и стандартного UNIX ввода/вывода никак нельзя ни повлиять, ни даже спросить текущее значение аппаратной конфигурации (кодировки).
С другой стороны, почтовые сообщения в MIME могут содержать различные charset даже в пределах одного сообщения.
Задача почтовой программы (MUA - Mail User Agent)-- правильно отобразить различные charset для text/plain и text/html. Это легко сделать в оконных системах (Windows, X-Windows, e.t.c.) где доступна информация о шрифтах, но невозможно для стандартного UNIX терминального ввода/вывода.
В наиболее старой и известной программе для работы с MIME - metamail (взять можно здесь) впервые столкнулись с данной проблемой. Именно для metamail была впервые введена переменная окружения MM_CHARSET которая задавала "текущий" charset (набор символов) на консоли. Предполагалось, что пользователь его знает (или сам установил). Но постепенно эта переменная стала трактоваться как значение текущей кодировки аппаратного окружения (фонтов, e.t.c.) и современные почтовые программы (mh, elm) активно используют эту переменную.
Любая современная почтовая программа должна обязательно поддерживать UNICODE и UTF-8. См. : Internet Mail Consortium / Internationalization.
Содержание "Locale AS IT IS"