क्यों वेबमेल (जीमेल की तरह) मल्टीपार्ट/वैकल्पिक उप प्रकार (HTML में लिखते समय) का उपयोग करते हुए एमआईएमई संदेश भेजता है जबकि अन्य HTML को टेक्स्ट/एचटीएमएल भागों के साथ एमआईएम के रूप में भेजते हैं (वैकल्पिक उप प्रकार का उपयोग किए बिना)?मल्टीपार्ट/वैकल्पिक उप प्रकार, जब ग्राहक इसका उपयोग करते हैं?
multipart/alternative इंगित करता है कि प्रत्येक भाग एक ही (या समान) सामग्री का "वैकल्पिक" संस्करण है, प्रत्येक अपने "सामग्री-प्रकार" शीर्षलेख द्वारा निर्दिष्ट एक अलग प्रारूप में है। प्रारूपों का आदेश दिया जाता है कि वे कम से कम वफादार पहले और सबसे वफादार आखिरी के साथ मूल के प्रति कितने वफादार हैं।
जीमेल जैसे मेल-एजेंट जानते हैं कि वे क्या कर रहे हैं, और text/html से text/plain में कनवर्ट करें और दोनों विकल्पों को ईमेल में रखें और प्राप्त करने का अंत तय करें कि किस विकल्प का उपयोग करना है।
ऐसे मेल-एजेंट भी हैं जो HTML सामग्री से टेक्स्ट-केवल संस्करण निकालने के बारे में नहीं जानते हैं, क्योंकि डेवलपर इसे लागू करने के लिए परेशान नहीं था, इसलिए वे केवल text/html को किसी भी विकल्प के साथ भेजते हैं।
और कभी-कभी - मैं उन्हें पागल कहता हूं - multipart/alternative भेजें, लेकिन वास्तव में केवल किसी भी विकल्प के बिना टेक्स्ट/एचटीएमएल डालें। जो वास्तव में अच्छा नहीं है, लेकिन यह किसी भी spec के खिलाफ नहीं है।
RFC 2046 की section 5.1.4 प्रेषक एक ही संदेश के विभिन्न, विनिमेय अभ्यावेदन प्रदान करने के लिए अनुमति देने के लिए और रिसीवर के लिए इसे छोड़ने के लिए अपनी क्षमताओं के लिए सबसे उपयुक्त प्रस्तुति के रूप चुना multipart/alternative MIME प्रकार परिभाषित करता है। ध्यान दें कि उपयोगकर्ता के लिए प्रत्येक प्रतिनिधित्व के सामान्य अर्थ को बनाए रखा जाना चाहिए, जबकि आमतौर पर एक प्रतिनिधित्व से कुछ जानकारी हानि होती है (उदा। text/plaintext/html के संबंध में स्वरूपण जानकारी गुम है)। विकल्पों को आम तौर पर सबसे अमीर से सबसे अमीर तक आदेश दिया जाना चाहिए, यानी यदि विकल्प फिर से text/html और text/plain हैं तो text/plain पहले आना चाहिए। यह गैर-एमआईएम-अनुरूप दर्शकों के उपयोगकर्ताओं की सहायता करता है जिनमें भाग की व्याख्या करने के लिए सबसे आसान सबसे पहले दिखाया जाएगा। आम तौर पर, एक एमआईएम-अनुरूप व्यक्ति को अंतिम प्रतिनिधित्व प्रदर्शित करना चाहिए जो इसे देखने में सक्षम है क्योंकि यह सबसे बेहतर है।
यह सामग्री प्रकार अक्सर multipart/mixed के साथ विपरीत होता है जहां विभिन्न संसाधन एक ही संदेश में संयुक्त होते हैं।
मुख्य कारण कुछ मेल सेवाएं multipart/alternative संदेश प्रदान करती हैं क्योंकि प्राप्त करने वाले अंत में विभिन्न प्रकार के देखने के अनुप्रयोगों का समर्थन करना है। उदाहरण के लिए, कुछ दर्शकों में HTML को प्रस्तुत करने की क्षमता नहीं होती है और संदेश को पढ़ने के लिए text/plain प्रतिनिधित्व की आवश्यकता होती है। साथ ही, अन्य दर्शकों के पास HTML प्रस्तुत करने की क्षमता होती है और text/html के रूप में संदेश वितरित होने पर अधिक बेहतर उपयोगकर्ता अनुभव प्रदान कर सकता है। दर्शकों की विस्तृत श्रृंखला का समर्थन करने और अधिक सक्षम लोगों के लिए उपयोगकर्ता अनुभव को बढ़ाने के बीच व्यापार-बंद का सबसे लचीला समाधान multipart/alternative संदेश में लिपटे दोनों प्रस्तुतिकरणों को वितरित करके प्रदान किया जाता है।
विवरण के लिए RFC 2046 देखें।
अच्छी व्याख्या। –