8-बिट क्लीन: Difference between revisions
(→इतिहास) |
No edit summary |
||
| Line 1: | Line 1: | ||
{{Short description|Computer system that correctly handles 8-bit character encodings}} | {{Short description|Computer system that correctly handles 8-bit character encodings}}''8-बिट क्लीन'' [[ कंप्यूटर प्रणाली ]], कम्युनिकेशन चैनल और अन्य उपकरणों और सॉफ़्टवेयर की एक विशेषता है, जो [[8-बिट कंप्यूटिंग|8-बिट]] कैरेक्टर एन्कोडिंग को सही पद्धति से नियंत्रण करते हैं। ऐसी एन्कोडिंग में [[ISO 8859]] श्रृंखला और [[यूनिकोड]] की [[UTF-8]] एन्कोडिंग सम्मिलित है। | ||
''8-बिट क्लीन'' [[ कंप्यूटर प्रणाली ]], | |||
== इतिहास == | == इतिहास == | ||
1990 के दशक | 1990 के दशक के प्रारम्भ तक, कई प्रोग्राम और डेटा ट्रांसमिशन चैनल करैक्टर ओरिएंटेड थे और कुछ कैरेक्टर, जैसे, ईटीएक्स, को कंट्रोल कैरेक्टर के रूप में मानते थे। अन्य ने 0 और 127 के बीच मानों के साथ सात-बिट कैरेक्टर की एक स्रोत मान ली, उदाहरण के लिए, ASCII मानक डेटा ट्रांसमिशन लागत को बचाने के लिए 8-बिट प्रतिनिधित्व से बचते हुए, प्रति कैरेक्टर केवल 7 बिट्स का उपयोग करता है। 8-बिट बाइट्स का उपयोग करने वाले कंप्यूटर और डेटा लिंक पर इसने प्रत्येक बाइट के शीर्ष बिट को [[समता द्वियक|पैरीटी]] [[ध्वज बिट|फ़्लैग बिट]] या मेटा डेटा नियंत्रण बिट के रूप में उपयोग के लिए स्वतंत्र छोड़ दिया। 7-बिट सिस्टम और डेटा लिंक अधिक काम्प्लेक्स कैरेक्टर कोड को सीधे संभालने में असमर्थ हैं जो बड़े कैरेक्टर वाले दूसरे-[[अंग्रेजी भाषा]]-भाषी देशों में सामान्य हैं। | ||
[[ऑक्टेट (कंप्यूटिंग)|ऑक्टेट]] की [[बाइनरी फ़ाइल|बाइनरी फ़ाइलें]] 7-बिट डेटा चैनलों के माध्यम से सीधे ट्रांसमिटेड नहीं की जा सकतीं। इसके आसपास काम करने के लिए, [[बाइनरी-टू-टेक्स्ट एन्कोडिंग]] तैयार की गई है जो केवल 7-बिट ASCII कैरेक्टर का उपयोग करती है। इनमें से कुछ एन्कोडिंग [[ uuencoding| यूयूएन्कोडिंग]] , [[एएससीआईआई]]85( Ascii85), [[एसआरईसी (फ़ाइल प्रारूप)]], [[बिनहेक्स]], [[केर्मिट (प्रोटोकॉल)|केर्मिट]] और एमआईएमई का बेस 64 हैं। [[ EBCDIC]] -आधारित सिस्टम यूयूएनकोडेड डेटा में उपयोग किए गए सभी कैरेक्टर को | [[ऑक्टेट (कंप्यूटिंग)|ऑक्टेट]] की [[बाइनरी फ़ाइल|बाइनरी फ़ाइलें]] 7-बिट डेटा चैनलों के माध्यम से सीधे ट्रांसमिटेड नहीं की जा सकतीं। इसके आसपास काम करने के लिए, [[बाइनरी-टू-टेक्स्ट एन्कोडिंग]] तैयार की गई है जो केवल 7-बिट ASCII कैरेक्टर का उपयोग करती है। इनमें से कुछ एन्कोडिंग [[ uuencoding| यूयूएन्कोडिंग]] , [[एएससीआईआई]]85( Ascii85), [[एसआरईसी (फ़ाइल प्रारूप)|एसआरईसी (SREC)]], [[बिनहेक्स|बिनहेक्स (BinHex)]], [[केर्मिट (प्रोटोकॉल)|केर्मिट]] (kermit) और एमआईएमई (MIME) का बेस 64 हैं। [[ EBCDIC]] -आधारित सिस्टम यूयूएनकोडेड डेटा में उपयोग किए गए सभी कैरेक्टर को नियंत्रण नहीं सकते हैं। यद्यपि, बेस 64 एन्कोडिंग में यह समस्या नहीं है। | ||
==एसएमटीपी और एनएनटीपी 8-बिट | ==एसएमटीपी (SMTP) और एनएनटीपी (NNTP) 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 कैरेक्टर सेट के उपयोग की आवश्यकता होती है, "उच्च-क्रम बिट को शून्य पर क्लीन करने के साथ 8-बिट बाइट के रूप में प्रेषित" और इनमें से कुछ<ref>{{IETF RFC|780}}: Appendix A, {{IETF RFC|788}}: 4.5.2., {{IETF RFC|821}}: Appendix B, {{IETF RFC|1056}}: 4.</ref> स्पष्ट रूप से सभी डेटा को 7-बिट करैक्टर तक सीमित करते हैं। | ||
ईमेल नेटवर्क के पहले कुछ दशकों (1971 से 1990 के प्रारंभ तक) में, अधिकांश ईमेल | ईमेल नेटवर्क के पहले कुछ दशकों (1971 से 1990 के प्रारंभ तक) में, अधिकांश ईमेल मैसेज 7-बिट यूएस-एएससीआईआई करैक्टर सेट में [[सादे पाठ|प्लेन टेक्स्ट]] थे।<ref> John Beck. [http://www.sendmail.com/sm/open_source/docs/email_explained/ "Email Explained"]. 2011.</ref> | ||
SMTP की <nowiki>RFC 788</nowiki> परिभाषा, अपने पूर्ववर्ती {{IETF RFC|780}} की तरह, इंटरनेट मेल को 7-बिट US-ASCII कैरेक्टर की पंक्तियों (1000 कैरेक्टर या उससे कम) तक सीमित करता है।<ref>{{cite RFC | SMTP की <nowiki>RFC 788</nowiki> परिभाषा, अपने पूर्ववर्ती {{IETF RFC|780}} की तरह, इंटरनेट मेल को 7-बिट US-ASCII कैरेक्टर की पंक्तियों (1000 कैरेक्टर या उससे कम) तक सीमित करता है।<ref>{{cite RFC | ||
| Line 40: | Line 37: | ||
}}</ref> | }}</ref> | ||
बाद में उन | बाद में उन मैसेजों का समर्थन करने के लिए ईमेल मैसेजों के प्रारूप को फिर से परिभाषित किया गया जो पूरी तरह से यूएस-एएससीआईआई टेक्स्ट नहीं हैं (यूएस-एएससीआईआई के अलावा अन्य करैक्टर सेट में टेक्स्ट मैसेज, और नॉन-टेक्स्ट मैसेज, जैसे ऑडियो और छवियां)।<ref name="RFC2045">{{cite RFC | ||
| rfc = 2045 | | rfc = 2045 | ||
| title = Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies | | title = Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies | ||
| Line 74: | Line 71: | ||
| author1 = N. Freed | | author1 = N. Freed | ||
| author2 = K. Moore | | author2 = K. Moore | ||
}}</ref> | }}</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> और संदेश हेडर के लिए SMTP SMTPUTF8<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> एक्सटेंशन का उपयोग करना है इसके स्थान पर, कुछ [[ मेल स्थानांतरण एजेंट | मेल ट्रांसफर एजेंट]] , विशेष रूप से [[एग्जिम]] और [[ yamail | क्यूमेल]], उन सर्वरों पर मेल रिले करते हैं जो {{IETF RFC|6152}}. द्वारा आवश्यक 7-बिट MIME (सामान्यतः उद्धृत-मुद्रण योग्य, "Q-P रूपांतरण") में रूपांतरण किए बिना 8BITMIME का विज्ञापन नहीं करते हैं। यह जस्ट-सेंड-8 दृष्टिकोण वास्तव में व्यवहार में समस्या उत्पन्न नहीं करता है, क्योंकि वस्तुतः सभी आधुनिक ईमेल सर्वर 8-बिट क्लीन हैं।<ref>{{cite IETF| | ||
| rfc = 8531 | | rfc = 8531 | ||
| title = SMTP Extension for Internationalized Email | | title = SMTP Extension for Internationalized Email | ||
| Line 83: | Line 80: | ||
| author2 = W. Mao | | author2 = W. Mao | ||
}} | }} | ||
</ref> | </ref> | ||
== यह भी देखें == | == यह भी देखें == | ||
* [[32-बिट साफ़]] | * [[32-बिट साफ़|32-बिट क्लीन]] | ||
* {{slink|MIME|Content-Transfer-Encoding}} | * {{slink|MIME|Content-Transfer-Encoding}} | ||
* {{slink|Telnet|8-bit data}} | * {{slink|Telnet|8-bit data}} | ||
Revision as of 12:13, 2 August 2023
8-बिट क्लीन कंप्यूटर प्रणाली , कम्युनिकेशन चैनल और अन्य उपकरणों और सॉफ़्टवेयर की एक विशेषता है, जो 8-बिट कैरेक्टर एन्कोडिंग को सही पद्धति से नियंत्रण करते हैं। ऐसी एन्कोडिंग में ISO 8859 श्रृंखला और यूनिकोड की UTF-8 एन्कोडिंग सम्मिलित है।
इतिहास
1990 के दशक के प्रारम्भ तक, कई प्रोग्राम और डेटा ट्रांसमिशन चैनल करैक्टर ओरिएंटेड थे और कुछ कैरेक्टर, जैसे, ईटीएक्स, को कंट्रोल कैरेक्टर के रूप में मानते थे। अन्य ने 0 और 127 के बीच मानों के साथ सात-बिट कैरेक्टर की एक स्रोत मान ली, उदाहरण के लिए, ASCII मानक डेटा ट्रांसमिशन लागत को बचाने के लिए 8-बिट प्रतिनिधित्व से बचते हुए, प्रति कैरेक्टर केवल 7 बिट्स का उपयोग करता है। 8-बिट बाइट्स का उपयोग करने वाले कंप्यूटर और डेटा लिंक पर इसने प्रत्येक बाइट के शीर्ष बिट को पैरीटी फ़्लैग बिट या मेटा डेटा नियंत्रण बिट के रूप में उपयोग के लिए स्वतंत्र छोड़ दिया। 7-बिट सिस्टम और डेटा लिंक अधिक काम्प्लेक्स कैरेक्टर कोड को सीधे संभालने में असमर्थ हैं जो बड़े कैरेक्टर वाले दूसरे-अंग्रेजी भाषा-भाषी देशों में सामान्य हैं।
ऑक्टेट की बाइनरी फ़ाइलें 7-बिट डेटा चैनलों के माध्यम से सीधे ट्रांसमिटेड नहीं की जा सकतीं। इसके आसपास काम करने के लिए, बाइनरी-टू-टेक्स्ट एन्कोडिंग तैयार की गई है जो केवल 7-बिट ASCII कैरेक्टर का उपयोग करती है। इनमें से कुछ एन्कोडिंग यूयूएन्कोडिंग , एएससीआईआई85( Ascii85), एसआरईसी (SREC), बिनहेक्स (BinHex), केर्मिट (kermit) और एमआईएमई (MIME) का बेस 64 हैं। EBCDIC -आधारित सिस्टम यूयूएनकोडेड डेटा में उपयोग किए गए सभी कैरेक्टर को नियंत्रण नहीं सकते हैं। यद्यपि, बेस 64 एन्कोडिंग में यह समस्या नहीं है।
एसएमटीपी (SMTP) और एनएनटीपी (NNTP) 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] और संदेश हेडर के लिए SMTP SMTPUTF8[13] एक्सटेंशन का उपयोग करना है इसके स्थान पर, कुछ मेल ट्रांसफर एजेंट , विशेष रूप से एग्जिम और क्यूमेल, उन सर्वरों पर मेल रिले करते हैं जो RFC 6152. द्वारा आवश्यक 7-बिट MIME (सामान्यतः उद्धृत-मुद्रण योग्य, "Q-P रूपांतरण") में रूपांतरण किए बिना 8BITMIME का विज्ञापन नहीं करते हैं। यह जस्ट-सेंड-8 दृष्टिकोण वास्तव में व्यवहार में समस्या उत्पन्न नहीं करता है, क्योंकि वस्तुतः सभी आधुनिक ईमेल सर्वर 8-बिट क्लीन हैं।[14]
यह भी देखें
संदर्भ
- ↑ RFC 780: Appendix A, RFC 788: 4.5.2., RFC 821: Appendix B, RFC 1056: 4.
- ↑ John Beck. "Email Explained". 2011.
- ↑ 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).
- ↑ 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.
- ↑ 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)."
- ↑ 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
- ↑ 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
- ↑ C. Feather (October 2006). Network News Transfer Protocol (NNTP). doi:10.17487/RFC3977. RFC 3977.
- ↑ C. Lindsey; D. Kohn (November 2009). K. Murchison (ed.). Netnews Article Format. doi:10.17487/RFC5536. RFC 5536.
- ↑ K. Moore (November 1996). MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text. doi:10.17487/RFC2047. RFC 2047.
- ↑ N. Freed; K. Moore (November 1997). MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations. doi:10.17487/RFC2231. RFC 2231.
- ↑ 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.
- ↑ "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.
- ↑ J. Yao; W. Mao (February 2012). SMTP Extension for Internationalized Email. doi:10.17487/RFC8531. RFC 8531.
