क्या आप ईमेल के भीतर शब्द रैपिंग का उपयोग करते हैं?

Question

मुझे आश्चर्य है कि पाठ ईमेल में शब्द रैपिंग लागू की जानी चाहिए? और एचटीएमएल ईमेल के बारे में क्या? यदि हां, तो आप आम तौर पर किस चरित्र को लपेटेंगे?

Answer 1

RFC 2646 का कहना है:

पाठ/सादा मीडिया प्रकार

(आमतौर पर 80 से ज्यादा कोई प्रथा के अनुसार), इंटरनेट ई-मेल की सबसे कम आम विभाजक है अधिक से अधिक 997 पात्रों में से लाइनों के साथ

एक और लोकप्रिय मानक 72 अक्षरों पर लपेटना है। यह कई कंसोल अनुप्रयोगों (जैसे EDIT और कई बीबीएस इंटरफेस) पर वापस आता है जो एक एएससीआईआईआई "विंडो" के भीतर एक सीमा और स्क्रॉलबार सहित टेक्स्ट प्रदर्शित करता है, जिससे 80 वर्णों से थोड़ा कम प्रदर्शित किया जा सकता है।

Answer 2

आम तौर पर आपको डिली क्लाइंट को रैपिंग के बिना उद्धरण देने के लिए 80 या थोड़ा कम लपेटना चाहिए।

Answer 3

लाइनवैप का उपयोग नहीं किया, जब तक कि मैंने mutt/xterm (कभी वापस नहीं देखा) पर स्विच किया हो।

Answer 4

72 वें स्थान से पहले पहले व्हाइटस्पेस चरित्र पर लपेटें, या 72 वें स्थान पर यदि कोई नहीं है तो लपेटें। युडोरा में जब मैं इसका उपयोग करता था, तो सम्मेलन लाइन के अंत में एक जगह छोड़ना था जो इंगित करता था कि यह लपेटा गया था, इसलिए यह प्राप्तकर्ता क्लाइंट को अनुच्छेद को फिर से प्रवाह करने के लिए सिग्नल करेगा जहां इसकी आवश्यकता होती है ग्राहक की खिड़की मुझे यकीन नहीं है कि वर्तमान ईमेल क्लाइंट में यह मामला है।

Answer 5

उद्धरण के कम से कम एक या दो स्तरों को संभालने के लिए 72 (80 भी सामान्य है लेकिन इसका मतलब है कि यह उद्धृत होने पर 80 से अधिक हो जाएगा) पर लाइनों को लपेटना आम है। "टेक्स्ट/फ्लोइड" एमआईएमई प्रकार है जिसका अर्थ है कि क्लाइंट विंडो की सीमाओं पर खुद को टेक्स्ट लपेट लेगा, लेकिन यह नहीं कि कई ग्राहक इसका समर्थन करते हैं। बस 72 पर लपेटने के लिए अपने संपादक को सेटअप करें और आप अधिकांश लोगों द्वारा सुरक्षित और पठनीय होंगे।

संपादित करें: ठीक वैसी ही इस तरह format=flowed के योग के साथ text/plain है:

Content-Type: text/plain; format=flowed 

स्पष्टीकरण के लिए rfc2646 देखें।

एचटीएमएल मेल से बचा जाना चाहिए IMNSHO, हर कोई ब्राउज़र में मेल नहीं पढ़ता है या HTML- सक्षम मेल क्लाइंट नहीं है। HTML का उपयोग करने के अधिकांश कारण (अंडरलाइन, बोल्ड और इस तरह के मेल को समृद्ध करना) नकल किया जा सकता है। एचटीएमएल को लपेटने की जरूरत नहीं है क्योंकि क्लाइंट विंडो आकार में अनुकूलित होगा।

एचटीएमएल का एक विकल्प "टेक्स्ट/समृद्ध" एमआईएमई प्रकार है जो आपको एचटीएमएल मेल के अधिकांश फायदे देता है, लेकिन परेशानी है, लेकिन फिर भी, हर जगह समर्थित नहीं हो सकता है।

टेक्स्ट/समृद्ध के लिए here देखें।

Answer 6

गूगल का कहना है कि परिणाम 1 - 10 के बारे में ...

3,160 for +word +wrap +email +"80 characters" 
2,820 for +word +wrap +email +"50 characters" 
1,790 for +word +wrap +email +"60 characters" 
1,720 for +word +wrap +email +"70 characters" 
1,540 for +word +wrap +email +"100 characters" 
1,250 for +word +wrap +email +"65 characters" 
1,120 for +word +wrap +email +"40 characters" 
    962 for +word +wrap +email +"75 characters" 
    836 for +word +wrap +email +"72 characters" 

Answer 7

मैं अक्सर ई-मेल शुरू कर अपने आप को खोजने के साथ उत्तर:

[Format recovered--see http://www.lemis.com/grog/email/email-format.php] 

जो मैं ग्रेग Lehey से मिला है।that page का हिस्सा कहता है:

स्पष्ट रूप से, यह निर्दिष्ट करने का कोई तरीका होना चाहिए कि संदेश टेक्स्ट को लपेटा नहीं जाना चाहिए। वह पाठ/सादा है। विशेष MIME अनुलग्नक प्रकार हैं जो रैपिंग की अनुमति देते हैं, हालांकि मुझे अभी भी लगता है कि यह एक बुरा विचार है। यदि आप निर्दिष्ट करते हैं कि आपका संदेश लपेटा जा सकता है, तो आप रिसीवर की स्क्रीन कैसा दिखता है इसके बारे में एक धारणा बना रहे हैं। यहां तक ​​कि यदि आप कुछ समय सही हैं, तो आप हर समय सही नहीं हो सकते हैं। उदाहरण के लिए, एक व्यक्ति के पास लंबी लॉग फ़ाइल प्रविष्टियों को प्रदर्शित करने में सक्षम होने के लिए 200 वर्ण विस्तृत स्क्रीन हो सकती है, लेकिन वह लंबे समय तक अपना टेक्स्ट नहीं देखना चाहेंगे।

Answer 8

JavaMail जैसे एक अच्छा मेल एपीआई आपके लिए यह करेगा। आदर्श रूप से, आपको इस मुद्दे के बारे में स्पष्ट रूप से सोचना नहीं होगा।

Answer 9

आरएफसी 5322

http://tools.ietf.org/html/rfc5322#section-2.1.1

2.1.1। रेखा की लंबाई सीमा

इस सीमा का एक पंक्ति में वर्णों की संख्या पर दो सीमाएं हैं। वर्णों की प्रत्येक पंक्ति 998 वर्णों से अधिक नहीं होनी चाहिए, और को CRLF को छोड़कर 78 वर्णों से अधिक नहीं होना चाहिए।

998 वर्ण सीमा कई कार्यान्वयन में सीमाओं के कारण है जो आईएमएफ संदेशों को भेज, प्राप्त या स्टोर करती है जो आसानी से लाइन पर 998 से अधिक वर्णों को संभाल नहीं सकती हैं। कार्यान्वयन प्राप्त करने के लिए मजबूती के लिए लाइन में मनमाने ढंग से बड़ी संख्या में वर्णों को संभालने के लिए अच्छा होगा। हालांकि, ऐसे कई कार्यान्वयन हैं जो ([आरएफसी 5321] की परिवहन आवश्यकताओं के अनुपालन में) सीआर और प्रति पंक्ति एलएफ सहित 1000 से अधिक वर्ण वाले संदेशों को स्वीकार करते हैं, यह जैसे कार्यान्वयन के लिए महत्वपूर्ण है। संदेश।

अधिक रूढ़िवादी 78 चरित्र सिफारिश तथ्य यह है कि के बावजूद यूजर इंटरफेस के कई प्रयोगों है कि इन संदेशों जो काट-छांट कर सकते हैं या आपत्ति के साथ लपेट प्रदर्शित करते हैं, प्रति पंक्ति 78 वर्णों से अधिक का प्रदर्शन, समायोजित करने के लिए है ऐसे कार्यान्वयन इस विनिर्देश (और [RFC5321] के इरादे से गैर-अनुरूप हैं यदि वे वास्तव में खोने की जानकारी का कारण बनते हैं)। फिर भी, भले ही यह सीमा संदेशों पर रखी गई हो, यह संदेशों को पंक्तियों में निश्चित रूप से के लिए लाइन (निश्चित रूप से कम से कम 998 वर्ण सीमा तक) में मनमाने ढंग से बड़ी संख्या में वर्णों को संभालने के लिए प्रदर्शित करता है। ।

यह भी देखें: RFC2045, RFC2046, RFC2047, RFC2049, RFC4289 & RFC6838 माइम चश्मा के लिए।

यह आरएफसी पढ़ने में मजेदार है। आप जानते हैं कि आप इसे प्यार करते हैं :-)