ईमेल विषय की लंबाई सीमा क्या है?

227

इंटरनेट ईमेल की विषय पंक्ति में कितने वर्ण होने की अनुमति है? मेरे पास ईमेल के लिए RFC का स्कैन था लेकिन यह विशेष रूप से नहीं देख सकता था कि इसे कब तक होने दिया जाए। मेरे पास एक सहयोगी है जो इसके लिए प्रोग्रामेटिक रूप से मान्य करना चाहता है।

यदि कोई औपचारिक सीमा नहीं है, तो सुझाव देने के लिए व्यवहार में एक अच्छी लंबाई क्या है?

email limit

— स्कॉट फर्ग्यूसन
स्रोत

17

255 कुछ टिकट उत्पादों पर सीमा (उदाहरण के लिए Jira) और दृष्टिकोण पर सीमा प्रतीत हो रहा है, थंडरबर्ड और जीमेल के बाद 130. काटना लगते हैं

— reconbot

1

RFC2047 सत्यापन के लिए बेहतर है, मुझे अमान्य RFC2047 सामग्री का उत्पादन करने वाले बहुत सारे थोक-मेलिंग सॉफ़्टवेयर दिखाई देते हैं।

— ०37:

3

डेटाबेस में यह बहुत आम है (एक परंपरा जिसे आप कह सकते हैं) विशेष रूप से लंबे या छोटे पाठ क्षेत्रों की लंबाई को परिभाषित करने के लिए VARCHAR (255) या इसी तरह के समकक्ष नाम। यदि एक लंबी स्ट्रिंग प्रस्तुत की जाती है, तो यह एक त्रुटि उत्पन्न करेगा या बस सीमा को छोटा कर देगा। यही कारण है कि यहाँ उल्लेखित जीरा और आउटलुक अधिक वर्णों का समर्थन नहीं करते हैं। संगतता कारणों के लिए, मैं 255+ की सिफारिश नहीं करूँगा 5 साल पुराने केक पर सिर्फ कुछ क्रीम जोड़ने;)

— अल्फ

195

आरएफसी 2822 , खंड 2.1.1 देखें ।

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

जैसा कि RFC बाद में बताता है, आप इस सीमा के आसपास काम कर सकते हैं (ऐसा नहीं है कि आपको) कई लाइनों पर विषय को मोड़कर।

प्रत्येक शीर्ष लेख फ़ील्ड तार्किक रूप से फ़ील्ड नाम, बृहदान्त्र और फ़ील्ड बॉडी वाले वर्णों की एक एकल पंक्ति होती है। हालाँकि, सुविधा के लिए, और प्रति पंक्ति 998/78 वर्ण सीमाओं से निपटने के लिए, हेडर फ़ील्ड के फ़ील्ड बॉडी भाग को कई लाइन प्रतिनिधित्व में विभाजित किया जा सकता है; इसे "फोल्डिंग" कहा जाता है। सामान्य नियम यह है कि जहां कहीं भी यह मानक सफेद स्थान को तह करने की अनुमति देता है (केवल WSP वर्ण नहीं), किसी भी WSP से पहले CRLF डाला जा सकता है। उदाहरण के लिए, शीर्ष लेख फ़ील्ड:
       Subject: This is a test
के रूप में प्रतिनिधित्व किया जा सकता है:
       Subject: This
        is a test

विषय हेडर में 78 से अधिक वर्णों के लिए अनुशंसा उचित नहीं लगती है। संपूर्ण विषय पंक्ति को देखने के लिए कोई भी स्क्रॉल नहीं करना चाहता है, और कुछ महत्वपूर्ण सही पर कट सकता है।

— माइकल पेट्रोत्ता
स्रोत

8

आईएमएफ कल्पना का मौजूदा संस्करण, आरएफसी 5322, यहां पाया जा सकता है: tools.ietf.org/html/rfc5322#section-2.1.1

— james.garriss

6

यह उत्तर केवल लाइन की लंबाई सीमा को संबोधित करता है, न कि समग्र लंबाई सीमा को।

— चलि

1

RFC है और प्रयोज्य है। जैकब नील्सन लेख ईमेल विषय लाइनें: पाठकों को आकर्षित करने के लिए 5 युक्तियां संक्षेप में प्रस्तुत करती हैं: "पहले 40 वर्णों पर ध्यान दें। वर्णनात्मक और अच्छी तरह से लिखी गई विषय पंक्तियां प्राप्तकर्ताओं को अधिक विवरण प्राप्त करने या आगे बढ़ने के लिए एक सूचित निर्णय लेने की अनुमति देती हैं।"

— लोपेज

3

स्पष्ट करने के लिए, विषय लाइनों के लिए कोई लंबाई सीमा नहीं है, क्योंकि मानक हेडर को 998 बाइट्स से अधिक लंबे समय तक एक ही हेडर लपेटकर अधिक से अधिक लाइन्स की अनुमति देते हैं। ~ 80 वर्णों की सिफारिश वास्तव में एक उचित है। आप एक ईमेल क्लाइंट में लिख रहे हैं आप है जब एक सूची के भाग के रूप दिखा काट-छांट से एक भयानक तरह से तोड़ने के बिना हास्यास्पद लंबे विषयों से निपटने के लिए, खासकर सक्षम होने के लिए।

— थोमसट्रेटर

1

... यह किसी अन्य हेडर फ़ील्ड के साथ भी होगा (जैसे "From")। PS यदि आप सोच रहे हैं कि 80 के बजाय 78 क्यों, या 1000 के बजाय 998 क्यों, यह इसलिए है क्योंकि ईमेल मानक CRLF (\ r \ n) को विभाजक के रूप में निर्दिष्ट करता है, जो कि दो बाइट्स हैं, जिससे यह 1000 बाइट्स प्रति पंक्ति हो जाती है जिसमें 998 हेडर ही। यह भी ध्यान दें कि हेडर का नाम और कोलन के बाद के किसी भी स्थान जैसे "विषय:" में भी फिट होना है।

— थोमसट्रेटर

20

RFC2322 में कहा गया है कि विषय हेडर में "कोई लंबाई प्रतिबंध नहीं है"

लेकिन लंबे हेडर का उत्पादन करने के लिए लेकिन आपको इसे कई लाइनों में विभाजित करना होगा, एक प्रक्रिया जिसे "तह" कहा जाता है।

विषय को RFC 5322 में "असंरचित" के रूप में परिभाषित किया गया है

यहाँ कुछ उद्धरण ([...] इंगित सामान मैं छोड़ा गया)

3.6.5. Informational Fields
  The informational fields are all optional.  The "Subject:" and
  "Comments:" fields are unstructured fields as defined in section
  2.2.1, [...]

2.2.1. Unstructured Header Field Bodies
  Some field bodies in this specification are defined simply as
  "unstructured" (which is specified in section 3.2.5 as any printable
  US-ASCII characters plus white space characters) with no further
  restrictions.  These are referred to as unstructured field bodies.
  Semantically, unstructured field bodies are simply to be treated as a
  single line of characters with no further processing (except for
  "folding" and "unfolding" as described in section 2.2.3).

2.2.3  [...]  An unfolded header field has no length restriction and
  therefore may be indeterminately long.

— Jasen
स्रोत

@ हसन आप तह के लिए एक उपकरण जानते हैं?

— महदी

किसी भी अच्छी तरह से लिखा ईमेल पुस्तकालय ऐसा करेगा। मेरा पसंदीदा हैc-client

— जस

यह सही जवाब है। प्रश्न का दूसरा भाग "व्यवहार में अच्छी लंबाई" पूरी तरह से आपके ऐप पर निर्भर करता है। यदि आप प्राप्त ईमेल को सहेज रहे हैं तो आपको असीमित लंबाई का समर्थन करना होगा।

— रोब

4

कुछ परीक्षण के बाद: यदि आप एक आउटलुक क्लाइंट को एक ईमेल भेजते हैं, और विषय> 77 वर्ण है, और इसे "=?ISO"विषय के अंदर उपयोग करने की आवश्यकता है (उच्चारण के कारण मेरे मामले में) तो OutLook विषय को "बीच में" काट देगा यह और यह सब है कि बाद में आता है, शरीर पाठ, संलग्न, आदि सहित सभी जाल ... सभी जाल!

मेरे पास इस तरह के कई उदाहरण हैं:

Subject: =?ISO-8859-1?Q?Actas de la obra N=BA.20100154 (Expediente N=BA.20100182) "NUEVA RED FERROVIARIA.=

TRAMO=20BEASAIN=20OESTE(Pedido=20PC10/00123-125),=20BEASAIN".?=

सेवा:

जैसा कि आप देख रहे हैं, विषय पंक्ति में इसे "=" के साथ char 78 पर काटा गया, उसके बाद 2 या 3 पंक्ति फ़ीड्स, फिर शेष विषय को खराब तरीके से जारी रखा।

यह मेरे लिए कई ग्राहकों से बताया गया था, जहां सभी OutLook का उपयोग करते हैं, अन्य ईमेल क्लाइंट उन विषयों के साथ ठीक व्यवहार करते हैं।

यदि आपके पास इस पर कोई आईएसओ नहीं है, तो यह चोट नहीं पहुंचाता है, लेकिन यदि आप इसे अपने विषय में जोड़कर RFC के लिए अच्छा है, तो आपको यह आश्चर्य चकित कर देता है। बिट यदि आप ISO नहीं जोड़ते हैं, तो iPhone ईमेल इसे नहीं समझेगा (और ऐसे वर्णों का उपयोग करने वाले नामों के साथ फ़ाइलें संलग्न करें जो iPhones पर काम नहीं करेगा)।

— सर्जियो
स्रोत

5

आपके द्वारा निर्धारित विषय के साथ कई समस्याएं हैं: 1. रिक्त स्थान '_' के साथ एन्कोडेड होना चाहिए, 2. एक 'एन्कोडेड-वर्ड' (=? Charset? क्यू / बी? डेटा? =) 75 से अधिक वर्ण लंबे नहीं हो सकते हैं? (rfc2047)। 3 आप लाइन के अंत में '=' चार के साथ नई लाइन से बच नहीं सकते (हेडर QP एन्कोडिंग अलग है तो बॉडी QP)। निचला रेखा है: यह आउटलुक की गलती नहीं है।

— पावेल लेस्निकोवस्की

2

मुझे विश्वास नहीं होता कि यहां कोई औपचारिक सीमा है, और मुझे पूरा यकीन है कि RFC में कोई भी कठिन सीमा निर्दिष्ट नहीं है, जैसा कि आपने पाया।

मुझे लगता है कि सामान्य रूप से (केवल ई-मेल नहीं) विषय रेखाओं के लिए कुछ बहुत ही सामान्य सीमाएँ हैं:

80 वर्ण
128 वर्ण
256 वर्ण

जाहिर है, आप कुछ ऐसा करना चाहते हैं जो वाजिब हो। यदि आप एक ई-मेल क्लाइंट लिख रहे हैं, तो आप 256 वर्णों जैसी किसी चीज़ के साथ जा सकते हैं, और जाहिर है कि बड़े वाणिज्यिक सर्वरों के खिलाफ पूरी तरह से परीक्षण करें ताकि यह सुनिश्चित हो सके कि वे आपके मेल को सही ढंग से सेवा दें।

उम्मीद है की यह मदद करेगा!

— एड अल्टोफर
स्रोत

13

कोई विशेष कारण नहीं है कि क्यों 256 250, या 300, या 372 से कोई बेहतर है। हम लंबे समय तक स्ट्रिंग लंबाई के लिए बाइट्स का उपयोग कर रहे हैं।

— ग्रेग हेविगेल

4

255 कुछ उत्पादों (उदाहरण के लिए जीरा और आउटलुक) पर वास्तविक सीमा है

— कनेक्ट करें

5

यह उत्तर गलत है। आरएमएफ 5322, आईएमएफ कल्पना का वर्तमान संस्करण, स्पष्ट रूप से अधिकतम लाइन लंबाई को परिभाषित करता है। @ माइकल का जवाब देखें।

— james.garriss

2

+1 लाइन लंबाई सीमा संदेश की सभी पंक्तियों के लिए है, लेकिन मुझे ऐसा कुछ भी दिखाई नहीं देता है जिसमें कहा गया हो कि आपके पास एक विषय अवधि कई पंक्तियाँ नहीं हो सकती हैं (विषय के लिए वर्णों की संख्या पर कोई सीमा नहीं है)। २.२.३ देखें और उसके बाद के उदाहरण को सीधे देखें।

— साइफ्रे

1

VARCHAR 255 शायद MySQL / MariaDB में सबसे आम (और अधिक कुशल) डेटा कॉलम लंबाई है। बाइट्स सबसे निश्चित रूप से अभी भी प्रासंगिक हैं। MySQL लंबाई को स्टोर करने के लिए 1 बाइट का उपयोग करेगा यदि यह 256 से कम है, या अधिक अन्यथा। यदि आप सोचते हैं कि C ++ का उपयोग कैसे किया जाता है :: स्ट्रिंग स्ट्रिंग पर विचार करें यदि स्ट्रिंग की लंबाई अत्यधिक महत्वपूर्ण नहीं है और बाइट्स में गिना जाता है।

— ebyrob

0

ईमेल भेजना क्या महत्वपूर्ण है, आप किस तंत्र का उपयोग कर रहे हैं। अधिकांश आधुनिक पुस्तकालय (यानी System.Net.Mail) आपसे तह छिपाएंगे। आप बिना (सीआर, एलएफ, एचटीएबी) के बिना एक बहुत लंबी ईमेल विषय पंक्ति डालते हैं। यदि आप अपने स्वयं के तह करने की कोशिश करना शुरू करते हैं तो सभी दांव बंद हो जाते हैं। यह त्रुटियों की रिपोर्ट करना शुरू कर देगा। इसलिए यदि आप इस समस्या को सिर्फ सीआर, एलएफ, एचटीएबी से दूर करते हैं और लाइब्रेरी को आपके लिए काम करने देते हैं। आप आमतौर पर एन्कोडिंग पाठ प्रकार को एक अलग क्षेत्र के रूप में भी सेट कर सकते हैं। विषय पंक्ति में आइसो एनकोडिंग की कोई आवश्यकता नहीं है।

— kariato
स्रोत