'\ N' और 'r \ n' के बीच अंतर


99

हाँ हाँ, मुझे पता है कि '\n'UNIX में एक नई पंक्ति लिखता है जबकि विंडोज के लिए दो वर्ण क्रम है '\r\n':। यह सब सिद्धांत में बहुत अच्छा है, लेकिन मेरा सवाल यह है कि क्यों ? विंडोज में गाड़ी का रिटर्न कैरेक्टर अतिरिक्त क्यों है? यदि UNIX यह कर सकता है तो \nऐसा करने के लिए Windows दो वर्ण क्यों लेता है?

मैं डेविड बेज़ले की पायथन पुस्तक पढ़ रहा हूं और वह कहता है:

उदाहरण के लिए, विंडोज पर, चरित्र '\ n' लिखना वास्तव में दो-वर्ण अनुक्रम '\ r \ n' को आउटपुट करता है (और फ़ाइल को वापस पढ़ते समय, '\ r \ n' को वापस एक एकल '\ n' में अनुवादित किया जाता है। चरित्र)।

अतिरिक्त प्रयास क्यों?

मुझे इमानदार रहना है। मैं लंबे समय से अंतर को जानता हूं लेकिन कभी भी डब्ल्यूएचवाई से पूछने की जहमत नहीं उठाई। मुझे उम्मीद है कि आज जवाब दिया गया है।

आपके समय के लिए धन्यवाद।


5
यह भी ध्यान दिया जाना चाहिए कि विंडोज केवल एक ही है जो उपयोग नहीं करता है \r\n। इसका उपयोग ज्यादातर पाठ-आधारित इंटरनेट प्रोटोकॉल (जैसे SMTP, HTTP, आदि) द्वारा बड़े पैमाने पर विंडोज (यानी इतिहास) के लिए भी किया जाता है।
डीन हार्डिंग

3
इसके अलावा, जब जावा में और प्रारूप स्ट्रिंग्स (जैसे System.out.printf()या String.format()) का उपयोग करके सुनिश्चित करें कि आप %nओएस संगतता उद्देश्यों के लिए अपने CRLF के रूप में उपयोग करते हैं। \nपदावनत किया गया है।
गैरी रोवे

मैंने \n\rकई बार देखा है। (मुझे लगता है कि यह नेटवेयर से कुछ था।)
ग्रेविटी


1
बहुत कम विंडोज प्रोग्राम हैं जिन्हें वास्तव में CRLF की आवश्यकता होती है। CRLF डिफ़ॉल्ट हो सकता है, लेकिन लगभग सब कुछ स्वतः लोड हो जाएगा और LF का उपयोग ठीक होगा। मेरे पास विंडोज पर मेरे सभी पाठ संपादक हैं, जिन्होंने सभी नई फ़ाइलों के लिए एलएफ का उपयोग करने के लिए कॉन्फ़िगर किया है, और यह वास्तव में कोई समस्या नहीं है।
केविन

जवाबों:


124

अनिच्छुक अनुकूलता।

MS-DOS (आक्रामक रूप से, यहां तक ​​कि) और MS-DOS ने CR-LF कन्वेंशन का उपयोग किया है क्योंकि MS-DOS CP / M-80 (दुर्घटना से कुछ हद तक) के साथ संगत था, जो CR-LF कॉन्फिडेंस का उपयोग करता था क्योंकि यह था कि आपने एक प्रिंटर कैसे चलाया (क्योंकि प्रिंटर मूल रूप से कंप्यूटर नियंत्रित टाइपराइटर थे)।

प्रिंटर में एक लाइन को एक नई लाइन में स्थानांतरित करने के लिए एक अलग कमांड होता है, और गाड़ी (जहां कागज माउंट किया गया था) को वापस बाएं मार्जिन पर लौटने के लिए एक अलग कमांड है।

इसीलिए। और, हाँ, यह एक झुंझलाहट है, लेकिन यह उस पैकेज डील का हिस्सा है जिसने MS-DOS को CP / M पर जीतने की अनुमति दी, और Windows 95 को अन्य सभी GUI को DOS के शीर्ष पर जीतने के लिए, और Windows XP को लेने की अनुमति दी विंडोज 98 से।

(नोट: आधुनिक लेजर प्रिंटर में अभी भी ये कमांड हैं क्योंकि वे भी पहले के प्रिंटर के साथ पीछे की ओर संगत हैं - एचपी विशेष रूप से यह अच्छी तरह से करते हैं)

: टाइपराइटरों के साथ अपरिचित उन लोगों के लिए, यहाँ एक वीडियो दिखा कैसे टाइपिंग किया गया था http://www.youtube.com/watch?v=LJvGiU_UyEQ । ध्यान दें कि कागज को पहले ऊपर ले जाया जाता है, और फिर गाड़ी को वापस कर दिया जाता है, भले ही यह एक साधारण आंदोलन में हो। डिंग ने टाइपिस्ट को सूचित किया कि अंत निकट था, और इसके लिए तैयारी की।


3
यूनिक्स के साथ यूनिक्स केवल उन पुराने दिनों के प्रिंटर के साथ कैसे काम करता था? मुझे लगता है कि वे यूनिक्स कंसोल टाइपराइटर प्रकार प्रिंटर से जुड़ा था?
सेंथिल कुमारन

3
@ सेंथिल, यूनिक्स में न्यूलाइन चरित्र को अंतिम ड्राइवर द्वारा परिवर्तित किया गया है। यह सिर्फ एक अलग डिजाइन का निर्णय है।

2
@ सेंथिल, सटीक होने के लिए, यूनिक्स प्रिंटर और टर्मिनलों को ऑपरेटिंग सिस्टम में अमूर्त किया जाता है, और उनका विवरण निर्धारित करता है कि डिवाइस के लिए कौन से बाइट अनुक्रम उत्पन्न होते हैं। CP / M के पास ऐसा कोई अमूर्त काम नहीं था, जिससे यह सब चल रहा हो। - यह सबसे अधिक संभावना है क्योंकि सभी कार्यक्रमों के लिए इसकी आवश्यकता नहीं थी, इसलिए इसे निवासी के ऑपरेटिंग सिस्टम में रखने से कार्यक्रमों की कीमती स्मृति नहीं छीनी जाएगी। याद रखें कि CP / M को 16 किलोबाइट सिस्टम के लिए डिज़ाइन किया गया था ।

1
"तो यकीनन दुनिया की सबसे उन्नत परिवहन प्रणाली की एक प्रमुख डिजाइन विशेषता मूल रूप से घोड़े के गधे की चौड़ाई द्वारा निर्धारित की गई थी।" और इसलिए यह सॉफ्टवेयर के साथ भी है। astrodigital.org/space/stshorse.html
रयान

1
@ किरण, शहरी कथा। पर खारिज snopes.com/history/american/gauge.htm

20

जहां तक ​​मुझे पता है यह टाइपराइटर के दिनों में वापस आ गया है।

\r गाड़ी वापसी है, जो वह जगह है जहाँ आप पृष्ठ पर बाईं ओर टाइप कर रहे हैं (या यदि आपकी संस्कृति सही है)

\n नई लाइन है, जो आपके पेपर को एक लाइन में ले जाती है।

टाइपराइटर पर इनमें से केवल एक को करने से आप गलत जगह पर पाठ की एक नई पंक्ति लिखना शुरू कर देंगे।

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


7
तो विंडोज अभी भी इससे क्यों चिपकता है?
सुखबीर

8
अनिच्छुक अनुकूलता। कल्पना करें कि यदि वे अब बदल जाते हैं तो कितने पाठ दस्तावेज़ टूट जाएंगे
मैट एलेन

4
कड़ाई से बोलते हुए, "ऑडबॉल" यहां यूनिक्स का प्रयोग किया गया है 'केवल नईलाइन का उपयोग करें', शुरू में किया गया है (मेरा मानना ​​है) संग्रहीत पात्रों की संख्या को कम रखने के लिए (सीआर एलएफ में अनुवाद टर्मिनल ड्राइवर में किया जाता है, यह 'ओनली' झंडा है आउटपुट के लिए इसे नियंत्रित करता है।
वैटीन

3
विंडोज में DOS नाम का एक पूर्ववर्ती था, जिसमें समान लाइन-एंडिंग थी। विंडोज ने संगतता रखी। डॉस के पूर्ववर्ती स्वयं सीपी यानी एम थे। यह भी CRLF का इस्तेमाल किया। डॉस ने अनुकूलता बनाए रखी। CP / M का विकास DECs TOPS से प्रभावित था। और आप अनुमान लगा सकते हैं, कि उन्होंने किस लाइन का इस्तेमाल किया। :-) संगतता अधिक बताती है।
Mnementh

5
ठीक है, लेकिन नोटपैड अभी भी "एंड" लाइन एंडिंग को क्यों नहीं पहचानता है?
dan04

8

मुझे नहीं पता कि यह सामान्य ज्ञान है, लेकिन यह ध्यान दिया जाना चाहिए कि सीआर को अभी भी आधुनिक टर्मिनल एमुलेटर द्वारा समझा जाता है:

$ printf "hey world\rsup\n"
sup world

यह प्रगति संकेतक के लिए उपयोगी है, उदाहरण के लिए

for i in {1..100}
do
    printf "\rLoading... %d%%" $i
    sleep 0.01
done
echo

1
पुराने आईबीएम लाइन प्रिंटर (उदाहरण के लिए, 1403), कन्वेंशन को लाइन बफर के पहले चरित्र को एक कैरक्टर कंट्रोल कैरेक्टर के रूप में माना जाता था। खाली का मतलब एक पंक्ति को आगे बढ़ाना और प्रिंट करना था। इसके अलावा रिक्ति को छोड़ना था और इसका इस्तेमाल किया गया था, उदाहरण के लिए, रेखांकित करने के लिए। शून्य का मतलब डबल-स्पेस से है और माइनस से ट्रिपल-स्पेस है। एक '1' अगले पृष्ठ के शीर्ष पर स्थित है, और उपयोगकर्ता-परिभाषित ऊर्ध्वाधर पदों के लिए उन्नत अन्य अंक (पूर्व-मुद्रित रूपों में भरने के लिए उपयोग किया जाता है)।
जॉर्ज

7

ऐतिहासिक रूप से, लाइन फीड का मतलब था कि प्लैटन - वह रोलर, जिस पर आप टाइप करते हैं - एक लाइन को घुमाया जाता है, जिससे टेक्स्ट अगली लाइन पर दिखाई देता है ... लेकिन अगले कॉलम में।

कैरिज रिटर्न का मतलब था "वह बिट लौटें जिसके साथ आप लाइन की शुरुआत में टाइप करते हैं"।

Windows CR + LF का उपयोग करता है क्योंकि MS-DOS ने किया था, क्योंकि CP / M ने किया था, क्योंकि यह धारावाहिक लाइनों के लिए समझ में आता था।

यूनिक्स ने अपने \ n सम्मेलन की नकल की क्योंकि मल्टीिक्स ने किया।

मुझे संदेह है कि यदि आप बहुत पीछे खोदते हैं, तो आपको कार्यान्वयनकर्ताओं के बीच एक राजनीतिक असहमति मिलेगी!

(आपने अतिरिक्त मज़ेदार बिट को छोड़ दिया, जहां मैक कन्वेंशन (या इस्तेमाल किया जाता है) सिर्फ सीआर को अलग लाइनों का उपयोग करने के लिए। और अब यूनिकोड का अपना लाइन विभाजक भी है, U + 2028!)


वाह! मैक के बारे में नहीं पता था ...
माइकल के

मुझे यकीन नहीं है कि आपको राजनीतिक असहमति मिलेगी। यह भी संभव है कि आप लोगों को स्वतंत्र रूप से इसी तरह के काम करते हुए पाएंगे।
डेविड थॉर्नले

1
जब विभिन्न मानक निकाय शामिल होते हैं? मुझे आश्चर्य होगा कि मुझे राजनीतिक कारण नहीं मिले!
फ्रैंक शीयर

6

न्यूलाइन चरित्र का इतिहास (विकिपीडिया):

ASCII को आईएसओ और ASA द्वारा एक साथ विकसित किया गया था, जो ANSI का पूर्ववर्ती संगठन था। 1963-1968 की अवधि के दौरान, आईएसओ ड्राफ्ट मानकों ने एक नई रेखा के रूप में अकेले सीआर + एलएफ या एलएफ के उपयोग का समर्थन किया, जबकि एएसए ड्राफ्ट ने केवल सीआर + एलएफ का समर्थन किया।

अनुक्रम CR + LF कई प्रारंभिक कंप्यूटर प्रणालियों पर आम उपयोग में था, जो कि टेलेटाइप मशीनों को अपनाया था, आमतौर पर एक ASR33, एक कंसोल डिवाइस के रूप में, क्योंकि इस क्रम को उन प्रिंटरों को एक नई लाइन की शुरुआत में स्थान देना आवश्यक था। इन प्रणालियों पर, पाठ को अक्सर इन प्रिंटरों के साथ संगत करने के लिए नियमित रूप से रचा गया था, क्योंकि डिवाइस ड्राइवरों की अवधारणा ऐसे हार्डवेयर विवरणों को आवेदन से छिपाती थी, जो अभी तक अच्छी तरह से विकसित नहीं हुई थी; अनुप्रयोगों को सीधे टेलेटाइप मशीन से बात करनी थी और इसके सम्मेलनों का पालन करना था।

दो कार्यों के अलगाव ने इस तथ्य को छिपा दिया कि प्रिंट सिर एक पंक्ति के समय में अगली पंक्ति की शुरुआत तक दूर से वापस नहीं आ सकता है। यही कारण है कि अनुक्रम हमेशा सीआर के साथ पहले भेजा गया था। वास्तव में, प्रिंट वर्णों को बाएं हाशिये पर जाने के लिए अतिरिक्त वर्ण (अतिरिक्त सीआर या NUL, जिन्हें अनदेखा किया जाता है) को भेजने के लिए अक्सर आवश्यक होता था।

टेलेटाइप्स को उच्च बॉड दरों के साथ कंप्यूटर टर्मिनलों द्वारा प्रतिस्थापित किए जाने के बाद भी, कई ऑपरेटिंग सिस्टम ने सस्ते टर्मिनलों के साथ संगतता के लिए इन फिल वर्णों के स्वत: भेजने का समर्थन किया, जिन्हें प्रदर्शन को स्क्रॉल करने के लिए कई वर्ण समय की आवश्यकता होती है।

MS-DOS (1981) ने CP / M के CR + LF को अपनाया; सीआर / एलएफ के सीपी / एम के उपयोग ने धारावाहिक लाइनों के माध्यम से कंप्यूटर टर्मिनलों का उपयोग करने के लिए समझ में आया। यह सम्मेलन माइक्रोसॉफ्ट के बाद के विंडोज ऑपरेटिंग सिस्टम द्वारा विरासत में मिला था।

मल्टिक्स ऑपरेटिंग सिस्टम ने 1964 में विकास शुरू किया और एलएफ को अकेले ही इसकी नई रेखा के रूप में इस्तेमाल किया। यूनिक्स ने मल्टीिक्स प्रथा का पालन किया, और बाद में सिस्टम ने यूनिक्स का अनुसरण किया।


पुराने आईबीएम 2741 प्रिंटर-कीबोर्ड टर्मिनल पर, प्रिंटर घटक एक आईबीएम सिलेक्टिक बाउंसिंग टाइप बॉल टाइपराइटर था। अपरकेस में बदलने से गेंद को घुमाने में, अतिरिक्त समय लगता है। EBCDIC वर्ण कोड में, अपरकेस वर्णों की स्थिति 1 में 1-बिट थी। तो, एक EBCDIC रिक्त (0x40) अपरकेस था! यदि आप एक लंबी अवधि (उदाहरण के लिए, एक थीसिस) को प्रिंट कर रहे थे, तो आप शब्दाडंबर शब्दों के बीच NULs, या लोअरकेस रिक्त स्थान (वे एक अलग वर्ण, IL का उपयोग करते थे, यदि मेमोरी काम करती है, तो देरी का परिचय देने के लिए, आउटपुट को गति प्रदान कर सकते हैं।) , जब लौट रहे हैं या वर्जित हैं)।
जार्ज

5

"यूनिक्स क्यों कर सकते हैं \nऔर विंडोज नहीं " पूछ रहे लोगों के साथ यह क्या है ? यह इतना अजीब सवाल है।

  1. OS का इससे कोई लेना देना नहीं है। यह अधिक बात है कि ऐप, लाइब्रेरी, प्रोटोकॉल और फ़ाइल प्रारूप चीजों से कैसे निपटते हैं। ओएस जहां पाठ-आधारित कॉन्फ़िगरेशन या कमांड लाइन कमांड को पढ़ता / लिखता है, इसके अलावा, यह ओएस को गलती करने के लिए कोई मतलब नहीं है।
  2. अधिकांश विंडोज़ ऐप्स दोनों और बस ठीक पढ़ सकते हैं । वे आउटपुट भी देते हैं ताकि हर कोई खुश हो। एक प्रोग्राम या तो "नहीं" करता है या - यह एक, दूसरे या दोनों को स्वीकार करता है, और एक, दूसरे या दोनों को आउटपुट करता है।\n\r\n\r\n\n\r\n
  3. एक प्रोग्रामर के रूप में यह वास्तव में आपको लगभग कभी परेशान नहीं करना चाहिए । व्यावहारिक रूप से हर भाषा / मंच में सही एंड-लाइन लिखने और सबसे अधिक मजबूती से पढ़ने की सुविधा है। समस्या से निपटने के लिए मेरे पास एकमात्र समय था जब मैंने एक HTTP सर्वर लिखा था - और यह इसलिए था क्योंकि एक निश्चित ब्राउज़र (संकेत: IE के बाद अगला सबसे लोकप्रिय ब्राउज़र) सही के\n बजाय कर रहा था । \r\n
  4. एक बहुत अधिक प्रासंगिक सवाल यह है कि इतने सारे आधुनिक यूनिक्स ऐप आउटपुट केवल \nपूरी तरह से जानते हैं कि कुछ प्रोटोकॉल और प्रोग्राम हैं जो इसे पसंद नहीं करते हैं?

3
एक और प्रासंगिक सवाल: चूंकि कई प्रोटोकॉल मुख्य रूप से यूनिक्स सिस्टम पर विकसित किए गए थे, इसलिए उन्होंने '\ n' का उपयोग क्यों नहीं किया?
डेविड थॉर्नले

@DavidThornley क्योंकि \ r \ n के लिए क्रॉस-प्लेटफॉर्म (पुराने macs के लिए \ r, विंडोज़ के लिए \ r \ n और * nix के लिए \ n) काम करने की अधिक संभावना है।
बेसिक

4

इसका कारण यह है कि कन्वेंशन उनके विभिन्न सिस्टमों (यूनिक्स प्रकार सिस्टम पर \ n, विंडोज आदि पर \ r \ n) को पकड़ते हैं, क्योंकि एक बार जब आप एक कन्वेंशन ले लेते हैं, तो आप इसे लोगों की फाइलों का एक गुच्छा तोड़े बिना नहीं बदल सकते। और यह आमतौर पर पर आधारित है।

टेलेटाइप के विभिन्न मॉडलों का उपयोग करके यूनिक्स-प्रकार की प्रणालियों को विकसित किया गया (बहुत शुरुआती दिन), और किसी बिंदु पर किसी ने तय किया कि उपकरण को गाड़ी वापस करना चाहिए जब उसने एक लाइन फीड किया।

विंडोज डॉस से आया है, इसलिए विंडोज के लिए वास्तव में सवाल यह है: डॉस ने इस cr / lf अनुक्रम का उपयोग क्यों किया? मैं अनुमान लगा रहा हूं कि इसका CP / M से कुछ लेना-देना है, जहाँ DOS की कुछ जड़ें हैं। फिर से, टेलेटाइप के विशिष्ट मॉडल ने एक भूमिका निभाई हो सकती है।


हां दिलचस्प।
सुखबीर

1
क्यों नहीं विंडोज हैंडल लाइनों को समाप्त कर सकता है \n, लेकिन अभी के लिए उपयोग करना जारी रखें \r\n? अगर उन्होंने विंडोज एक्सपी से शुरू किया, तो वे अब \nइसके बजाय फाइलों को सहेजना शुरू कर सकते हैं \r\n
असंतुष्टगीत

1
विंडोज का इससे कोई लेना-देना नहीं है। यह ऐप्स का निर्णय है, और अधिकांश ऐप '\ n' और 'r \ n' दोनों को पढ़ेंगे, और '\ r \ n' लिखेंगे - जिससे सभी लोग खुश होंगे।
री मियासका

2

यहाँ सबसे अच्छा स्रोत से एक जवाब है - Microsoft। लाइन टर्मिनेटर CR + LF क्यों है?

यह प्रोटोकॉल टेलेटिप्राइवर्स के दिनों की है। CR का अर्थ "कैरिज रिटर्न" है - CR कंट्रोल कैरेक्टर ने पेपर को आगे बढ़ाए बिना कॉलम 0 पर प्रिंट हेड ("कैरिज") को लौटा दिया। LF का मतलब "लाइनफीड" है - LF कंट्रोल कैरेक्टर ने प्रिंट हेड को मूव किए बिना पेपर वन लाइन को एडवांस किया। इसलिए यदि आप प्रिंट सिर को कॉलम शून्य (अगली पंक्ति को प्रिंट करने के लिए तैयार) पर लौटना चाहते हैं और पेपर को आगे बढ़ाते हैं (इसलिए यह ताजा पेपर पर प्रिंट करता है), तो आपको सीआर और एलएफ दोनों की आवश्यकता है।

यदि आप विभिन्न इंटरनेट प्रोटोकॉल दस्तावेजों जैसे कि RFC 0821 (SMTP), RFC 1939 (POP), RFC 2060 (IMAP), या RFC 2616 (HTTP) पर जाते हैं, तो आप देखेंगे कि वे सभी CR + LOS को निर्दिष्ट करते हैं। लाइन समाप्ति का क्रम। तो असली सवाल यह नहीं है कि "CP / M, MS-DOS, और Win32 लाइन टर्मिनेटर के रूप में CR + LF का उपयोग क्यों करते हैं?" लेकिन इसके बजाय "अन्य लोगों ने इन मानकों के दस्तावेजों से अलग क्यों चुना और कुछ अन्य लाइन टर्मिनेटर का उपयोग किया?"

यूनिक्स ने लाइन समाप्ति अनुक्रम के रूप में सादे एलएफ को अपनाया। यदि आप स्टेंट विकल्पों को देखते हैं, तो आप देखेंगे कि ऑनलर विकल्प निर्दिष्ट करता है कि क्या LF को CR + LF में बदला जाना चाहिए। यदि आपको यह सेटिंग गलत लगती है, तो आपको स्टेपस्टेप टेक्स्ट मिल जाएगा, जहां

each
    line
        begins

जहां पिछली लाइन बंद थी। इसलिए, यहां तक ​​कि यूनिक्स, जब कच्चे मोड में छोड़ दिया जाता है, तो लाइनों को समाप्त करने के लिए सीआर + एलएफ की आवश्यकता होती है। LF से पहले निहित CR एक यूनिक्स आविष्कार है, शायद एक अर्थव्यवस्था के रूप में, क्योंकि यह प्रति पंक्ति एक बाइट बचाता है।

C भाषा के यूनिक्स पूर्वजों ने इस सम्मेलन को C भाषा मानक में शामिल किया, जिसमें लाइनों को समाप्त करने के लिए केवल "\ n" (जो LF को एन्कोड करता है) की आवश्यकता होती है, कच्चे फाइल डेटा को तार्किक लाइनों में बदलने के लिए रनटाइम लाइब्रेरीज़ पर बोझ डालते हैं।

सी भाषा ने "जेनेरिक लाइन टर्मिनेटर" की अवधारणा को व्यक्त करने के लिए "न्यूलाइन" शब्द भी पेश किया। मुझे बताया गया है कि ASCII समिति ने चरित्र 0x0A का नाम बदलकर 1996 के आसपास "न्यूलाइन" कर दिया है, इसलिए भ्रम का स्तर और भी अधिक बढ़ गया है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.