8-बिट क्लीन: Difference between revisions

From Vigyanwiki
(Created page with "{{Short description|Computer system that correctly handles 8-bit character encodings}} {{More citations needed|date=June 2008}} ''8-बिट क्लीन'' कंप...")
 
No edit summary
Line 5: Line 5:


== इतिहास ==
== इतिहास ==
1990 के दशक की शुरुआत तक, कई प्रोग्राम और डेटा ट्रांसमिशन चैनल चरित्र-उन्मुख थे और कुछ वर्णों, जैसे, एंड-ऑफ़-टेक्स्ट वर्ण, को नियंत्रण वर्ण के रूप में मानते थे। अन्य ने 0 और 127 के बीच मानों के साथ सात-[[ अंश ]] वर्णों की एक धारा मान ली; उदाहरण के लिए, ASCII मानक डेटा ट्रांसमिशन लागत को बचाने के लिए 8-बिट प्रतिनिधित्व ASCII#Bit चौड़ाई| से बचते हुए, प्रति वर्ण केवल सात बिट्स का उपयोग करता है। [[बाइट]]#8-बिट बाइट्स|8-बिट बाइट्स का उपयोग करने वाले कंप्यूटर और डेटा लिंक पर इसने प्रत्येक बाइट के शीर्ष बिट को [[ समता द्वियक ]], [[ध्वज बिट]] या मेटा डेटा नियंत्रण बिट के रूप में उपयोग के लिए निःशुल्क छोड़ दिया। 7-बिट सिस्टम और डेटा लिंक अधिक जटिल वर्ण कोड को सीधे संभालने में असमर्थ हैं जो बड़े अक्षर वाले गैर-[[अंग्रेजी भाषा]]-भाषी देशों में आम हैं।
1990 के दशक की शुरुआत तक, कई प्रोग्राम और डेटा ट्रांसमिशन चैनल करैक्टर ओरिएंटेड थे और कुछ कैरेक्टर, जैसे, ईटीएक्स, को कंट्रोल कैरेक्टर के रूप में मानते थे। अन्य ने 0 और 127 के बीच मानों के साथ सात-बिट कैरेक्टर की एक धारा मान ली; उदाहरण के लिए, ASCII मानक डेटा ट्रांसमिशन लागत को बचाने के लिए 8-बिट प्रतिनिधित्व से बचते हुए, प्रति कैरेक्टर केवल सात बिट्स का उपयोग करता है। 8-बिट बाइट्स का उपयोग करने वाले कंप्यूटर और डेटा लिंक पर इसने प्रत्येक बाइट के शीर्ष बिट को [[समता द्वियक| समता]] [[ध्वज बिट|फ़्लैग बिट]] या मेटा डेटा नियंत्रण बिट के रूप में उपयोग के लिए निःशुल्क छोड़ दिया। 7-बिट सिस्टम और डेटा लिंक अधिक जटिल कैरेक्टर कोड को सीधे संभालने में असमर्थ हैं जो बड़े अक्षर वाले गैर-[[अंग्रेजी भाषा]]-भाषी देशों में आम हैं।


[[ऑक्टेट (कंप्यूटिंग)]] की [[बाइनरी फ़ाइल]]ें 7-बिट डेटा चैनलों के माध्यम से सीधे प्रसारित नहीं की जा सकतीं। इसके आसपास काम करने के लिए, [[बाइनरी-टू-टेक्स्ट एन्कोडिंग]] तैयार की गई है जो केवल 7-बिट ASCII वर्णों का उपयोग करती है। इनमें से कुछ एन्कोडिंग [[ uuencoding ]], [[एएससीआईआई]]85, [[एसआरईसी (फ़ाइल प्रारूप)]], [[बिनहेक्स]], [[केर्मिट (प्रोटोकॉल)]] और एमआईएमई का बेस64 हैं। [[ EBCDIC ]]-आधारित सिस्टम यूयूएनकोडेड डेटा में उपयोग किए गए सभी वर्णों को संभाल नहीं सकते हैं। हालाँकि, बेस64 एन्कोडिंग में यह समस्या नहीं है।
[[ऑक्टेट (कंप्यूटिंग)|ऑक्टेट]] की [[बाइनरी फ़ाइल|बाइनरी फ़ाइलें]] 7-बिट डेटा चैनलों के माध्यम से सीधे प्रसारित नहीं की जा सकतीं। इसके आसपास काम करने के लिए, [[बाइनरी-टू-टेक्स्ट एन्कोडिंग]] तैयार की गई है जो केवल 7-बिट ASCII कैरेक्टर का उपयोग करती है। इनमें से कुछ एन्कोडिंग [[ uuencoding]] , [[एएससीआईआई]]85, [[एसआरईसी (फ़ाइल प्रारूप)]], [[बिनहेक्स]], [[केर्मिट (प्रोटोकॉल)|केर्मिट]] और एमआईएमई का बेस 64 हैं। [[ EBCDIC]] -आधारित सिस्टम यूयूएनकोडेड डेटा में उपयोग किए गए सभी कैरेक्टर को संभाल नहीं सकते हैं। यद्यपि, बेस 64 एन्कोडिंग में यह समस्या नहीं है।


==एसएमटीपी और एनएनटीपी 8-बिट सफाई==
==एसएमटीपी और एनएनटीपी 8-बिट सफाई==
ऐतिहासिक रूप से, संदेशों को स्थानांतरित करने के लिए विभिन्न मीडिया का उपयोग किया जाता था, उनमें से कुछ केवल 7-बिट डेटा का समर्थन करते थे, इसलिए 20वीं शताब्दी में ट्रांसमिशन के दौरान 8-बिट संदेश के मोजिबेक होने की उच्च संभावना थी। लेकिन कुछ कार्यान्वयनों ने वास्तव में 8-बिट डेटा को औपचारिक रूप से हतोत्साहित करने की परवाह नहीं की और उच्च बिट सेट बाइट्स को पारित करने की अनुमति दी। ऐसे कार्यान्वयन को 8-बिट साफ़ कहा जाता है। सामान्य तौर पर, एक [[संचार प्रोटोकॉल]] को 8-बिट क्लीन कहा जाता है यदि यह संचार प्रक्रिया में प्रत्येक बाइट के उच्च बिट से सही ढंग से गुजरता है।
ऐतिहासिक रूप से, संदेशों को स्थानांतरित करने के लिए विभिन्न मीडिया का उपयोग किया जाता था, उनमें से कुछ केवल 7-बिट डेटा का समर्थन करते थे, इसलिए 20वीं शताब्दी में ट्रांसमिशन के दौरान 8-बिट संदेश के मोजिबेक होने की उच्च संभावना थी। लेकिन कुछ कार्यान्वयनों ने वास्तव में 8-बिट डेटा को औपचारिक रूप से हतोत्साहित करने की परवाह नहीं की और उच्च बिट सेट बाइट्स को पारित करने की अनुमति दी। ऐसे कार्यान्वयन को 8-बिट साफ़ कहा जाता है। सामान्य तौर पर, एक [[संचार प्रोटोकॉल]] को 8-बिट क्लीन कहा जाता है यदि यह संचार प्रक्रिया में प्रत्येक बाइट के उच्च बिट से सही ढंग से गुजरता है।


कई प्रारंभिक संचार प्रोटोकॉल मानक, जैसे {{IETF RFC|780|788|821|2821|5321}} ([[एसएमटीपी]] के लिए), {{IETF RFC|977}} ([[एनएनटीपी]] के लिए) और {{IETF RFC|1056|leadout=and}}, ऐसे 7-बिट संचार लिंक पर काम करने के लिए डिज़ाइन किए गए थे। उन्हें विशेष रूप से 8-बिट बाइट के रूप में प्रसारित ASCII कैरेक्टर सेट के उपयोग की आवश्यकता होती है, जिसमें उच्च-ऑर्डर बिट को शून्य पर साफ़ किया जाता है और इनमें से कुछ<ref>{{IETF RFC|780}}: Appendix&nbsp;A, {{IETF RFC|788}}: 4.5.2., {{IETF RFC|821}}: Appendix&nbsp;B, {{IETF RFC|1056}}: 4.</ref> सभी डेटा को स्पष्ट रूप से 7-बिट वर्णों तक सीमित रखें।
कई प्रारंभिक संचार प्रोटोकॉल मानक, जैसे {{IETF RFC|780|788|821|2821|5321}} ([[एसएमटीपी]] के लिए), {{IETF RFC|977}} ([[एनएनटीपी]] के लिए) और {{IETF RFC|1056|leadout=and}}, ऐसे 7-बिट संचार लिंक पर काम करने के लिए डिज़ाइन किए गए थे। उन्हें विशेष रूप से 8-बिट बाइट के रूप में प्रसारित ASCII कैरेक्टर सेट के उपयोग की आवश्यकता होती है, "उच्च-क्रम बिट को शून्य पर साफ़ करने के साथ 8-बिट बाइट के रूप में प्रेषित"  और इनमें से कुछ<ref>{{IETF RFC|780}}: Appendix&nbsp;A, {{IETF RFC|788}}: 4.5.2., {{IETF RFC|821}}: Appendix&nbsp;B, {{IETF RFC|1056}}: 4.</ref> स्पष्ट रूप से सभी डेटा को 7-बिट वर्णों तक सीमित करते हैं।


ईमेल नेटवर्क के पहले कुछ दशकों (1971 से 1990 के प्रारंभ तक) में, अधिकांश ईमेल संदेश 7-बिट यूएस-एएससीआईआई वर्ण सेट में [[सादे पाठ]] थे।<ref> John Beck. [http://www.sendmail.com/sm/open_source/docs/email_explained/ "Email Explained"]. 2011.</ref>
ईमेल नेटवर्क के पहले कुछ दशकों (1971 से 1990 के प्रारंभ तक) में, अधिकांश ईमेल संदेश 7-बिट यूएस-एएससीआईआई वर्ण सेट में [[सादे पाठ]] थे।<ref> John Beck. [http://www.sendmail.com/sm/open_source/docs/email_explained/ "Email Explained"]. 2011.</ref>


{{IETF RFC|788}एसएमटीपी की परिभाषा, अपने पूर्ववर्ती की तरह {{IETF RFC|780}}, इंटरनेट मेल को 7-बिट यूएस-एएससीआईआई वर्णों की पंक्तियों (1000 वर्ण या उससे कम) तक सीमित करता है।<ref>{{cite RFC
SMTP की <nowiki>RFC 788</nowiki> परिभाषा, अपने पूर्ववर्ती {{IETF RFC|780}} की तरह, इंटरनेट मेल को 7-बिट US-ASCII कैरेक्टर की पंक्तियों (1000 कैरेक्टर या उससे कम) तक सीमित करता है।<ref>{{cite RFC
  |        rfc = 788
  |        rfc = 788
  |      title = SIMPLE MAIL TRANSFER PROTOCOL
  |      title = SIMPLE MAIL TRANSFER PROTOCOL
Line 23: Line 23:
  |        date = November 1981
  |        date = November 1981
  |      author = Jonathan B. Postel
  |      author = Jonathan B. Postel
  }}
  }}</ref><ref>{{cite RFC
</ref><ref>{{cite RFC
  |        rfc = 1428
  |        rfc = 1428
  |      title = Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME
  |      title = Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME
Line 31: Line 30:
  | sectionname = 2. The Problem
  | sectionname = 2. The Problem
  |      quote = SMTP as defined in RFC 821 limits the sending of Internet Mail to US-ASCII characters.
  |      quote = SMTP as defined in RFC 821 limits the sending of Internet Mail to US-ASCII characters.
  }}
  }}</ref><ref>Dan Sugalski. [http://www.foo.be/docs/tpj/issues/vol4_2/tpj0402-0010.html "E-mail with Attachments"]. "The Perl Journal". Summer 1999. "When mail was standardized way back in 1982 with RFC822, ... The only limits placed on the body were the character set (7-bit ASCII) and the maximum line length (1000 characters)."</ref><ref name="RFC20452">{{cite RFC
</ref><ref> Dan Sugalski. [http://www.foo.be/docs/tpj/issues/vol4_2/tpj0402-0010.html "E-mail with Attachments"]. "The Perl Journal". Summer 1999. "When mail was standardized way back in 1982 with RFC822, ... The only limits placed on the body were the character set (7-bit ASCII) and the maximum line length (1000 characters)."</ref><ref name="RFC2045" />
|        rfc = 2045
|      title = Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
|    author1 = N. Freed
|    author2 = N. Borenstein
|        date = November 1996
| sectionname = Abstract
| quote = Multipurpose Internet Mail Extensions, or [[MIME]], redefines the format of messages
}}</ref>


बाद में उन संदेशों का समर्थन करने के लिए ईमेल संदेशों के प्रारूप को फिर से परिभाषित किया गया जो पूरी तरह से यूएस-एएससीआईआई टेक्स्ट नहीं हैं (यूएस-एएससीआईआई के अलावा अन्य वर्ण सेट में टेक्स्ट संदेश, और गैर-टेक्स्ट संदेश, जैसे ऑडियो और छवियां)।<ref name="RFC2045">{{cite RFC
बाद में उन संदेशों का समर्थन करने के लिए ईमेल संदेशों के प्रारूप को फिर से परिभाषित किया गया जो पूरी तरह से यूएस-एएससीआईआई टेक्स्ट नहीं हैं (यूएस-एएससीआईआई के अलावा अन्य वर्ण सेट में टेक्स्ट संदेश, और गैर-टेक्स्ट संदेश, जैसे ऑडियो और छवियां)।<ref name="RFC2045">{{cite RFC
Line 50: Line 56:
  |    date = October 2006
  |    date = October 2006
  |  author = C. Feather
  |  author = C. Feather
  }}
  }}</ref> निर्दिष्ट करता है कि एनएनटीपी किसी भी विश्वसनीय द्वि-दिशात्मक 8-बिट-वाइड डेटा स्ट्रीम चैनल पर संचालित होता है। और कमांड के लिए सेट किए गए कैरेक्टर को UTF-8 में बदल देता है। यद्यपि, {{IETF RFC|5536}}<ref>{{cite IETF
</ref> निर्दिष्ट करता है कि एनएनटीपी किसी भी विश्वसनीय द्वि-दिशात्मक 8-बिट-वाइड डेटा स्ट्रीम चैनल पर संचालित होता है। और कमांड के लिए सेट किए गए वर्ण को UTF-8 में बदल देता है। हालाँकि, {{IETF RFC|5536}}<ref>{{cite IETF
  |    rfc = 5536
  |    rfc = 5536
  |  title = Netnews Article Format
  |  title = Netnews Article Format
Line 58: Line 63:
  | author2 = D. Kohn
  | author2 = D. Kohn
  |  editor = K. Murchison
  |  editor = K. Murchison
}}
}}</ref> अभी भी कैरेक्टर सेट को ASCII तक सीमित करता है, जिसमें {{IETF RFC|2047}}<ref>{{cite RFC
</ref> अभी भी वर्ण सेट को ASCII तक सीमित करता है, जिसमें शामिल है {{IETF RFC|2047}}<ref>{{cite RFC
  |    rfc = 2047
  |    rfc = 2047
  |  title = MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text
  |  title = MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text
  |    date = November 1996
  |    date = November 1996
  |  author = K. Moore
  |  author = K. Moore
  }}
  }}</ref> और {{IETF RFC|2231}}<ref>{{cite IETF  
</ref> और {{IETF RFC|2231}}<ref>{{cite IETF  
  |    rfc = 2231
  |    rfc = 2231
  |  title = MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations
  |  title = MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations
Line 71: Line 74:
  | author1 = N. Freed
  | author1 = N. Freed
  | author2 = K. Moore
  | author2 = K. Moore
}}
}}</ref> गैर-ASCII डेटा की MIME एन्कोडिंग सम्मिलित है।
</ref> गैर-ASCII डेटा की MIME एन्कोडिंग।


इंटरनेट समुदाय आम तौर पर विस्तार द्वारा सुविधाओं को जोड़ता है, जिससे उन्नत मशीनों और अभी तक अपग्रेड नहीं की गई मशीनों के बीच दोनों दिशाओं में संचार की अनुमति मिलती है, न कि पहले के मानकों के अनुरूप विरासत सॉफ़्टवेयर को तोड़ने की घोषणा करने और इस बात पर ज़ोर देने के लिए कि दुनिया भर के सभी सॉफ़्टवेयर को नवीनतम मानक में अपग्रेड किया जाए। 1990 के दशक के मध्य में, लोग{{Who|date=February 2012}} सिर्फ 8 बिट्स (को) भेजने पर आपत्ति जताई {{IETF RFC|821}}एसएमटीपी सर्वर), शायद इस धारणा के कारण कि केवल 8 बिट भेजना एक अंतर्निहित घोषणा है कि [[आईएसओ 8859-1]] नया मानक एन्कोडिंग बन गया है, जो दुनिया में सभी को समान वर्ण सेट का उपयोग करने के लिए मजबूर करता है।{{Original research inline|date=February 2012}} इसके बजाय, मशीनों के बीच 8-बिट-क्लीन लिंक का लाभ उठाने का अनुशंसित तरीका ईएसएमटीपी का उपयोग करना है ({{IETF RFC|1869}}) [[8 बिटमाइम]] एक्सटेंशन<ref>{{Cite web|url=http://www.imc.org/ietf-smtp/old-archive/msg02018.html|title=8-bit transmission in NNTP|author=Theodore Ts'o|author-link=Theodore Ts'o|author2=Keith Moore|author2-link=Keith Moore|author3=Mark Crispin|author3-link=Mark Crispin|work=[[IETF]]-SMTP mail list|date=12 September 1994|access-date=3 April 2010|archive-url=https://web.archive.org/web/20120320233721/http://www.imc.org/ietf-smtp/old-archive/msg02018.html|archive-date=20 March 2012|url-status=dead|df=dmy-all}}</ref><ref>{{Cite web|url=http://www.uni-giessen.de/faq/archiv/mail.mime-faq.part1-9/msg00002.html|title=comp.mail.mime FAQ, part 3 'What's ESMTP, and how does it affect MIME?'|work=[[Usenet]] FAQs|date=8 August 1997|access-date=3 April 2010|archive-url=https://web.archive.org/web/20120118070711/http://www.uni-giessen.de/faq/archiv/mail.mime-faq.part1-9/msg00002.html|archive-date=18 January 2012|url-status=dead|df=dmy-all}} </ref> संदेश निकायों और SMTP [[SMTPUTF8]] के लिए<ref>{{cite IETF|
इंटरनेट समुदाय आम तौर पर विस्तार द्वारा सुविधाओं को जोड़ता है, जिससे उन्नत मशीनों और अभी तक अपग्रेड नहीं की गई मशीनों के बीच दोनों दिशाओं में संचार की अनुमति मिलती है, न कि पहले के मानकों के अनुरूप विरासत सॉफ़्टवेयर को तोड़ने की घोषणा करने और इस बात पर ज़ोर देने के लिए कि दुनिया भर के सभी सॉफ़्टवेयर को नवीनतम मानक में अपग्रेड किया जाए। 1990 के दशक के मध्य में, लोग{{Who|date=February 2012}} सिर्फ 8 बिट्स (को) भेजने पर आपत्ति जताई {{IETF RFC|821}}एसएमटीपी सर्वर), शायद इस धारणा के कारण कि केवल 8 बिट भेजना एक अंतर्निहित घोषणा है कि [[आईएसओ 8859-1]] नया मानक एन्कोडिंग बन गया है, जो दुनिया में सभी को समान वर्ण सेट का उपयोग करने के लिए मजबूर करता है।{{Original research inline|date=February 2012}} इसके बजाय, मशीनों के बीच 8-बिट-क्लीन लिंक का लाभ उठाने का अनुशंसित तरीका ईएसएमटीपी का उपयोग करना है ({{IETF RFC|1869}}) [[8 बिटमाइम]] एक्सटेंशन<ref>{{Cite web|url=http://www.imc.org/ietf-smtp/old-archive/msg02018.html|title=8-bit transmission in NNTP|author=Theodore Ts'o|author-link=Theodore Ts'o|author2=Keith Moore|author2-link=Keith Moore|author3=Mark Crispin|author3-link=Mark Crispin|work=[[IETF]]-SMTP mail list|date=12 September 1994|access-date=3 April 2010|archive-url=https://web.archive.org/web/20120320233721/http://www.imc.org/ietf-smtp/old-archive/msg02018.html|archive-date=20 March 2012|url-status=dead|df=dmy-all}}</ref><ref>{{Cite web|url=http://www.uni-giessen.de/faq/archiv/mail.mime-faq.part1-9/msg00002.html|title=comp.mail.mime FAQ, part 3 'What's ESMTP, and how does it affect MIME?'|work=[[Usenet]] FAQs|date=8 August 1997|access-date=3 April 2010|archive-url=https://web.archive.org/web/20120118070711/http://www.uni-giessen.de/faq/archiv/mail.mime-faq.part1-9/msg00002.html|archive-date=18 January 2012|url-status=dead|df=dmy-all}} </ref> संदेश निकायों और SMTP [[SMTPUTF8]] के लिए<ref>{{cite IETF|
Line 81: Line 83:
  | author2 = W. Mao
  | author2 = W. Mao
}}
}}
</ref> संदेश शीर्षलेखों के लिए एक्सटेंशन. इसके बावजूद, कुछ [[ मेल स्थानांतरण एजेंट ]], विशेष रूप से [[एग्जिम]] और [[ yamail ]], उन सर्वरों पर मेल रिले करते हैं जो आवश्यक 7-बिट एमआईएमई (आमतौर पर उद्धृत-मुद्रण योग्य, क्यू-पी रूपांतरण) में रूपांतरण किए बिना 8BITMIME का विज्ञापन नहीं करते हैं। {{IETF RFC|6152}}. यह जस्ट-सेंड-8 रवैया वास्तव में व्यवहार में समस्या पैदा नहीं करता है, क्योंकि वस्तुतः सभी आधुनिक ईमेल सर्वर 8-बिट साफ़ हैं।<ref>{{cite web|url=http://cr.yp.to/smtp/8bitmime.html|title=The 8BITMIME extension}}</ref>
</ref> संदेश शीर्षलेखों के लिए एक्सटेंशन. इसके बावजूद, कुछ [[ मेल स्थानांतरण एजेंट | मेल स्थानांतरण एजेंट]] , विशेष रूप से [[एग्जिम]] और [[ yamail | yamail]] , उन सर्वरों पर मेल रिले करते हैं जो आवश्यक 7-बिट एमआईएमई (आमतौर पर उद्धृत-मुद्रण योग्य, क्यू-पी रूपांतरण) में रूपांतरण किए बिना 8BITMIME का विज्ञापन नहीं करते हैं। {{IETF RFC|6152}}. यह जस्ट-सेंड-8 रवैया वास्तव में व्यवहार में समस्या पैदा नहीं करता है, क्योंकि वस्तुतः सभी आधुनिक ईमेल सर्वर 8-बिट साफ़ हैं।<ref>{{cite web|url=http://cr.yp.to/smtp/8bitmime.html|title=The 8BITMIME extension}}</ref>
 




Revision as of 09:04, 2 August 2023

8-बिट क्लीन कंप्यूटर प्रणाली , संचार चैनल और अन्य उपकरणों और सॉफ़्टवेयर की एक विशेषता है, जो 8-बिट कंप्यूटिंग|8-बिट अक्षरों को सांकेतिक अक्षरों में बदलना को सही ढंग से संभालती है। ऐसी एन्कोडिंग में ISO 8859 श्रृंखला और यूनिकोड की UTF-8 एन्कोडिंग शामिल है।

इतिहास

1990 के दशक की शुरुआत तक, कई प्रोग्राम और डेटा ट्रांसमिशन चैनल करैक्टर ओरिएंटेड थे और कुछ कैरेक्टर, जैसे, ईटीएक्स, को कंट्रोल कैरेक्टर के रूप में मानते थे। अन्य ने 0 और 127 के बीच मानों के साथ सात-बिट कैरेक्टर की एक धारा मान ली; उदाहरण के लिए, ASCII मानक डेटा ट्रांसमिशन लागत को बचाने के लिए 8-बिट प्रतिनिधित्व से बचते हुए, प्रति कैरेक्टर केवल सात बिट्स का उपयोग करता है। 8-बिट बाइट्स का उपयोग करने वाले कंप्यूटर और डेटा लिंक पर इसने प्रत्येक बाइट के शीर्ष बिट को समता फ़्लैग बिट या मेटा डेटा नियंत्रण बिट के रूप में उपयोग के लिए निःशुल्क छोड़ दिया। 7-बिट सिस्टम और डेटा लिंक अधिक जटिल कैरेक्टर कोड को सीधे संभालने में असमर्थ हैं जो बड़े अक्षर वाले गैर-अंग्रेजी भाषा-भाषी देशों में आम हैं।

ऑक्टेट की बाइनरी फ़ाइलें 7-बिट डेटा चैनलों के माध्यम से सीधे प्रसारित नहीं की जा सकतीं। इसके आसपास काम करने के लिए, बाइनरी-टू-टेक्स्ट एन्कोडिंग तैयार की गई है जो केवल 7-बिट ASCII कैरेक्टर का उपयोग करती है। इनमें से कुछ एन्कोडिंग uuencoding , एएससीआईआई85, एसआरईसी (फ़ाइल प्रारूप), बिनहेक्स, केर्मिट और एमआईएमई का बेस 64 हैं। EBCDIC -आधारित सिस्टम यूयूएनकोडेड डेटा में उपयोग किए गए सभी कैरेक्टर को संभाल नहीं सकते हैं। यद्यपि, बेस 64 एन्कोडिंग में यह समस्या नहीं है।

एसएमटीपी और एनएनटीपी 8-बिट सफाई

ऐतिहासिक रूप से, संदेशों को स्थानांतरित करने के लिए विभिन्न मीडिया का उपयोग किया जाता था, उनमें से कुछ केवल 7-बिट डेटा का समर्थन करते थे, इसलिए 20वीं शताब्दी में ट्रांसमिशन के दौरान 8-बिट संदेश के मोजिबेक होने की उच्च संभावना थी। लेकिन कुछ कार्यान्वयनों ने वास्तव में 8-बिट डेटा को औपचारिक रूप से हतोत्साहित करने की परवाह नहीं की और उच्च बिट सेट बाइट्स को पारित करने की अनुमति दी। ऐसे कार्यान्वयन को 8-बिट साफ़ कहा जाता है। सामान्य तौर पर, एक संचार प्रोटोकॉल को 8-बिट क्लीन कहा जाता है यदि यह संचार प्रक्रिया में प्रत्येक बाइट के उच्च बिट से सही ढंग से गुजरता है।

कई प्रारंभिक संचार प्रोटोकॉल मानक, जैसे RFC 780, 788, 821, 2821, 5321 (एसएमटीपी के लिए), RFC 977 (एनएनटीपी के लिए) और RFC 1056, ऐसे 7-बिट संचार लिंक पर काम करने के लिए डिज़ाइन किए गए थे। उन्हें विशेष रूप से 8-बिट बाइट के रूप में प्रसारित ASCII कैरेक्टर सेट के उपयोग की आवश्यकता होती है, "उच्च-क्रम बिट को शून्य पर साफ़ करने के साथ 8-बिट बाइट के रूप में प्रेषित" और इनमें से कुछ[1] स्पष्ट रूप से सभी डेटा को 7-बिट वर्णों तक सीमित करते हैं।

ईमेल नेटवर्क के पहले कुछ दशकों (1971 से 1990 के प्रारंभ तक) में, अधिकांश ईमेल संदेश 7-बिट यूएस-एएससीआईआई वर्ण सेट में सादे पाठ थे।[2]

SMTP की RFC 788 परिभाषा, अपने पूर्ववर्ती RFC 780 की तरह, इंटरनेट मेल को 7-बिट US-ASCII कैरेक्टर की पंक्तियों (1000 कैरेक्टर या उससे कम) तक सीमित करता है।[3][4][5][6]

बाद में उन संदेशों का समर्थन करने के लिए ईमेल संदेशों के प्रारूप को फिर से परिभाषित किया गया जो पूरी तरह से यूएस-एएससीआईआई टेक्स्ट नहीं हैं (यूएस-एएससीआईआई के अलावा अन्य वर्ण सेट में टेक्स्ट संदेश, और गैर-टेक्स्ट संदेश, जैसे ऑडियो और छवियां)।[7]

RFC 3977[8] निर्दिष्ट करता है कि एनएनटीपी किसी भी विश्वसनीय द्वि-दिशात्मक 8-बिट-वाइड डेटा स्ट्रीम चैनल पर संचालित होता है। और कमांड के लिए सेट किए गए कैरेक्टर को UTF-8 में बदल देता है। यद्यपि, RFC 5536[9] अभी भी कैरेक्टर सेट को ASCII तक सीमित करता है, जिसमें RFC 2047[10] और RFC 2231[11] गैर-ASCII डेटा की MIME एन्कोडिंग सम्मिलित है।

इंटरनेट समुदाय आम तौर पर विस्तार द्वारा सुविधाओं को जोड़ता है, जिससे उन्नत मशीनों और अभी तक अपग्रेड नहीं की गई मशीनों के बीच दोनों दिशाओं में संचार की अनुमति मिलती है, न कि पहले के मानकों के अनुरूप विरासत सॉफ़्टवेयर को तोड़ने की घोषणा करने और इस बात पर ज़ोर देने के लिए कि दुनिया भर के सभी सॉफ़्टवेयर को नवीनतम मानक में अपग्रेड किया जाए। 1990 के दशक के मध्य में, लोग[who?] सिर्फ 8 बिट्स (को) भेजने पर आपत्ति जताई RFC 821एसएमटीपी सर्वर), शायद इस धारणा के कारण कि केवल 8 बिट भेजना एक अंतर्निहित घोषणा है कि आईएसओ 8859-1 नया मानक एन्कोडिंग बन गया है, जो दुनिया में सभी को समान वर्ण सेट का उपयोग करने के लिए मजबूर करता है।[original research?] इसके बजाय, मशीनों के बीच 8-बिट-क्लीन लिंक का लाभ उठाने का अनुशंसित तरीका ईएसएमटीपी का उपयोग करना है (RFC 1869) 8 बिटमाइम एक्सटेंशन[12][13] संदेश निकायों और SMTP SMTPUTF8 के लिए[14] संदेश शीर्षलेखों के लिए एक्सटेंशन. इसके बावजूद, कुछ मेल स्थानांतरण एजेंट , विशेष रूप से एग्जिम और yamail , उन सर्वरों पर मेल रिले करते हैं जो आवश्यक 7-बिट एमआईएमई (आमतौर पर उद्धृत-मुद्रण योग्य, क्यू-पी रूपांतरण) में रूपांतरण किए बिना 8BITMIME का विज्ञापन नहीं करते हैं। RFC 6152. यह जस्ट-सेंड-8 रवैया वास्तव में व्यवहार में समस्या पैदा नहीं करता है, क्योंकि वस्तुतः सभी आधुनिक ईमेल सर्वर 8-बिट साफ़ हैं।[15]


यह भी देखें

संदर्भ

  1. ↑ RFC 780: Appendix A, RFC 788: 4.5.2., RFC 821: Appendix B, RFC 1056: 4.
  2. ↑ John Beck. "Email Explained". 2011.
  3. ↑ Jonathan B. Postel (November 1981). "4.5.3. SIZES". SIMPLE MAIL TRANSFER PROTOCOL. doi:10.17487/RFC0788. RFC 788. The maximum total length of a text line including the <CRLF> is 1000 characters (but not counting the leading dot duplicated for transparency).
  4. ↑ G. Vaudreuil (February 1993). "2. The Problem". Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME. doi:10.17487/RFC1428. RFC 1428. SMTP as defined in RFC 821 limits the sending of Internet Mail to US-ASCII characters.
  5. ↑ Dan Sugalski. "E-mail with Attachments". "The Perl Journal". Summer 1999. "When mail was standardized way back in 1982 with RFC822, ... The only limits placed on the body were the character set (7-bit ASCII) and the maximum line length (1000 characters)."
  6. ↑ N. Freed; N. Borenstein (November 1996). "Abstract". Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. doi:10.17487/RFC2045. RFC 2045. Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages
  7. ↑ N. Freed; N. Borenstein (November 1996). "Abstract". Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. doi:10.17487/RFC2045. RFC 2045. Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages
  8. ↑ C. Feather (October 2006). Network News Transfer Protocol (NNTP). doi:10.17487/RFC3977. RFC 3977.
  9. ↑ C. Lindsey; D. Kohn (November 2009). K. Murchison (ed.). Netnews Article Format. doi:10.17487/RFC5536. RFC 5536.
  10. ↑ K. Moore (November 1996). MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text. doi:10.17487/RFC2047. RFC 2047.
  11. ↑ N. Freed; K. Moore (November 1997). MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations. doi:10.17487/RFC2231. RFC 2231.
  12. ↑ Theodore Ts'o; Keith Moore; Mark Crispin (12 September 1994). "8-bit transmission in NNTP". IETF-SMTP mail list. Archived from the original on 20 March 2012. Retrieved 3 April 2010.
  13. ↑ "comp.mail.mime FAQ, part 3 'What's ESMTP, and how does it affect MIME?'". Usenet FAQs. 8 August 1997. Archived from the original on 18 January 2012. Retrieved 3 April 2010.
  14. ↑ J. Yao; W. Mao (February 2012). SMTP Extension for Internationalized Email. doi:10.17487/RFC8531. RFC 8531.
  15. ↑ "The 8BITMIME extension".
Retrieved from ‘https://www.vigyanwiki.in/index.php?title=8-बिट_क्लीन&oldid=238723’