न्यू लाइन

For other uses, see New Line (disambiguation).

"Endl" redirects here. For the botanist, see Stephan Endlicher.

हैलो और वर्ल्ड शब्दों के बीच नई लाइन डाली गई है

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

इतिहास

1800 के दशक के मध्य में, तैलिप्रिंटर्स और टेलेटाइप मशीनों के आगमन से बहुत पहले, मोर्स कोड ऑपरेटरों या टेलिग्राफ़-आपरेटरों ने औपचारिक लिखित टेक्स्ट संदेशों में सफेद स्पेस टेक्स्ट फ़ॉर्मेटिंग को एनकोड करने के लिए मोर्स कोड के लिए Prosigns का आविष्कार किया और उनका उपयोग किया। विशेष रूप से अंतर्राष्ट्रीय मोर्स कोड प्रोसाइनBT(मेमोनिक bरिया text) सामान्य इंटर-कैरेक्टर स्पेसिंग के बिना भेजे गए शाब्दिक टेक्स्ट मोर्स कोड B और T वर्णों के संयोजन द्वारा प्रतिनिधित्व किया जाता है, मोर्स कोड में औपचारिक टेक्स्ट संदेश में नई लाइन या नए सेक्शन को एनकोड और इंगित करने के लिए उपयोग किया जाता है।

बाद में, आधुनिक टेलीप्रिंटर के युग में, सफेद स्थान पाठ स्वरूपण में सहायता के लिए मानकीकृत वर्ण सेट नियंत्रण कोड विकसित किए गए थे। ASCII को अंतर्राष्ट्रीय मानकीकरण संगठन (ISO) और अमेरिकी मानक संघ (ASA) द्वारा साथ विकसित किया गया था, बाद वाला अमेरिकी राष्ट्रीय मानक संस्थान (ANSI) का पूर्ववर्ती संगठन था। 1963 से 1968 की अवधि के दौरान, आईएसओ प्रारूप मानकों ने #प्रतिनिधित्व|CR+LFया #प्रतिनिधित्व|LFअकेले नई लाइन के रूप में, जबकि एएसए ड्राफ्ट केवल समर्थित थे CR+LF.

क्रम CR+LF आमतौर पर कई शुरुआती कंप्यूटर सिस्टम पर इस्तेमाल किया गया था, जिन्होंने टेलेटाइप कॉर्पोरेशन मशीनों को अपनाया था - आमतौर पर टेलेटाइप मॉडल 33 एएसआर - कंसोल डिवाइस के रूप में, क्योंकि इस क्रम को उन प्रिंटरों को नई लाइन की शुरुआत में रखने की आवश्यकता थी। न्यूलाइन को दो कार्यों में अलग करना इस तथ्य को छुपाता है कि प्रिंट हेड अगले वर्ण को प्रिंट करने के लिए दूर दाईं ओर से अगली पंक्ति की शुरुआत तक वापस नहीं आ सकता है। के बाद मुद्रित कोई भी वर्ण CR अक्सर पृष्ठ के मध्य में धुंध के रूप में प्रिंट होता था जबकि प्रिंट हेड अभी भी गाड़ी को पहली स्थिति में वापस ले जा रहा था। समाधान नई पंक्ति को दो वर्ण बनाना था: CR कैरिज को कॉलम में ले जाने के लिए, और LF कागज को ऊपर ले जाने के लिए। वास्तव में, अक्सर अतिरिक्त वर्ण-बाहरी सीआर या एनयूएल भेजने के लिए आवश्यक होता था-जो अनदेखा कर दिए जाते हैं लेकिन प्रिंट हेड को बाएं मार्जिन पर जाने का समय देते हैं। कई शुरुआती वीडियो डिस्प्ले को भी डिस्प्ले को स्क्रॉल करने के लिए कई वर्ण बार की आवश्यकता होती है।

ऐसी प्रणालियों पर, अनुप्रयोगों को टेलेटाइप मशीन से सीधे बात करनी पड़ती है और इसके सम्मेलनों का पालन करना पड़ता है क्योंकि उपकरण चालकों द्वारा ऐसे हार्डवेयर विवरणों को अनुप्रयोग से छिपाने की अवधारणा अभी तक अच्छी तरह से विकसित नहीं हुई थी। इसलिए, टेलेटाइप मशीनों की जरूरतों को पूरा करने के लिए पाठ नियमित रूप से तैयार किया गया था। डिजिटल उपकरण निगम के अधिकांश मिनीकंप्यूटर सिस्टम ने इस कन्वेंशन का इस्तेमाल किया। CP/M ने इसका उपयोग उन्हीं टर्मिनलों पर प्रिंट करने के लिए भी किया, जिनका उपयोग मिनीकंप्यूटर करते थे। वहां से MS-DOS (1981) ने CP/M's को अपनाया CR+LF संगत होने के लिए, और यह सम्मेलन Microsoft के बाद के Microsoft Windows ऑपरेटिंग सिस्टम द्वारा विरासत में मिला था।

मॉलटिक्स ऑपरेटिंग सिस्टम ने 1964 में विकास शुरू किया और इसका इस्तेमाल किया LF अकेले इसकी नई लाइन के रूप में। मल्टिक्स ने इस वर्ण का अनुवाद करने के लिए डिवाइस ड्राइवर का इस्तेमाल किया, जो प्रिंटर की जरूरत के किसी भी क्रम में (अतिरिक्त पैडिंग वर्णों सहित), और एकल बाइट प्रोग्रामिंग के लिए अधिक सुविधाजनक था। क्या अधिक स्पष्ट प्रतीत होता है पसंद-CR- उपयोग नहीं किया गया था, जैसा CR जोर (टाइपोग्राफी), बल देना और स्ट्रिकथ्रौघ प्रभाव बनाने के लिए पंक्ति को दूसरे के साथ ओवरप्रिंट करने का उपयोगी कार्य प्रदान किया। शायद अधिक महत्वपूर्ण, का उपयोग LF अकेले लाइन टर्मिनेटर के रूप में पहले से ही अंतिम आईएसओ/आईईसी 646 मानक के मसौदे में शामिल किया गया था। यूनिक्स ने मल्टिक्स अभ्यास का पालन किया, और बाद में यूनिक्स जैसी प्रणालियों ने यूनिक्स का अनुसरण किया। इसने विंडोज और यूनिक्स जैसे ऑपरेटिंग सिस्टम के बीच संघर्ष पैदा किया, जिससे ऑपरेटिंग सिस्टम पर बनी फाइलों को दूसरे ऑपरेटिंग सिस्टम द्वारा उचित रूप से स्वरूपित या व्याख्या नहीं किया जा सकता था (उदाहरण के लिए माइक्रोसॉफ्ट नोटपैड जैसे विंडोज टेक्स्ट एडिटर में लिखी गई UNIX शेल स्क्रिप्ट)).

प्रतिनिधित्व

कैरिज रिटर्न (सीआर) और लाइन फीड (एलएफ) की अवधारणाएं निकट से जुड़ी हुई हैं और इन्हें अलग-अलग या साथ माना जा सकता है। टाइपराइटर और प्रिंटर (कंप्यूटिंग) के भौतिक मीडिया में, पृष्ठ (पेपर) पर नई पंक्ति बनाने के लिए गति के दो कार्टेशियन समन्वय प्रणाली, नीचे और आर-पार, की आवश्यकता होती है। हालांकि मशीन (टाइपराइटर या प्रिंटर) के डिजाइन को उन्हें अलग से विचार करना चाहिए, सॉफ्टवेयर का अमूर्त तर्क उन्हें साथ घटना के रूप में जोड़ सकता है। यही कारण है कि वर्ण एन्कोडिंग में नई पंक्ति को परिभाषित किया जा सकता है CR और LF में संयुक्त (आमतौर पर कहा जाता है CR+LF या CRLF).

कुछ वर्ण एन्कोडिंग अलग न्यूलाइन वर्ण कोड प्रदान करते हैं। ईबीसीडीआईसी, उदाहरण के लिए, प्रदान करता है NL वर्ण कोड के अलावा CR और LF कोड। यूनिकोड, ASCII प्रदान करने के अलावा CR और LF नियंत्रण चरित्र, अगली पंक्ति भी प्रदान करता है (NEL) नियंत्रण कोड, साथ ही रेखा विभाजक और अनुच्छेद विभाजक मार्करों के लिए नियंत्रण कोड।

Software applications and operating system representation of a newline with one or two control characters

Operating system	Character encoding	Abbreviation	hex value	dec value	Escape sequence
Unix and Unix-like systems (Linux, macOS, FreeBSD, AIX, Xenix, etc.), Multics, BeOS, Amiga, RISC OS, and others	ASCII	LF	0A	10	\n
Microsoft Windows, DOS (MS-DOS, PC DOS, etc.), Atari TOS, DEC TOPS-10, RT-11, CP/M, MP/M, OS/2, Symbian OS, Palm OS, Amstrad CPC, and most other early non-Unix and non-IBM operating systems		CR LF	0D 0A	13 10	\r\n
Commodore 8-bit machines (C64, C128), Acorn BBC, ZX Spectrum, TRS-80, Apple II series, Oberon, the classic Mac OS, MIT Lisp Machine and OS-9		CR	0D	13	\r
QNX pre-POSIX implementation (version < 4)		RS	1E	30	\036
Acorn BBC and RISC OS spooled text output		LF CR	0A 0D	10 13	\n\r
Atari 8-bit machines	ATASCII		9B	155
IBM mainframe systems, including z/OS (OS/390) and IBM i (OS/400)	EBCDIC	NL	15	21	\025
ZX80 and ZX81 (Home computers from Sinclair Research Ltd)	used a specific non-ASCII character set	NEWLINE	76	118

• EBCDIC सिस्टम- मुख्य रूप से IBM मेनफ्रेम सिस्टम, जिसमें z/OS (OS/390) और IBM i (OS/400) शामिल हैं- का उपयोग करें NL (नई पंक्ति, 0x15) लाइन फीड और कैरिज रिटर्न के कार्यों के संयोजन वाले चरित्र के रूप में। समतुल्य यूनिकोड वर्ण (0x85) कहा जाता है NEL (अगली पंक्ति)। ईबीसीडीआईसी में नियंत्रण वर्ण भी कहा जाता है CR और LF, लेकिन का संख्यात्मक मान LF (0x25) ASCII द्वारा उपयोग किए गए से भिन्न है (0x0A). इसके अतिरिक्त, कुछ EBCDIC वैरिएंट भी उपयोग करते हैं NL लेकिन चरित्र को अलग संख्यात्मक कोड असाइन करें। हालाँकि, वे ऑपरेटिंग सिस्टम रिकॉर्ड-उन्मुख फ़ाइल सिस्टम सिस्टम | रिकॉर्ड-आधारित फ़ाइल सिस्टम का उपयोग करते हैं, जो पाठ फ़ाइलों को प्रति पंक्ति रिकॉर्ड के रूप में संग्रहीत करता है। अधिकांश फ़ाइल स्वरूपों में, कोई लाइन टर्मिनेटर वास्तव में संग्रहीत नहीं होते हैं।
• सीडीसी 6000 श्रृंखला के लिए ऑपरेटिंग सिस्टम ने 60-बिट शब्द के अंत में दो या दो से अधिक शून्य-मूल्य वाले छह-बिट वर्णों के रूप में नई पंक्ति को परिभाषित किया। कुछ विन्यासों ने शून्य-मूल्यवान वर्ण को बृहदान्त्र (विराम चिह्न) वर्ण के रूप में भी परिभाषित किया, जिसके परिणामस्वरूप स्थिति के आधार पर कई कॉलनों को नई पंक्ति के रूप में व्याख्या किया जा सकता है।
• RSX-11 और OpenVMS भी रिकॉर्ड-आधारित फ़ाइल सिस्टम का उपयोग करते हैं, जो प्रति पंक्ति रिकॉर्ड के रूप में पाठ फ़ाइलों को संग्रहीत करता है। अधिकांश फ़ाइल स्वरूपों में, कोई लाइन टर्मिनेटर वास्तव में संग्रहीत नहीं होते हैं, लेकिन रिकॉर्ड प्रबंधन सेवा सुविधा पारदर्शी रूप से प्रत्येक पंक्ति में टर्मिनेटर जोड़ सकती है, जब इसे किसी एप्लिकेशन द्वारा पुनर्प्राप्त किया जाता है। रिकॉर्ड में स्वयं समान लाइन टर्मिनेटर वर्ण हो सकते हैं, जिन्हें या तो विशेषता या उपद्रव माना जा सकता है जो कि आवेदन पर निर्भर करता है। RMS न केवल रिकॉर्ड संग्रहीत करता है, बल्कि फ़ाइल के लिए अलग-अलग बिट्स में रिकॉर्ड विभाजक के बारे में मेटाडेटा भी संग्रहीत करता है, जिससे मामले और भी जटिल हो जाते हैं (चूंकि फ़ाइलों में निश्चित लंबाई के रिकॉर्ड हो सकते हैं, ऐसे रिकॉर्ड जो गिनती या रिकॉर्ड द्वारा समाप्त होते हैं जो विशिष्ट वर्ण द्वारा समाप्त होते हैं ). बिट्स सामान्य नहीं हैं, इसलिए जब वे इसे निर्दिष्ट कर सकते हैं CRLF या LF या और भी CR लाइन टर्मिनेटर है, वे किसी अन्य कोड को स्थानापन्न नहीं कर सकते।
• फिक्स्ड लाइन लेंथ का इस्तेमाल कुछ शुरुआती मेनफ़्रेम कंप्यूटर ऑपरेटिंग सिस्टम द्वारा किया जाता था। ऐसी प्रणाली में, उदाहरण के लिए, प्रत्येक 72 या 80 वर्णों में निहित अंत-पंक्ति मान ली गई थी। कोई न्यूलाइन वर्ण संग्रहीत नहीं किया गया था। यदि कोई फ़ाइल बाहरी दुनिया से आयात की गई थी, तो लाइन की लंबाई से छोटी लाइनों को रिक्त स्थान के साथ पैडेड करना पड़ता था, जबकि लाइन की लंबाई से अधिक लंबी लाइनों को छोटा करना पड़ता था। इसने छिद्रित कार्डों के उपयोग की नकल की, जिस पर प्रत्येक पंक्ति को अलग कार्ड पर संग्रहीत किया गया था, आमतौर पर प्रत्येक कार्ड पर 80 कॉलम के साथ, अक्सर कॉलम 73-80 में अनुक्रम संख्या के साथ। इनमें से कई प्रणालियों ने अगले रिकॉर्ड की शुरुआत में एएसए कैरिज नियंत्रण वर्ण जोड़े; यह इंगित कर सकता है कि क्या अगला रिकॉर्ड पिछले रिकॉर्ड, या नई लाइन द्वारा शुरू की गई लाइन की निरंतरता थी, या पिछली पंक्ति को ओवरप्रिंट करना चाहिए (के समान) CR). अक्सर यह सामान्य मुद्रण वर्ण होता था जैसे # इस प्रकार पंक्ति में पहले वर्ण के रूप में उपयोग नहीं किया जा सकता था। कुछ शुरुआती लाइन प्रिंटरों ने इन वर्णों की सीधे उन्हें भेजे गए रिकॉर्ड में व्याख्या की।

यूनिकोड

"Paragraph separator" redirects here. For the symbol also known as a "paragraph sign", see Pilcrow.

यूनिकोड मानक कई वर्णों को परिभाषित करता है जो अनुरूप अनुप्रयोगों को लाइन टर्मिनेटर के रूप में पहचानना चाहिए:

 LF:    रेखा भरण, U+000A

 VT:    वर्टिकल टैब, U+000B

 FF:    फ़ीड बनाएं, U+000C

 CR:    कैरिज रिटर्न, U+000D

 CR+LF: CR (U+000D) के बाद LF (U+000A)

 NEL:   अगली पंक्ति, U+0085

 LS:    रेखा विभाजक, U+2028

 PS:    अनुच्छेद विभाजक, U+2029

उदाहरण के लिए, सभी लाइन टर्मिनेटरों को वर्ण में परिवर्तित करने जैसे दृष्टिकोण की तुलना में यह अत्यधिक जटिल लग सकता है LF. हालांकि, यूनिकोड को किसी टेक्स्ट फ़ाइल को किसी भी मौजूदा एन्कोडिंग से यूनिकोड में और वापस कनवर्ट करते समय सभी सूचनाओं को संरक्षित करने के लिए डिज़ाइन किया गया था। इसलिए, यूनिकोड में मौजूदा एनकोडिंग में शामिल वर्ण होने चाहिए।

उदाहरण के लिए: NL ईबीसीडीआईसी का हिस्सा है, जो कोड का उपयोग करता है 0x15; यह आमतौर पर यूनिकोड में मैप किया जाता है NEL, 0x85, जो C1 कंट्रोल सेट में कंट्रोल कैरेक्टर है। जैसे, यह ईसीएमए 48 द्वारा परिभाषित किया गया है, और ISO/IEC 2022 (जो ECMA 35 के समतुल्य है) के अनुरूप एनकोडिंग द्वारा मान्यता प्राप्त है। C1 नियंत्रण सेट ISO-8859-1 के साथ भी संगत है। यूनिकोड मानक में अपनाया गया दृष्टिकोण सभी संभावित प्रकार के लाइन टर्मिनेटरों को पहचानने के लिए अनुप्रयोगों को सक्षम करते हुए राउंड-ट्रिप परिवर्तन को सूचना-संरक्षण करने की अनुमति देता है।

से अधिक न्यूलाइन कोड को पहचानना और उपयोग करना 0x7F (NEL, LS और PS) अक्सर नहीं किया जाता है। वे यूटीएफ-8 -8 में कई बाइट हैं, और कोड के लिए NEL दीर्घवृत्त के रूप में इस्तेमाल किया गया है (…) Windows-1252 में वर्ण। उदाहरण के लिए:

• ईसीएमएस्क्रिप्ट स्वीकार करता है LS और PS लाइन-ब्रेक के रूप में, लेकिन मानता है U+0085 (NEL) लाइन-ब्रेक के बजाय व्हाइटस्पेस चरित्र
• Windows 10 इनमें से किसी का भी इलाज नहीं करता है NEL, LS, या PS अपने डिफ़ॉल्ट टेक्स्ट एडिटर, माइक्रोसॉफ्ट नोटपैड में लाइन-ब्रेक के रूप में।
• Gedit, GNOME डेस्कटॉप वातावरण का डिफ़ॉल्ट पाठ संपादक, ट्रीट करता है LS और PS न्यूलाइन के रूप में लेकिन के लिए नहीं है NEL.
• जेएसओएन अनुमति देता है LS और PS तार के भीतर वर्ण, जबकि ECMAScript से पहले ES2019 उन्हें न्यूलाइन्स के रूप में माना, और इसलिए अवैध सिंटैक्स।
• वाईएएमएल JSON के साथ संगत होने के लिए अब उन्हें संस्करण 1.2 के रूप में विशेष के रूप में नहीं पहचानता है।

ध्यान दें कि यूनिकोड विशेष वर्ण U+2424 (SYMBOL FOR NEWLINE, ␤), U+23CE (RETURN SYMBOL, ⏎), U+240D (SYMBOL FOR CARRIAGE RETURN, ␍) और U+240A (SYMBOL FOR LINE FEED, ␊) दस्तावेज़ के पाठक के लिए उपयोगकर्ता-दिखाई देने वाले चरित्र को प्रस्तुत करने के लिए ग्लिफ़ हैं, और इस प्रकार खुद को नई पंक्ति के रूप में मान्यता नहीं दी जाती है।

प्रोग्रामिंग भाषाओं में

"\n" redirects here. For the similar number notation, see \nnn (disambiguation).

में porting प्रोग्राम के निर्माण को सुविधाजनक बनाने के लिए, प्रोग्रामिंग लैंग्वेज विभिन्न वातावरणों में उपयोग किए जाने वाले विभिन्न प्रकार के न्यूलाइन अनुक्रमों से निपटने के लिए कुछ सार प्रदान करती हैं।

सी (प्रोग्रामिंग भाषा) बचने का क्रम प्रदान करती है '\n' (न्यूलाइन) और '\r' (कैरिज रिटर्न)। हालाँकि, इन्हें ASCII के समकक्ष होने की आवश्यकता नहीं है LF और CR नियंत्रण वर्ण। सी मानक केवल दो चीजों की गारंटी देता है:

1. इनमें से प्रत्येक एस्केप सीक्वेंस अद्वितीय कार्यान्वयन-परिभाषित संख्या में मैप करता है जिसे एकल में संग्रहीत किया जा सकता है char कीमत।
2. टेक्स्ट मोड में फाइल, डिवाइस नोड, या सॉकेट / फीफो में लिखते समय, '\n' सिस्टम द्वारा उपयोग किए जाने वाले मूल न्यूलाइन अनुक्रम में पारदर्शी रूप से अनुवादित है, जो वर्ण से अधिक लंबा हो सकता है। टेक्स्ट मोड में पढ़ते समय, नेटिव न्यूलाइन सीक्वेंस को वापस ट्रांसलेट किया जाता है '\n'. बाइनरी मोड में, कोई अनुवाद नहीं किया जाता है, और आंतरिक प्रतिनिधित्व इसके द्वारा निर्मित होता है '\n' सीधे आउटपुट है।

यूनिक्स प्लेटफॉर्म पर, जहां सी की उत्पत्ति हुई, मूल न्यूलाइन अनुक्रम ASCII है LF (0x0A), इसलिए '\n' बस उस मूल्य के रूप में परिभाषित किया गया था। आंतरिक और बाहरी प्रतिनिधित्व समान होने के साथ, टेक्स्ट मोड में किया गया अनुवाद एनओपी (कोड) | नो-ऑप है, और यूनिक्स में टेक्स्ट मोड या बाइनरी मोड की कोई धारणा नहीं है। इसने कई प्रोग्रामरों को यूनिक्स सिस्टम पर अपने सॉफ़्टवेयर को विकसित करने के लिए पूरी तरह से भेद को अनदेखा करने का कारण बना दिया है, जिसके परिणामस्वरूप कोड विभिन्न प्लेटफार्मों के लिए पोर्टेबल नहीं है।

सी पुस्तकालय समारोह fgets() बाइनरी मोड में सबसे अच्छा बचा है क्योंकि यूनिक्स न्यूलाइन कन्वेंशन के साथ नहीं लिखी गई कोई भी फाइल गलत होगी। साथ ही, टेक्स्ट मोड में, कोई भी फाइल जो सिस्टम के नेटिव न्यूलाइन सीक्वेंस (जैसे कि यूनिक्स सिस्टम पर बनाई गई फाइल, फिर विंडोज सिस्टम में कॉपी की गई) के साथ नहीं लिखी गई है, उसे भी गलत तरीके से पढ़ा जाएगा।

और आम समस्या का उपयोग है '\n' ASCII के उपयोग को अनिवार्य करने वाले इंटरनेट प्रोटोकॉल का उपयोग करते हुए संचार करते समय CR+LF समाप्त होने वाली पंक्तियों के लिए। लिखना '\n' टेक्स्ट मोड स्ट्रीम के लिए विंडोज सिस्टम पर सही ढंग से काम करता है, लेकिन केवल उत्पादन करता है LF यूनिक्स पर, और अधिक विदेशी प्रणालियों पर कुछ पूरी तरह से अलग। का उपयोग करते हुए "\r\n" बाइनरी मोड में थोड़ा बेहतर है।

कई भाषाएँ, जैसे C++, पर्ल, और हास्केल (प्रोग्रामिंग भाषा) की समान व्याख्या प्रदान करते हैं '\n' C. C++ में इनपुट/आउटपुट (C++)|वैकल्पिक I/O मॉडल है जहां मैनिपुलेटर std::endl नई लाइन को आउटपुट करने के लिए इस्तेमाल किया जा सकता है (और स्ट्रीम बफर को फ्लश करता है)।

जावा (प्रोग्रामिंग भाषा), पीएचपी, और पायथन (प्रोग्रामिंग भाषा) प्रदान करना '\r\n' अनुक्रम (एएससीआईआई के लिए CR+LF). सी के विपरीत, इन्हें मूल्यों का प्रतिनिधित्व करने की गारंटी है U+000D और U+000A, क्रमश।

जावा I/O पुस्तकालय इन्हें इनपुट या आउटपुट पर प्लेटफ़ॉर्म-निर्भर न्यूलाइन अनुक्रमों में पारदर्शी रूप से अनुवादित नहीं करते हैं। इसके बजाय, वे पूर्ण पंक्ति लिखने के लिए कार्य प्रदान करते हैं जो स्वचालित रूप से देशी न्यूलाइन अनुक्रम जोड़ते हैं, और उन पंक्तियों को पढ़ने के लिए कार्य करते हैं जो इनमें से किसी को भी स्वीकार करते हैं CR, LF, या CR+LF लाइन टर्मिनेटर के रूप में (देखें BufferedReader.readLine()). System.lineSeparator() }} विधि का उपयोग अंतर्निहित रेखा विभाजक को पुनः प्राप्त करने के लिए किया जा सकता है।

उदाहरण: <वाक्यविन्यास प्रकाश लैंग = जावा>

  स्ट्रिंग ईओएल = System.lineSeparator ();
  स्ट्रिंग लाइन रंग = रंग: लाल + ईओएल;

</वाक्यविन्यास हाइलाइट>

पढ़ने के लिए फ़ाइल खोलते समय, मॉड्यूल आयात करते समय और फ़ाइल निष्पादित करते समय पायथन यूनिवर्सल न्यूलाइन सपोर्ट की अनुमति देता है। कुछ भाषाओं ने प्रोग्राम निष्पादन के दौरान न्यूलाइन की सुविधा के लिए विशेष चर (कंप्यूटर विज्ञान), स्थिरांक (कंप्यूटर प्रोग्रामिंग), और सबरूटीन्स बनाए हैं। PHP और पर्ल जैसी कुछ भाषाओं में, सभी एस्केप सीक्वेंस के लिए एस्केप प्रतिस्थापन करने के लिए डबल उद्धरण की आवश्यकता होती है, जिसमें शामिल हैं '\n' और '\r'. PHP में, पोर्टेबिलिटी की समस्याओं से बचने के लिए, PHP_EOL स्थिरांक का उपयोग करके न्यूलाइन अनुक्रम जारी किए जाने चाहिए। सी शार्प (प्रोग्रामिंग भाषा) में उदाहरण|सी#: <वाक्यविन्यास प्रकाश लैंग = सी #>

  स्ट्रिंग ईओएल = पर्यावरण। न्यूलाइन;
  स्ट्रिंग लाइन रंग = रंग: लाल + ईओएल;
  
  स्ट्रिंग ईओएल2 = \n;
  स्ट्रिंग लाइन रंग 2 = रंग: नीला + ईओएल 2;

</वाक्यविन्यास हाइलाइट>

विभिन्न न्यूलाइन प्रारूपों के साथ मुद्दे

जीएडिट के साथ बनाई गई और हेक्स संपादक के साथ देखी गई पाठ फ़ाइल। पाठ वस्तुओं के अलावा, हेक्साडेसिमल मान 0A के साथ केवल EOL मार्कर हैं।

विभिन्न न्यूलाइन सम्मेलनों के कारण विभिन्न प्रकार की प्रणालियों के बीच स्थानांतरित की गई पाठ फ़ाइलें गलत तरीके से प्रदर्शित होती हैं।

यूनिक्स-जैसे या क्लासिक मैक ओएस पर आम प्रोग्राम के साथ बनाई गई फाइलों में टेक्स्ट, एमएस-डॉस और माइक्रोसॉफ्ट विंडोज के लिए सामान्य प्रोग्रामों पर लंबी लाइन के रूप में दिखाई देता है क्योंकि ये भी प्रदर्शित नहीं करते हैं line feed या carriage return लाइन ब्रेक के रूप में।

इसके विपरीत, यूनिक्स जैसी प्रणाली पर विंडोज कंप्यूटर से उत्पन्न होने वाली फाइल को देखते समय, अतिरिक्त CR दूसरी पंक्ति विराम के रूप में प्रदर्शित किया जा सकता है, जैसे ^M, या के रूप में <cr> प्रत्येक पंक्ति के अंत में।

इसके अलावा, पाठ संपादकों के अलावा अन्य प्रोग्राम फ़ाइल को स्वीकार नहीं कर सकते हैं, उदा। कुछ कॉन्फ़िगरेशन फ़ाइल, मान्य फ़ाइल के रूप में विदेशी न्यूलाइन कन्वेंशन का उपयोग करके एन्कोडेड।

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

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

अधिकांश टेक्स्टुअल इंटरनेट प्रोटोकॉल (कंप्यूटिंग) (HTTP, सरल डाक स्थानांतरण प्रोटोकॉल, फाइल ट्रांसफर प्रोटोकॉल, इंटरनेट रिले चैट और कई अन्य सहित) ASCII के उपयोग को अनिवार्य करते हैं। CR+LF ('\r\n', 0x0D 0x0A) प्रोटोकॉल स्तर पर, लेकिन अनुशंसा करते हैं कि सहिष्णु अनुप्रयोग अकेले को पहचानें LF ('\n', 0x0A) भी। निर्धारित मानक के बावजूद, कई एप्लिकेशन गलती से C (प्रोग्रामिंग लैंग्वेज) न्यूलाइन एस्केप सीक्वेंस का उपयोग करते हैं '\n' (LF) कैरिज रिटर्न एस्केप और न्यूलाइन एस्केप सीक्वेंस के सही संयोजन के बजाय '\r\n' (CR+LF) (उपरोक्त प्रोग्रामिंग भाषाओं में अनुभाग देखें)। सुझाए गए सहिष्णु व्याख्या के बजाय मानकों की सख्त व्याख्या का पालन करने वाले सिस्टम के साथ संवाद करने की कोशिश करते समय गलत एस्केप सीक्वेंस का यह आकस्मिक उपयोग समस्याओं की ओर ले जाता है। ऐसी ही असहिष्णु प्रणाली है qmail मेल ट्रांसफर एजेंट जो बिना संदेश भेजने वाले सिस्टम से संदेशों को स्वीकार करने से सक्रिय रूप से मना कर देता है LF आवश्यक के बजाय CR+LF. मानक इंटरनेट संदेश प्रारूप ईमेल स्टेट्स के लिए: CR और LF केवल CRLF के रूप में साथ होने चाहिए; उन्हें शरीर में स्वतंत्र रूप से प्रकट नहीं होना चाहिए।

एएससीआईआई मोड में स्थानांतरण होने पर फाइल ट्रांसफर प्रोटोकॉल ऑपरेटिंग सिस्टम के बीच विभिन्न न्यूलाइन प्रस्तुतियों के साथ स्थानांतरित की जा रही फाइलों में नई लाइनों को स्वचालित रूप से परिवर्तित कर सकता है। हालाँकि, इस मोड में बाइनरी फ़ाइलों को स्थानांतरित करने के आमतौर पर विनाशकारी परिणाम होते हैं: न्यूलाइन बाइट अनुक्रम की कोई भी घटना - जिसमें इस संदर्भ में लाइन टर्मिनेटर शब्दार्थ नहीं है, लेकिन बाइट्स के सामान्य अनुक्रम का हिस्सा है - जो भी न्यूलाइन प्रतिनिधित्व के लिए अनुवादित किया जाएगा दूसरी प्रणाली प्रभावी रूप से डेटा भ्रष्टाचार फ़ाइल का उपयोग करती है। एफ़टीपी ग्राहक अक्सर द्विआधारी या एएससीआईआई मोड का चयन करने के लिए कुछ ह्यूरिस्टिक (कंप्यूटर विज्ञान) (उदाहरण के लिए, फ़ाइल नाम एक्सटेंशन का निरीक्षण) को नियोजित करते हैं, लेकिन अंत में यह सुनिश्चित करने के लिए उपयोगकर्ताओं पर निर्भर है कि उनकी फाइलें सही मोड में स्थानांतरित की गई हैं। यदि सही मोड के बारे में कोई संदेह है, तो बाइनरी मोड का उपयोग किया जाना चाहिए, क्योंकि तब एफ़टीपी द्वारा कोई फ़ाइल नहीं बदली जाएगी, हालांकि वे गलत तरीके से प्रदर्शित हो सकती हैं।

न्यूलाइन प्रारूपों के बीच रूपांतरण

पाठ संपादकों का उपयोग अक्सर पाठ फ़ाइल को विभिन्न न्यूलाइन स्वरूपों के बीच परिवर्तित करने के लिए किया जाता है; अधिकांश आधुनिक संपादक कम से कम भिन्न ASCII का उपयोग करके फ़ाइलों को पढ़ और लिख सकते हैं CR/LF सम्मेलनों।

उदाहरण के लिए, संपादक विम (पाठ संपादक) विंडोज नोटपैड टेक्स्ट एडिटर के साथ संगत फाइल बना सकता है। विम के भीतर <वाक्यविन्यास प्रकाश लैंग = विम>

:सेट फ़ाइलफॉर्मेट=डॉस
:wq

</वाक्यविन्यास हाइलाइट> बड़ी फ़ाइलों को परिवर्तित करने या कई फ़ाइलों के बल्क रूपांतरण के लिए संपादक अनुपयुक्त हो सकते हैं। बड़ी फ़ाइलों के लिए (Windows NT/2000/XP पर) निम्नलिखित कमांड का प्रयोग अक्सर किया जाता है: <वाक्यविन्यास लैंग = डॉसकॉन> डी:\>टाइप यूनिक्स_फाइल | ढूँढें / वी> dos_file </वाक्यविन्यास हाइलाइट> विभिन्न न्यूलाइन सम्मेलनों के बीच फ़ाइलों को परिवर्तित करने के लिए विशेष प्रयोजन के कार्यक्रमों में शामिल हैं unix2dos|unix2dos और dos2unix, mac2unix और unix2mac, mac2dos और dos2mac, और flip.

tr }} कमांड वस्तुतः हर यूनिक्स जैसी प्रणाली पर उपलब्ध है और इसका उपयोग एकल वर्णों पर मनमाने ढंग से प्रतिस्थापन संचालन करने के लिए किया जा सकता है। सभी ASCII को हटाकर DOS/Windows पाठ फ़ाइल को यूनिक्स प्रारूप में परिवर्तित किया जा सकता है CR के साथ वर्ण
$ tr (यूनिक्स) -d '\r' <inputfile> outputfile

या, यदि पाठ में केवल है CR न्यूलाइन, सभी को परिवर्तित करके CR न्यूलाइन्स टू LF साथ

$ tr (यूनिक्स) '\r' '\n' <inputfile> outputfile

यदि प्लेटफ़ॉर्म में पर्ल दुभाषिया है, तो वही कार्य कभी-कभी awk, sed, या Perl में किए जाते हैं: <वाक्यविन्यास लैंग = कंसोल> $ awk '{उप ($, \ r \ n); printf( %s ,$0);}' inputfile > Outputfile # UNIX to DOS (Linux और BSD आधारित OS पर CRs जोड़ना जिसमें GNU एक्सटेंशन नहीं है) $ awk '{gsub( \r , ); print;}' inputfile > Outputfile # DOS to UNIX (Linux और BSD आधारित OS पर CR को हटा रहा है जिसमें GNU एक्सटेंशन नहीं हैं) $ sed -e 's/$/\r/' inputfile > Outputfile # UNIX to DOS (Linux आधारित OS पर CRs जोड़कर जो GNU एक्सटेंशन का उपयोग करते हैं) $ sed -e 's/\r$//' inputfile > Outputfile # DOS to UNIX (Linux आधारित OS पर CR को हटाना जो GNU एक्सटेंशन का उपयोग करते हैं) $ perl -pe's/\r?\n|\r/\r\n/g' inputfile > Outputfile # DOS में कनवर्ट करें $ perl -pe's/\r?\n|\r/\n/g' inputfile > Outputfile # UNIX में कनवर्ट करें $ perl -pe's/\r?\n|\r/\r/g' inputfile > Outputfile # पुराने मैक में कनवर्ट करें </वाक्यविन्यास हाइलाइट> file }} कमांड लाइन के अंत के प्रकार की पहचान कर सकता है: <वाक्यविन्यास लैंग = कंसोल>

$ फ़ाइल myfile.txt
myfile.txt: ASCII अंग्रेजी पाठ, CRLF लाइन टर्मिनेटर के साथ

</वाक्यविन्यास हाइलाइट> यूनिक्स grep#Implementations (विस्तारित grep) कमांड का उपयोग यूनिक्स या डॉस फाइलों के फ़ाइलनामों को प्रिंट करने के लिए किया जा सकता है (केवल यूनिक्स और डॉस-शैली फ़ाइलों को मानते हुए, कोई क्लासिक मैक ओएस-शैली फ़ाइलें नहीं): <वाक्यविन्यास लैंग = कंसोल> $ egrep -L '\r\n' myfile.txt # UNIX स्टाइल फ़ाइल दिखाएं (LF समाप्त) $ egrep -l '\r\n' myfile.txt # डॉस स्टाइल फ़ाइल दिखाएं (CRLF समाप्त) </वाक्यविन्यास हाइलाइट>

अन्य उपकरण उपयोगकर्ता को ईओएल वर्णों की कल्पना करने की अनुमति देते हैं: <वाक्यविन्यास लैंग = कंसोल> $ ओडी -myfile.txt $ कैट -ई myfile.txt $ बिल्ली -v myfile.txt $ हेक्सडंप -c myfile.txt </वाक्यविन्यास हाइलाइट>

व्याख्या

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

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

उल्टा और आंशिक लाइन फ़ीड्स

RI, (यूनिकोड+008डी रिवर्स लाइन फीड, ISO/IEC 6429 8D, दशमलव 141) का उपयोग मुद्रण स्थिति को पंक्ति पीछे ले जाने के लिए किया जाता है (कागज को उल्टा करके, या डिस्प्ले कर्सर को पंक्ति ऊपर ले जाकर) ताकि अन्य वर्ण मौजूदा पाठ पर मुद्रित किए जा सकें। यह उन्हें बोल्डर बनाने के लिए किया जा सकता है, या अंडरलाइन, स्ट्राइक-थ्रू या अन्य वर्ण जैसे विशेषक जोड़ने के लिए किया जा सकता है।

इसी प्रकार, PLD (यूनिकोड+008बी आंशिक लाइन आगे, दशमलव 139) और PLU (यूनिकोड+008सी पार्टियल लाइन बैकवर्ड, डेसीमल 140) का उपयोग वर्टिकल लाइन स्पेसिंग (आमतौर पर, आधा) के कुछ अंश द्वारा टेक्स्ट प्रिंटिंग स्थिति को आगे बढ़ाने या उलटने के लिए किया जा सकता है। इनका उपयोग सबस्क्रिप्ट्स (आगे बढ़ने और फिर उलटने से) और सुपरस्क्रिप्ट्स (रिवर्सिंग और फिर आगे बढ़ने के द्वारा) के संयोजन में किया जा सकता है, और यह डायक्रिटिक्स को प्रिंट करने के लिए भी उपयोगी हो सकता है।

यह भी देखें

• एएसए कैरिज नियंत्रण वर्ण
• C0 और C1 नियंत्रण कोड
• फाइल समाप्त
• लाइन भूखी
• पृष्ठ ब्रेक
• कैरिज रिटर्न
• कुंजी दर्ज करें

बाहरी संबंध

• The Unicode reference, see paragraph 5.8 in Chapter 5 of the Unicode 4.0 standard (PDF)
• "The [NEL] Newline Character".
• The End of Line Puzzle
• Understanding Newlines at the Wayback Machine (archived 20 August 2006)
• "The End-of-Line Story"