Составной / альтернативный подтип, когда клиент его использует?

Question

Почему веб-почта (например, Gmail) отправляет сообщения MIME, используя multipart / альтернативный подтип (при компоновке в HTML), в то время как другие отправляют HTML как MIME с частями text / html внутри (без использования альтернативного подтипа)?

Answer 1

В разделе 5.1.4 из 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 .

Answer 2

multipart/alternative указывает, что каждая часть является «альтернативной» версией одного и того же (или похожего) контента, каждая в своем формате, обозначаемом заголовком «Content-Type». Форматы упорядочены по тому, насколько они верны оригиналу, с наименее верным первым и самым верным последним.

Почтовые агенты, такие как Gmail, знают, что они делают, и конвертируют text/html в text/plain, помещают обе альтернативы в свои электронные письма и позволяют принимающей стороне решить, какую альтернативу использовать.

Есть также почтовые агенты, которые не знают, как извлечь текстовую версию из html-контента, просто потому, что разработчик не удосужился ее реализовать, поэтому они только отправляют text/html без каких-либо альтернатив.

А иногда - я называю их сумасшедшими - отправляю multipart/alternative, но на самом деле ставлю только текст / html без каких-либо альтернатив. Что не очень приятно, но это не против какой-либо спецификации.