ईमेल सामग्री भेजते समय, "सामग्री अंतरण एन्कोडिंग" शीर्षक सेट करना आवश्यक है। मुझे मिले ईमेल के कई हेडर का अवलोकन किया। कुछ ईमेल "7 बिट" का उपयोग कर रहे हैं और कुछ "8 बिट" का उपयोग कर रहे हैं।
इन दोनों के बीच क्या अंतर है? कौन सा अनुशंसित है? क्या इन शीर्षलेखों को सेट करने के लिए ईमेल बॉडी के लिए कोई विशेष एन्कोडिंग आवश्यक है?
जवाबों:
यह पढ़ने में थोड़ा घना हो सकता है, लेकिन RFC 1341 के "कंटेंट-ट्रांसफर-एन्कोडिंग" खंड में सभी विवरण हैं:
http://www.w3.org/Protocols/rfc1341/5_Content-Transfer-Encoding.html
स्थिति थोड़े बुरे से बदतर होती चली जाती है। यहाँ मेरा सारांश है:
SMTP, परिभाषा (RFC 821) द्वारा, 7 बिट्स के 1000 वर्णों की मेल को सीमित करता है। इसका मतलब है कि पाइप को नीचे भेजने वाले किसी भी बाइट में "1" के लिए सबसे महत्वपूर्ण ("उच्चतम-क्रम") बिट सेट नहीं हो सकता है।
जो सामग्री हम भेजना चाहते हैं, वह अक्सर इस प्रतिबंध का पालन नहीं करती है। एक छवि फ़ाइल के बारे में सोचें, या एक पाठ फ़ाइल जिसमें यूनिकोड वर्ण हैं: इन फ़ाइलों के बाइट में अक्सर "8" पर उनका 8 वाँ बिट सेट होगा। SMTP इसे अनुमति नहीं देता है, इसलिए आपको बेमेल के आसपास काम करने के तरीके का वर्णन करने के लिए "ट्रांसफ़र एन्कोडिंग" का उपयोग करने की आवश्यकता है।
Content-Transfer-Encodingशीर्षलेख के मान उस नियम का वर्णन करते हैं, जिसे आपने इस समस्या को हल करने के लिए चुना है।
7bitबस का अर्थ है "मेरे डेटा में केवल US-ASCII वर्ण हैं, जो केवल प्रत्येक वर्ण के लिए निचले 7 बिट्स का उपयोग करते हैं।" आप मूल रूप से गारंटी दे रहे हैं कि आपकी सामग्री के सभी बाइट पहले से ही एसएमटीपी के प्रतिबंधों का पालन करते हैं, और इसलिए इसे किसी विशेष उपचार की आवश्यकता नहीं है। आप इसे बस के रूप में पढ़ सकते हैं।
ध्यान दें कि जब आप चुनते हैं 7bit, तो आप इस बात से सहमत होते हैं कि आपकी सामग्री की सभी लाइनें लंबाई में 1000 वर्णों से कम हैं।
जब तक आपकी सामग्री इन नियमों का पालन करती है, 7bitतब तक सर्वोत्तम स्थानांतरण एन्कोडिंग है, क्योंकि कोई अतिरिक्त कार्य आवश्यक नहीं है; जैसे ही वे पाइप से उतरते हैं आप बाइट्स को पढ़ / लिख लेते हैं। 7bitसामग्री को नेत्रगोलक करना और उसकी समझ बनाना भी आसान है। यहाँ विचार यह है कि यदि आप "सादे अंग्रेजी पाठ" में लिख रहे हैं तो आप ठीक हो जाएंगे। लेकिन 2005 में यह सच नहीं था और यह आज भी सच नहीं है।
8bit"मेरे डेटा में विस्तारित ASCII वर्ण शामिल हो सकते हैं; वे मानक US-ASCII 7-बिट वर्णों के बाहर विशेष वर्णों को इंगित करने के लिए 8 वें (उच्चतम) बिट का उपयोग कर सकते हैं।" जैसा कि 7bit, अभी भी 1000-वर्ण रेखा की सीमा है।
8bit, जैसे 7bit, वे वास्तव में बाइट्स का कोई भी परिवर्तन नहीं करते हैं क्योंकि वे तार से लिखे या पढ़े जाते हैं। इसका मतलब सिर्फ इतना है कि आप इस बात की गारंटी नहीं दे रहे हैं कि किसी भी बाइट में सबसे ज्यादा "1" का सेट नहीं होगा।
यह एक कदम से ऊपर की तरह लगता है 7bit, क्योंकि यह आपको अपनी सामग्री में अधिक स्वतंत्रता देता है। हालाँकि, RFC 1341 में यह tidbit समाहित है:
इस दस्तावेज़ के प्रकाशन के रूप में, कोई मानकीकृत इंटरनेट परिवहन नहीं है, जिसके लिए मेल बॉडी में अनएन्कोडेड 8-बिट या बाइनरी डेटा शामिल करना वैध है। इस प्रकार ऐसी कोई परिस्थिति नहीं है जिसमें "8 बिट" या "बाइनरी" सामग्री-स्थानांतरण-एन्कोडिंग वास्तव में इंटरनेट पर कानूनी है।
RFC 1341 20 साल पहले आया था। तब से हम RFC 6152 में 8bit MIME एक्सटेंशन प्राप्त कर चुके हैं । लेकिन फिर भी, लाइन सीमाएं अभी भी लागू हो सकती हैं:
ध्यान दें कि यह एक्सटेंशन एक SMTP सर्वर को सीमित करने की संभावना को समाप्त नहीं करता है; सर्वर इस एक्सटेंशन को लागू करने के लिए स्वतंत्र हैं, लेकिन फिर भी एक लाइन की लंबाई 1000 ऑक्टेट से कम नहीं है।
binaryके रूप में ही है 8bit, सिवाय इसके कि कोई लाइन लंबाई प्रतिबंध नहीं है। आप अभी भी अपने इच्छित किसी भी वर्ण को शामिल कर सकते हैं, और कोई अतिरिक्त एन्कोडिंग नहीं है। 8bitRFC 1341 के समान , यह बताता है कि यह वास्तव में एक वैध एन्कोडिंग ट्रांसफर एन्कोडिंग नहीं है। RFC 3030 ने इसे बढ़ाया BINARYMIME।
8BITMIMEएक्सटेंशन से पहले , 7bitSMTP पर नहीं जा सकने वाली सामग्री भेजने का एक तरीका होना चाहिए । HTML फ़ाइलें (जिनमें 1000 से अधिक वर्ण रेखाएँ हो सकती हैं) और अंतर्राष्ट्रीय वर्णों वाली फ़ाइलें इसके अच्छे उदाहरण हैं। quoted-printableएन्कोडिंग (RFC 1341 की धारा 5.1 में परिभाषित किया जाता है) इस संभाल करने के लिए बनाया गया है। यह दो काम करता है:
बचने और छोटी लाइनों की वजह से, उद्धरित मुद्रण योग्य, बहुत कठिन की तुलना में एक मानव द्वारा पढ़ने के लिए है 7bitया 8bit, लेकिन यह संभव सामग्री की एक अधिक व्यापक रेंज का समर्थन करता है।
यदि आपका डेटा काफी हद तक गैर-पाठ (उदा: एक छवि फ़ाइल) है, तो आपके पास कई विकल्प नहीं हैं। 7bitतालिका से बाहर है। 8bitऔर binaryMIME एक्सटेंशन RFC से पहले असमर्थित थे। quoted-printableकाम करेगा, लेकिन वास्तव में अक्षम है (प्रत्येक बाइट का प्रतिनिधित्व 3 वर्णों द्वारा किया जाएगा)।
base64इस प्रकार के डेटा के लिए एक अच्छा समाधान है। यह 4 यूएस-एएससीआईआई पात्रों के रूप में 3 कच्चे बाइट्स को एनकोड करता है, जो अपेक्षाकृत कुशल है। RFC 1341 base64एक SMTP संदेश के भीतर फिट होने के लिए 76 अक्षरों की डेटा लाइन की लंबाई को और सीमित कर देता है , लेकिन यह तय करना अपेक्षाकृत आसान है कि आप तय लंबाई में मनमाने अक्षरों को विभाजित या समेट रहे हैं।
बड़ी नकारात्मक बात यह है कि base64-encoded डेटा मनुष्यों द्वारा बहुत अधिक पूरी तरह से अपठनीय है, भले ही यह "सादे" पाठ के नीचे हो।