CRLF अब उपयोग में नहीं है और इसे समाप्त कर दिया जाना चाहिए

 (fossil-scm.org)
9 पॉइंट द्वारा GN⁺ 2024-10-14 | 8 टिप्पणियां | WhatsApp पर शेयर करें

कैरिज रिटर्न और लाइन फ़ीड की परिभाषा

  • कैरिज रिटर्न (CR): कर्सर को उसी पंक्ति के बाएँ मार्जिन पर ले जाता है
  • लाइन फ़ीड (LF): कर्सर को एक पंक्ति नीचे ले जाता है और पिछली पंक्तियों को ऊपर स्क्रॉल करता है
  • न्यूलाइन (NL): कर्सर को एक पंक्ति नीचे ले जाकर बाएँ मार्जिन पर ले जाता है

अवलोकन

  • CR और NL उपयोगी control characters हैं। NL सबसे सामान्य काम करता है, यानी टेक्स्ट की नई पंक्ति को बाएँ मार्जिन से शुरू करता है
  • LF व्यवहारिक रूप से बेकार है। कोई भी पंक्ति के बीच से अगली पंक्ति में जाकर उसी कॉलम में लिखना जारी नहीं रखना चाहता
  • LF की उत्पत्ति लगभग 70 साल पहले के यांत्रिक टेलीटाइपराइटर युग में हुई थी

ऐतिहासिक पृष्ठभूमि

  • टेलीटाइपराइटर लगभग 5 सेकंड में 5 अक्षर प्रिंट करते थे
  • CRLF की परंपरा 1950 के दशक के टेलीटाइपराइटर की यांत्रिक सीमाओं से निकली
  • Multix और Unix के दौर में यह समझ फैल गई कि CRLF को NL की तरह इस्तेमाल करना अक्षम है

आधुनिक स्थिति

  • आज CR को U+000d के रूप में, और LF तथा NL को U+000a के रूप में दर्शाया जाता है
  • अधिकांश आधुनिक मशीनें U+000a का उपयोग केवल NL के रूप में करती हैं
  • कुछ protocols अभी भी CRLF की मांग करते हैं, लेकिन अधिकांश software एकल NL को स्वीकार करता है

कार्रवाई का आह्वान

  • U+000a code point का नाम "लाइन फ़ीड" के बजाय "न्यूलाइन" रखा जाए
  • अनावश्यक CR भेजना बंद किया जाए
  • जो protocols CRLF की मांग करते हैं, उन्हें केवल NL भेजा जाए
  • ऐसे software को ठीक किया जाए जो CR के बिना NL मिलने पर error देता है

सारांश और लेखक

  • CRLF का अंत बहुत पहले हो जाना चाहिए था। इस पुराने अवशेष को हटाने के लिए हमें मिलकर काम करना चाहिए
  • लेखक: D. Richard Hipp, SQLite के संस्थापक

# GN⁺ का संक्षेप

  • यह लेख CRLF की ऐतिहासिक पृष्ठभूमि और आधुनिक अक्षमताओं को समझाता है, और इसे समाप्त करने की अपील करता है
  • CRLF यांत्रिक सीमाओं से निकली एक परंपरा है, जो आज अनावश्यक जटिलता पैदा करती है
  • यह विषय खास तौर पर programmers और software developers के लिए उपयोगी हो सकता है, और कुशल data transmission के लिए महत्वपूर्ण है
  • समान कार्यक्षमता वाले अन्य protocols या systems का उपयोग करते समय भी CRLF की आवश्यकता पर फिर से विचार करने की ज़रूरत है

संबंधित पढ़ाई

8 टिप्पणियां

 
cosine20 2024-10-14

मैं कभी-कभी line feed का इस्तेमाल करता हूँ....
 
doolayer 2024-10-14

काफी उग्र है, हद है lol
 
savvykang 2024-10-14

14 अक्टूबर के संशोधन के अनुसार, कहा जा रहा है कि बदलाव के प्रस्ताव को वापस ले लिया गया है.

यह केवल एक सिस्टम बदलने की बात नहीं थी, बल्कि प्रोटोकॉल और उससे प्रभावित सभी सिस्टमों को चरणबद्ध तरीके से बदलना पड़ता, इसलिए मुझे लगता है कि लेखक ने पर्याप्त सावधानी नहीं बरती थी.
 
constexprif 2024-10-14

क्या उन्हें लगा कि इसे हटाने में होने वाली लागत से, इसे हटाने से मिलने वाला फ़ायदा ज़्यादा है?
 
alstjr7375 2024-10-14

CR+LF का एक लंबा इतिहास है...

ओह.. तो इसकी यही वजह है..
 
bakyeono 2024-10-14

यह कोई गलत तरीके से परिभाषित specification भी नहीं है, बल्कि उस समय के hardware environment को दर्शाता है...
लगता है कि backward compatibility को भूलकर सिर्फ़ इसी पल के बारे में सोचा जा रहा है।
क्या hardware specification बदलने पर हमें हर बार protocol को पूरी तरह बदल देना चाहिए?
 
halfenif 2024-10-14

इसे हटाने के पक्ष में भी नहीं हूँ और विरोध में भी नहीं।

पता नहीं क्यों, लेकिन Millennium bug याद आ गया?
 
GN⁺ 2024-10-14
Hacker News राय
  • मौजूदा protocols को NL में अपडेट करना संभावित bugs पैदा कर सकता है, और HTTP/1.1 को पहले ही HTTP/2 ने replace कर दिया है
    • तर्क यह है कि नए protocols में CRLF की आवश्यकता न रखना तर्कसंगत है, लेकिन मौजूदा protocols को अपडेट करने की ज़रूरत नहीं है
  • CRLF का पालन न करना जानबूझकर bug introduce करने जैसा है
    • SQLite के HTTP server को \r\n की जगह \n इस्तेमाल करने के लिए अपडेट किया गया, लेकिन इससे Zig के HTTP client के साथ compatibility टूट गई
  • यह राय कि CRLF ऐसी चीज़ होनी चाहिए जिसकी चिंता हमारी अगली पीढ़ियों को न करनी पड़े
    • तर्क दिया गया कि .gitattribute file का इस्तेमाल सिखाना चाहिए, और Byte Order Mark से नफ़रत करना भी सिखाना चाहिए
  • Unix द्वारा non-standard line ending चुनना एक गलती थी, और इससे दशकों तक compatibility issues पैदा हुए
    • CRLF terminal API के दो अलग-अलग हिस्से हैं, और कई programs CR और LF के सही व्यवहार पर निर्भर करते हैं
  • CRLF standard के सबसे कम महत्वपूर्ण तत्वों में से एक है
    • standard को तोड़ना एक नया प्रयोग है, और व्यक्तिगत रूप से यह एक अपरिचित रवैया लगता है
  • SMTP स्पष्ट करता है कि message termination sequence CR LF . CR LF है, और ऐसी implementations भी मौजूद हैं जो LF . LF को पहचानती हैं
    • संभव है कि SMTP के मूल नियम अब उतने महत्वपूर्ण न हों
  • CRLF कई devices के लिए जोखिम पैदा कर सकता है, और exceptions को कम किया जाना चाहिए
  • mixed line endings के समय होने वाली समस्याओं का कोई उल्लेख नहीं है
    • NL नाम का कोई character मौजूद नहीं है, और हर keyboard की "ENTER" key CR भेजती है
    • मौजूदा तरीका अच्छी तरह काम कर रहा है