Подтип Multipart / alternative, когда клиент использует его?
Почему webmails (например, Gmail) отправляет MIME-сообщения с помощью многослойный/альтернативный подтипа (при составлении в HTML), в то время как другие отправляют HTML как MIME с текстовыми/html-частями внутри (без использования альтернативного подтипа)?
2 ответов
multipart/alternative указывает, что каждая часть является "альтернативной" версией того же (или аналогичного) контента, каждый в другом формате, обозначенном его заголовком "Content-Type". Форматы упорядочены по тому, насколько они верны оригиналу, с наименее верным первым и самым верным последним.
почтовые агенты, такие как Gmail, знают, что они делают, и конвертируют text/html to text/plain и поместите обе альтернативы в электронные письма и пусть получающая сторона решит, какая альтернатива использовать.
есть также почтовые агенты, которые не знают, как извлечь текстовую версию из содержимого html, только потому, что разработчик не потрудился ее реализовать, поэтому они только отправляют text/html без каких-либо альтернатив.
и иногда - я называю их сумасшедшими - послать multipart/alternative, но на самом деле только текст/html без каких-либо альтернатив. Что не очень приятно, но это не против каких-либо спецификаций.
на 5.1.4 of RFC 2046 определяет multipart/alternative тип MIME, позволяющий отправителю предоставлять различные взаимозаменяемые представления тот же сообщение и оставить его до получателя, чтобы выбрать форму презентации, наиболее подходящую для его возможностей. Обратите внимание, что, хотя общее значение каждого представления для пользователя должно быть сохранено, обычно происходит некоторая потеря информации от одного представления к другому (например, text/plain отсутствует информация о форматировании в отношении text/html). Альтернативы обычно должны быть упорядочены от самых простых до самых богатых, т. е. если альтернативы снова text/html и text/plain затем text/plain должен быть первым. Это помогает пользователям несоответствующих MIME зрителей, в которых легче всего интерпретировать часть будет отображаться в первую очередь. Как правило, MIME-совместимый зритель должен отображать последнее представление, которое он способен просматривать, так как это наиболее предпочтительный.
этот тип контента часто контрастирует с multipart/mixed где разные ресурсы объединяются в одно сообщение.
основная причина некоторые почтовые службы предоставляют сообщения как multipart/alternative для поддержки различных типов приложений просмотра на принимающей стороне. Например, некоторые зрители не имеют возможности отображать HTML и требуют text/plain представление сообщения по всем читаемым. В то же время, другие зрители у вас есть возможность рендеринга HTML и может обеспечить гораздо лучший пользовательский интерфейс, когда сообщение доставляется как text/html. Наиболее гибкое решение компромисса между поддержкой широкого круга зрителей и улучшением пользовательского опыта для более способных из них обеспечивается за счет доставки обоих представлений, завернутых в multipart/alternative сообщение.
Подробнее см. RFC 2046.