टेक्स्ट और रोजमर्रा के टूल · टेक्स्ट टूलकिट
CR, LF और CRLF: पंक्ति के अंत कहां से आते हैं और चिपकाया गया पाठ क्यों टूट जाता है
· पेजभूमि
पंक्ति-अंत पाठ-सफाई डेटा-निर्यात
कैरिज रिटर्न और लाइन फ़ीड की टेलेटाइप उत्पत्ति की व्याख्या करता है, ऑपरेटिंग सिस्टम ने अलग-अलग सम्मेलनों को क्यों चुना, और कैसे वे विकल्प चिपकाए गए पाठ में दोगुनी रिक्त रेखाओं और भटके हुए वर्णों के रूप में दिखाई देते हैं।
प्रत्येक पंक्ति के बाद एक रिक्त पंक्ति के साथ निर्यात - दूसरे सिस्टम से एक फ़ाइल दोगुनी पंक्तियों के साथ क्यों चिपकती है
आप तीन-पंक्ति निर्यात चिपकाते हैं और प्रत्येक रिकॉर्ड के बाद एक रिक्त पंक्ति देखते हैं। विंडोज़ CRLF को तुरंत दोष देना आकर्षक है, लेकिन एक मानक-अनुरूप पाठ क्षेत्र सामान्य रूप से लाइन ब्रेक को सामान्यीकृत रूप में प्रस्तुत करता है। दोगुनी पंक्तियों का मतलब अक्सर यह होता है कि पहले के रूपांतरण में कैरिज रिटर्न और लाइन फ़ीड को दो स्वतंत्र विभाजक के रूप में माना जाता था, या रिकॉर्ड के बीच एक अतिरिक्त नई लाइन डाली जाती थी।
मूल को तब तक अपने पास रखें जब तक आप यह न जान लें कि किस चरण ने इसे बदल दिया। किCAडिटर में स्रोत की तुलना करें जो नियंत्रण वर्ण प्रकट कर सकता है, फिर चिपकाई गई पंक्ति गणना की तुलना करें। ToolAcre जानबूझकर CRLF, LF और लोन CR को एक-एक सीमा के रूप में स्वीकार करता है, इसलिए एक अछूती तीन-रिकॉर्ड फ़ाइल को केवल छह के बजाय तीन लाइनें उत्पन्न करनी चाहिए क्योंकि यह विंडोज़ से आई है।
एक अतिरिक्त रिक्त पंक्ति एक लक्षण है, इस बात का प्रमाण नहीं कि CRLF अकेले ही इसका कारण बनी
नाम मुद्रण टर्मिनलों पर भौतिक क्रियाओं का वर्णन करते हैं। एक कैरिज रिटर्न ने कैरिज को वर्तमान लाइन की शुरुआत में ले जाया, जबकि एक लाइन फीड ने कागज को अगली लाइन में आगे बढ़ाया। वे अलग-अलग नियंत्रण थे क्योंकि किसी भी प्रस्ताव का स्वतंत्र रूप से अनुरोध किया जा सकता था। ASCII ने उन्हें दशमलव 13 पर नियंत्रण वर्ण CR और दशमलव 10 पर LF के रूप में बनाए रखा।
आधुनिक स्क्रीन अब कागज नहीं हिलाती हैं, फिर भी फाइलों, प्रोटोकॉल और प्रोग्रामिंग इंटरफेस में बाइट मान बचे रहते हैं। इतिहास बताता है कि क्यों CR और LF विनिमेय विराम चिह्न नहीं हैं और क्यों CRLF दो-वर्ण अनुक्रम है। इसका मतलब यह नहीं है कि प्रत्येक आधुनिक एप्लिकेशन उन्हें अलग से संसाधित करता है; पार्सर्स आमतौर पर जोड़ी को एक तार्किक अंत वाली रेखा के रूप में पहचानते हैं।
तीन परंपराएं - Unix और आधुनिक मैकOS पर LF, विंडोज पर CRLF, क्लासिक मैक OS पर CR, और प्रत्येक उचित क्यों लगता है
Unix और Unix जैसी प्रणालियाँ पारंपरिक रूप से लाइन समाप्ति के लिए LF का उपयोग करती हैं, और आधुनिक मैकOS उस सम्मेलन का पालन करता है। विंडोज़ टेक्स्ट फ़ाइलें पारंपरिक रूप से CRLF का उपयोग करती हैं। क्लासिक मैक OS ने अकेले CR का उपयोग किया, लेकिन मैक OS एक्स ने Unix फाउंडेशन और LF को अपनाया। जब टूल सामान्यीकरण पर सहमति के बिना सादे पाठ का आदान-प्रदान करते हैं तो वे विकल्प दृश्यमान रहते हैं।
शब्द खुद इन convention से नहीं बदलते। समस्या तब आती है जब reader सीमा पर केवल एक representation की उम्मीद करे या हर control character पर सीधे split करे। मज़बूत line parser पहले CRLF जोड़ी जाँचता है, फिर अकेला CR या LF। ToolAcre यही काम ordered pattern ` | | ` से करता है और बदला output LF से जोड़ता है।
ब्राउज़र टेक्स्ट बॉक्स में क्या होता है - पेस्ट पर लाइन ब्रेक को आम तौर पर कैसे सामान्य किया जाता है और जहां भटके हुए अक्षर अभी भी दिखाई देते हैं
HTML टेक्स्ट नियंत्रण में लाइन ब्रेक के लिए विशेष हैंडलिंग को परिभाषित करता है। टेक्स्टएरिया मान में, ब्राउज़र CRLF को सामान्यीकृत करते हैं और उजागर मान में CR को LF में बदल देते हैं, जबकि फॉर्म सबमिशन लाइन ब्रेक के लिए फॉर्म-डेटा नियमों को लागू कर सकता है। नतीजतन, एक पेस्ट जो बॉक्स में सही दिखता है उसे अभी भी किसी अन्य परत द्वारा अलग तरीके से क्रमबद्ध किया जा सकता है या किसी अन्य कन्वेंशन के साथ सॉफ़्टवेयर में कॉपी किया जा सकता है।
जब टेक्स्ट सामान्य टेक्स्ट क्षेत्र को बायपास कर देता है, जब शाब्दिक वर्ण `\r` जैसे एस्केप्ड बाइट्स प्रदर्शित होते हैं, या जब एक पार्सर केवल LF पर विभाजित होता है और CR को प्रत्येक फ़ील्ड से जुड़ा हुआ छोड़ देता है, तब भी स्ट्रे CR सतह पर आ सकता है। ब्राउज़र पथ में एक चरण है, फ़ाइलों, क्लिपबोर्ड उत्पादकों, APआई और कमांड-लाइन उपभोक्ताओं के लिए एक सार्वभौमिक मरम्मत सेवा नहीं है।
ब्राउज़र टेक्स्टएरिया लाइन ब्रेक को सामान्य करते हैं, लेकिन क्लिपबोर्ड और डाउनस्ट्रीम प्रारूप अभी भी भिन्न हैं
रिक्त पंक्तियों और अनुगामी कैरिज रिटर्न के लिए अलग-अलग निदान की आवश्यकता होती है। खाली पंक्तियाँ हटाएँ उन पंक्तियों को हटा देता है जिनकी सामग्री ToolAcre द्वारा सभी तीन पंक्ति-समाप्ति शैलियों को पहचानने के बाद खाली या रिक्त स्थान है। ट्रिम लाइन्स प्रत्येक पंक्ति से आगे और पीछे वाले रिक्त स्थान को हटा देती है। क्योंकि ToolAcre का स्प्लिटर एक वास्तविक CR विभाजक का उपभोग करता है, केवल उस विभाजक को मिटाने के लिए ट्रिमिंग की आवश्यकता नहीं होती है।
ट्रिमिंग का उपयोग केवल तभी करें जब रिक्त स्थान, टैब या कोई शाब्दिक अप्रयुक्त वर्ण रह जाए, और इसे बदलने से पहले सार्थक इंडेंटेशन का निरीक्षण करें। यदि पाठ में दृश्यमान `^M` है, तो निर्धारित करें कि दर्शक वास्तविक CR या उन दो मुद्रण योग्य वर्णों को प्रस्तुत कर रहा है या नहीं। ब्लैंकेट प्रतिस्थापन इच्छित सामग्री को नुकसान पहुंचा सकता है, जबकि पहले और बाद में जांच करने से समीक्षा योग्य परिणाम मिलता है।
ख़ाली पंक्तियाँ हटाएँ ख़ाली पंक्तियाँ ठीक करती हैं; ToolAcre CR को सही ढंग से विभाजित करने के बाद ट्रिमिंग आमतौर पर अनावश्यक होती है
प्रतिलिपि प्रस्तुत करने योग्य उदाहरण के लिए, तीन नामों से प्रारंभ करें जिनके क्षतिग्रस्त मध्यवर्ती प्रतिनिधित्व में प्रत्येक नाम के बीच एक खाली पंक्ति है: `Ada`, रिक्त, `Grace`, रिक्त, `Linus`। शब्द और चरित्र काउंटर पाँच पंक्तियों की रिपोर्ट करता है। यह जानबूझकर दोगुना किया गया इनपुट है; केवल एक वास्तविक CRLF अनुक्रम को एक सीमा के रूप में पहचाना जाएगा और ToolAcre में वे खाली पंक्तियाँ नहीं बनाई जाएंगी।
खाली रेखाएं हटाएं चुनें और आउटपुट LF के साथ जुड़कर तीन लाइनें बन जाता है। काउंटर को अब तीन की रिपोर्ट करनी चाहिए। यदि आयातित मानों में भी पैडिंग है, तो ट्रिम लाइन्स को अलग से चलाएँ और परिणाम की समीक्षा करें। उन ऑपरेशनों को अलग करने से यह साबित होता है कि प्रत्येक क्लीनअप को विंडोज़ टेक्स्ट से अस्पष्ट रूपांतरण के लिए जिम्मेदार ठहराने के बजाय प्रत्येक क्रिया को दोष दिया गया है।
कार्यान्वित उदाहरण: जानबूझकर दोगुने किए गए निर्यात को साफ़ करें और लाइन गिनती को सत्यापित करें
लाइन-एंडिंग क्लीनअप हार्ड रैपिंग की मरम्मत नहीं करता है, जहां एक तार्किक वाक्य को कॉलम की चौड़ाई पर जानबूझकर तोड़ा गया था। उस सामग्री से प्रत्येक नई पंक्ति को हटाने से वास्तविक पैराग्राफ और सूची आइटम भी जुड़ जाएंगे। पूरे ब्लॉक में लाइन ऑपरेशन लागू करने से पहले तय करें कि क्या सीमा एक रिकॉर्ड, एक पैराग्राफ या विज़ुअल रैपिंग का प्रतिनिधित्व करती है।
यह वर्ण एन्कोडिंग का भी निदान नहीं करता है. UTF-8 बाइट ऑर्डर चिह्न, प्रतिस्थापन हीरे, मोजिबेक और डिकोडिंग विफलताएं इस बात से संबंधित हैं कि बाइट्स वर्ण कैसे बनते हैं, न कि यह कि क्या CR या LF उन वर्णों को पंक्तियों में अलग करता है। मूल फ़ाइल को सुरक्षित रखें और अजीब दिखाई देने वाले प्रतीकों को लाइन एंडिंग के रूप में मानने से पहले एक उपयुक्त फ़ाइल-जागरूक टूल के साथ इसकी एन्कोडिंग की पहचान करें।
टेकअवे - पंक्ति का अंत इतिहास है जिसे आप देख सकते हैं; टेक्स्ट टूलकिट के लाइन टूल और काउंटर आपको लक्षणों को सेकंडों में ठीक करने देते हैं
CR, LF और CRLF वर्तमान अनुकूलता परिणामों के साथ ऐतिहासिक नियंत्रण हैं। सबसे सुरक्षित मानसिक मॉडल कई भौतिक अभ्यावेदन के साथ एक तार्किक रेखा सीमा है। रिकॉर्ड्स की गणना करें, स्रोत सम्मेलन का निरीक्षण करें और उस चरण की पहचान करें जिसने कुछ भी हटाने से पहले खाली पंक्तियां पेश कीं या नियंत्रण वर्ण बनाए रखे।
चिपकाई गई सामग्री के लिए, टेक्स्ट टूलकिट को `/tools/text/` पर खोलें, आरंभिक पंक्ति गणना नोट करें, रिक्त पंक्तियाँ हटाएँ केवल तभी लागू करें जब खाली पंक्तियाँ वास्तव में अवांछित हों, और ट्रिम लाइन्स का उपयोग केवल आसपास के रिक्त स्थान के लिए करें। बाद में गिनती और नमूना रिकॉर्ड दोबारा जांचें। वह संक्षिप्त ऑडिट एक अदृश्य स्वरूपण समस्या को नियंत्रित, प्रतिवर्ती पाठ परिवर्तन में बदल देता है।