टेक्स्ट क्लीनर

हर ऑपरेशन क्या करता है

यह कैसे काम करता है

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

आम उपयोग

• ईमेल, कीवर्ड, URL या ID की किसी सूची से डुप्लिकेट हटाएँ और क्रमबद्ध करें।
• PDF, स्प्रेडशीट या चैट से पेस्ट किए गए टेक्स्ट को साफ़ करें (अतिरिक्त स्पेस और खाली पंक्तियाँ)।
• किसी कॉपी किए वेब स्निपेट से HTML टैग हटाकर सादा टेक्स्ट पाएँ।
• मानों के एक कॉलम को अल्पविराम-पृथक सूची में बदलें (या वापस पंक्तियों में)।
• हर पंक्ति में बुलेट चिह्न, उद्धरण या अल्पविराम जोड़ें, या किसी सूची को नंबर दें।
• टैब को स्पेस में (या इसके उलट) बदलकर इंडेंटेशन को सामान्य बनाएँ।

पेस्ट किया गया टेक्स्ट अदृश्य कचरे से भरा क्यों होता है

टेक्स्ट शायद ही कभी साफ़ आता है। जब आप Microsoft Word, Google Docs, किसी PDF, ईमेल क्लाइंट या वेब पेज से कॉपी करते हैं, तो दिखने वाले शब्दों के साथ फ़ॉर्मैटिंग वर्णों की एक परत आती है जिसे आप कभी नहीं देखते। वर्ड प्रोसेसर चुपचाप नॉन-ब्रेकिंग स्पेस, कर्ली कोट्स और सॉफ़्ट हाइफ़न डाल देते हैं; वेब पेज   एंटिटीज़ और लेआउट के लिए इस्तेमाल किए गए भटके हुए ज़ीरो-विड्थ वर्ण जोड़ते हैं; और PDF तो सबसे बड़े अपराधी हैं, क्योंकि उनका टेक्स्ट असल में स्थिति-बद्ध ग्लिफ़ों का समूह होता है। किसी PDF से कॉपी करने पर अक्सर वाक्यों के बीच में कठोर लाइन-ब्रेक, संरेखित कॉलमों से बची हाइफ़नेशन, "fi" के बजाय fi जैसे संयुक्ताक्षर, और टेबल कॉलमों की जगह लेते स्पेस की लड़ियाँ मिलती हैं। इसमें से कुछ भी किसी कोड एडिटर, स्प्रेडशीट, डेटाबेस फ़ील्ड या सर्च बॉक्स में पेस्ट करें और यह ऐसे तरीक़ों से टूट सकता है जिन्हें डिबग करना पागल कर देने वाला होता है, ठीक इसलिए कि दोषी अदृश्य है। टेक्स्ट साफ़ करना काफ़ी हद तक उस छिपी परत को छीलकर सादे, पूर्वानुमेय वर्णों तक ले आने की कला है।

लाइन एंडिंग: LF, CRLF और पुराना Mac CR

टेक्स्ट की हर पंक्ति एक अदृश्य नियंत्रण वर्ण से समाप्त होती है, और तीन अलग-अलग परंपराएँ आज भी सक्रिय उपयोग में हैं। Unix, Linux, macOS और आधुनिक वेब एकल लाइन फ़ीड, LF (\n, U+000A) इस्तेमाल करते हैं। Windows और DOS एक कैरिज रिटर्न के बाद लाइन फ़ीड, CRLF (\r\n, U+000D U+000A) इस्तेमाल करते हैं — वही जोड़ी जो HTTP हेडर और कई इंटरनेट प्रोटोकॉल अनिवार्य करते हैं। क्लासिक Mac OS, संस्करण 9 तक, अकेला कैरिज रिटर्न, CR (\r) इस्तेमाल करता था। इन्हें मिलाने से असली समस्याएँ होती हैं: भटके कैरिज रिटर्न वाली फ़ाइल डिफ़ और कुछ एडिटरों में ^M के रूप में दिखती है, इंटरप्रेटर पंक्ति पर "command not found" त्रुटियों के साथ शेल स्क्रिप्ट तोड़ देती है, और वर्शन कंट्रोल में दो दृश्यतः समान फ़ाइलों को अलग तुलना करा सकती है। यह क्लीनर किसी भी और चीज़ से पहले तीनों परंपराओं को एकल लाइन फ़ीड में सामान्य कर देता है, ताकि बाक़ी पाइपलाइन हर पंक्ति को एक-सा माने।

अदृश्य और एक-सी दिखने वाली चीज़ें जो गड़बड़ करती हैं

मुट्ठी भर यूनिकोड वर्ण या तो पूरी तरह अदृश्य हैं या एक साधारण स्पेस से दृश्यतः अभिन्न हैं, फिर भी वे वे वर्ण नहीं हैं जिनकी कोई कंप्यूटर अपेक्षा करता है। चूँकि आप उन्हें देख नहीं सकते, वे कॉपी-पेस्ट में बच जाते हैं और चुपचाप सटीक-मिलान खोज, स्प्रेडशीट लुकअप, CSV इम्पोर्ट, फ़ॉर्म सत्यापन और कोड में स्ट्रिंग तुलना को तोड़ देते हैं — शब्द "total" और अंत में एक छिपे ज़ीरो-विड्थ स्पेस वाला शब्द "total" बस बराबर नहीं होते।

इनमें से अधिकांश उन वेब पेजों और वर्ड प्रोसेसरों से आते हैं जो इन्हें टाइपसेटिंग के लिए इस्तेमाल करते हैं। इन्हें हटा देना या किसी सामान्य स्पेस से बदल देना एक क्लीनर के सबसे मूल्यवान कामों में से एक है, क्योंकि लक्षण — "मेरा लुकअप कहता है कि ये दो सेल अलग हैं जबकि वे एक जैसे दिखते हैं" — आपको लगभग कोई सुराग नहीं देता कि कहाँ देखें।

स्मार्ट कोट्स और डैश बनाम उनके ASCII जुड़वाँ

Word, Google Docs और कई प्रकाशन प्रणालियाँ आपके टाइप करते ही आपकी टाइपोग्राफ़ी को स्वतः "सुधार" देती हैं: सीधे उद्धरण कर्ली बन जाते हैं और दोहरे हाइफ़न डैश बन जाते हैं। गद्य के लिए यह परिष्कृत दिखता है, पर किसी ऐसी चीज़ के लिए जिसे किसी मशीन को पार्स करना हो, यह रहस्यमय विफलताओं का बार-बार होने वाला स्रोत है। आपके कीबोर्ड पर सीधा एपॉस्ट्रॉफ़ी और उद्धरण-चिह्न ASCII U+0027 और U+0022 हैं; उनके टाइपोग्राफ़िक प्रतिस्थापन बाएँ और दाएँ एकल उद्धरण U+2018 और U+2019 तथा बाएँ और दाएँ दोहरे उद्धरण U+201C और U+201D हैं। इसी तरह सादा हाइफ़न-माइनस U+002D अक्सर एन डैश U+2013 या एम डैश U+2014 से बदल दिया जाता है।

मुसीबत यह है कि ये एक-सी दिखने वाली चीज़ें कोड में विनिमेय नहीं हैं। उदाहरण के लिए, JSON को हर कुंजी और स्ट्रिंग मान के चारों ओर सीधा दोहरा उद्धरण U+0022 चाहिए; उसकी जगह कर्ली उद्धरण पेस्ट करें और पार्सर पूरे दस्तावेज़ को अस्वीकार कर देता है। किसी कॉन्फ़िगरेशन फ़ाइल, CSV, URL या डेटाबेस पहचानकर्ता में गिरा एक एम डैश आमतौर पर दृश्य समीक्षा में बच जाता है — यह हाइफ़न जैसा पढ़ा जाता है — पर उसी क्षण विफल हो जाता है जब सॉफ़्टवेयर उसे शाब्दिक रूप से मानता है। समाधान है कि टेक्स्ट के कोड तक पहुँचने से पहले स्मार्ट विराम-चिह्नों को उनके ASCII समकक्ष में बदल दें, या पहले से ही मशीन-बद्ध टेक्स्ट को किसी सादे एडिटर में रचें। कर्ली उद्धरणों को सीधे उद्धरणों से, और एन या एम डैश को सादे हाइफ़न से बदलना किसी प्रोग्राम की ओर जा रहे किसी भी टेक्स्ट के लिए एक नियमित, सुरक्षित सामान्यीकरण है।

यूनिकोड नॉर्मलाइज़ेशन: NFC, NFD, NFKC और NFKD

वही दिखने वाला टेक्स्ट कोड पॉइंट के अलग-अलग अनुक्रमों के रूप में संग्रहीत हो सकता है। उच्चारण-चिह्नित अक्षर é एक अकेला पूर्व-रचित वर्ण (U+00E9) हो सकता है या एक सादा "e" जिसके बाद एक संयोजी तीव्र उच्चारण-चिह्न (U+0301) हो। वे अभिन्न दिखते हैं और एक ही अर्थ रखते हैं, पर बाइट-दर-बाइट वे भिन्न स्ट्रिंग हैं, इसलिए कोई खोज या तुलना एक को चूक सकती है जबकि दूसरे से मेल खा सकती है। यूनिकोड नॉर्मलाइज़ेशन, जिसे Unicode Standard Annex #15 परिभाषित करता है, टेक्स्ट को चार कैनोनिकल रूपों में से एक में फिर से लिखता है ताकि समकक्ष स्ट्रिंग अभिन्न बन जाएँ।

"K" (संगतता) रूप शक्तिशाली पर हानिकारक (lossy) हैं: NFKC, fi संयुक्ताक्षर को "fi" में, पूर्ण-चौड़ाई Ａ को सामान्य "A" में और सुपरस्क्रिप्ट ² को "2" में बदल देता है। ढीले मिलान और खोज के लिए यही आप चाहते हैं, पर यह फ़ॉर्मैटिंग भेद मिटा देता है, इसलिए Unicode Consortium मनमाने टेक्स्ट पर NFKC या NFKD को आँख मूँदकर लागू करने के प्रति चेतावनी देता है। अधिकांश सफ़ाई कार्यों के लिए NFC सुरक्षित विकल्प है; NFKC तभी चुनें जब आप विशेष रूप से उन संगतता वर्णों को समतल करना चाहते हों।

होमोग्लिफ़ और यूनिकोड स्पूफ़िंग

कुछ वर्ण अदृश्य नहीं बल्कि एक-सा दिखने वाले होते हैं, और यह सुव्यवस्था जितनी ही एक सुरक्षा समस्या भी है। लैटिन, सिरिलिक और ग्रीक वर्णमालाओं में से हर एक में ऐसे अक्षर हैं जो लगभग हर फ़ॉन्ट में एक-सा प्रस्तुत होते हैं: लैटिन "a" (U+0061) और सिरिलिक "а" (U+0430) स्क्रीन पर अभिन्न हैं, वैसे ही लैटिन "o" (U+006F) और सिरिलिक "о" (U+043E)। एक को दूसरे से बदलना होमोग्लिफ़ (homoglyph) हमला कहलाता है। इसके सबसे प्रसिद्ध रूप, अंतरराष्ट्रीयकृत-डोमेन-नाम होमोग्राफ़ हमले में, एक रजिस्ट्रार एक-सी दिखने वाले वर्णों से एक वेब पता बनाता है ताकि कोई दुर्भावनापूर्ण साइट apple.com पढ़ती दिखे जबकि असल में यह Punycode में एन्कोड किया गया एक भिन्न डोमेन हो (वही xn-- उपसर्ग जो आप कभी-कभी देखते हैं)। 2017 का एक व्यापक रूप से उद्धृत प्रदर्शन ऐसा एक डोमेन पंजीकृत करता था जिसे कुछ ब्राउज़र "apple.com" के रूप में दिखाते थे।

वही चाल पता-बार से बहुत दूर भी दिखती है: किसी यूज़रनेम, कूपन कोड, स्प्रेडशीट कुंजी या सोर्स-कोड पहचानकर्ता में छिपा एक सिरिलिक अक्षर दो "अभिन्न" मानों को सत्यापन से बचा सकता है या चुपचाप मेल न खाने दे सकता है। टेक्स्ट को किसी ज्ञात वर्णमाला तक सीमित करना, या कम से कम मिश्रित-लिपि सामग्री को चिह्नित करना, बचाव है — और पहला क़दम हमेशा उन छिपे वर्णों को दृश्य बनाना है, ठीक वही जो टेक्स्ट साफ़ करना आपको करने देता है।

कौन-सी सफ़ाई लागू करें, यह चुनना

सफ़ाई कोई एक ऑपरेशन नहीं बल्कि एक टूलबॉक्स है, और सही चुनाव पूरी तरह इस पर निर्भर करता है कि टेक्स्ट कहाँ जा रहा है। एक ऐसा रूपांतरण जो किसी बिखरी सूची को बचाता है, वह किसी कोड फ़ाइल को चुपचाप बिगाड़ सकता है, इसलिए ऑपरेशन को गंतव्य से मिलाना फ़ायदेमंद है।

• HTML टैग हटाएँ जब आप किसी कॉपी किए वेब स्निपेट या ईमेल हस्ताक्षर से पढ़ने योग्य टेक्स्ट चाहते हों। यह ग़लत क़दम है यदि आपको वास्तव में मार्कअप चाहिए — किसी टेम्पलेट या ईमेल बॉडी से टैग हटाना उसी संरचना को फेंक देता है जिसे आप रखना चाहते थे।
• इमोजी और चिह्न हटाएँ उन फ़ील्डों के लिए जिन्हें मशीन-साफ़ रहना है: यूज़रनेम, फ़ाइल नाम, प्रोडक्ट SKU, CSV कुंजियाँ और URL। सामान्य गद्य, सोशल कैप्शन या चैट लॉग के लिए, इन्हें हटाना आमतौर पर सुव्यवस्थित करने के बजाय अर्थ नष्ट कर देता है।
• खाली पंक्तियाँ समेटें — कई खाली पंक्तियों को एक में घटाना — PDF या ईमेल से पेस्ट किए गद्य को सुव्यवस्थित करने के लिए, जहाँ भटके अनुच्छेद-ब्रेक जमा हो जाते हैं। ऐसे फ़ॉर्मैटों से सावधान रहें जहाँ खाली पंक्तियाँ अर्थपूर्ण हों, जैसे Markdown (अनुच्छेद विभाजक) या नियत-चौड़ाई डेटा।
• स्पेस की लड़ियाँ समेटें ऐसे टेक्स्ट को ठीक करने के लिए जहाँ टैब या संरेखण-स्पेसिंग लंबे अंतरालों में समतल हो गई हो। इसे सोर्स कोड पर कभी लागू न करें, जहाँ इंडेंटेशन महत्वपूर्ण है, या स्पेस से कॉलम-संरेखित किसी चीज़ पर।
• केस फ़ोल्डिंग — सब कुछ छोटे या बड़े अक्षरों में करना — अक्षर-असंवेदनशील तुलना कुंजियाँ बनाने और सूचियों से डुप्लिकेट हटाने के लिए है, प्रदर्शन-टेक्स्ट के लिए नहीं, जहाँ यह उचित संज्ञाओं, संक्षिप्ताक्षरों और वाक्य-आरंभ के बड़े अक्षरों को बिगाड़ देगी।

स्वर्णिम नियम यह है कि कई मशीन-फ़ॉर्मैटों में व्हाइटस्पेस और केस महत्वपूर्ण होते हैं। Python और YAML ठीक-ठीक इंडेंटेशन पर निर्भर हैं, Makefiles को असली टैब वर्ण चाहिए, और Markdown खाली पंक्तियों तथा आगे के स्पेसों को संरचना मानता है। जब टेक्स्ट इनमें से किसी के लिए बना हो, तो उन अदृश्य और एक-सी दिखने वाली चीज़ों को साफ़ करें जो सचमुच बग पैदा करती हैं — ज़ीरो-विड्थ वर्ण, नॉन-ब्रेकिंग स्पेस, स्मार्ट कोट्स, बेमेल लाइन एंडिंग — पर अर्थपूर्ण व्हाइटस्पेस को छेड़ें नहीं। चूँकि यह टूल अपने चरण एक निश्चित क्रम में लागू करता है और परिणाम तुरंत दिखाता है, आप एक बार में एक ऑपरेशन टॉगल कर सकते हैं और ठीक-ठीक देख सकते हैं कि हर बदलाव क्या करता है, इससे पहले कि आप आउटपुट पर भरोसा करें।

अक्सर पूछे जाने वाले सवाल

टेक्स्ट क्लीनर क्या करता है?

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

ऑपरेशन किस क्रम में लागू होते हैं?

हमेशा वही पूर्वानुमेय क्रम ताकि परिणाम दोहराने योग्य रहे: 1) HTML हटाएँ, 2) प्रति पंक्ति — टैब/स्पेस बदलें, स्पेस समेटें, फिर ट्रिम करें, 3) खाली पंक्तियाँ हटाएँ, 4) डुप्लिकेट हटाएँ, 5) क्रमबद्ध करें या उलटें, 6) प्रीफ़िक्स/सफ़िक्स जोड़ें, 7) पंक्तियों को नंबर दें, 8) जोड़ें। चूँकि क्रम निश्चित है, वही इनपुट और वही सेटिंग हमेशा एक ही आउटपुट देती हैं।

“डुप्लिकेट पंक्तियाँ हटाएँ” यह कैसे तय करता है कि कौन-सी डुप्लिकेट है?

यह पिछले चरण चल जाने के बाद पूरी पंक्ति की तुलना करता है (यानी ट्रिमिंग और समेटना पहले होता है)। कोई पंक्ति पहली बार आती है तो रख ली जाती है; बाद की कोई भी समरूप पंक्ति हटा दी जाती है, क्रम बना रहता है। “अक्षर-असंवेदनशील” चुनें तो “Apple” और “apple” को एक ही पंक्ति माना जाता है।

क्या यह मेरी पंक्तियों का क्रम बदलेगा?

नहीं — जब तक आप कोई सॉर्ट विकल्प या “क्रम उलटें” न चुनें। सॉर्ट “कोई नहीं” पर सेट होने पर हर ऑपरेशन मूल पंक्ति-क्रम बनाए रखता है (डुप्लिकेट यथास्थान हटते हैं, खाली पंक्तियाँ यथास्थान हटती हैं)।

क्या सॉर्टिंग संख्याओं को सही ढंग से संभालती है?

हाँ। सॉर्टिंग संख्या-सजग है, इसलिए “file2” सामान्य पाठ-क्रम की बजाय “file10” से पहले आता है, जो अन्यथा “file10” को पहले रख देता। क्रमबद्ध करते समय बड़े-छोटे अक्षरों की उपेक्षा के लिए इसे “अक्षर-असंवेदनशील” के साथ जोड़ें।

क्या मेरा टेक्स्ट कहीं अपलोड होता है?

नहीं। हर ऑपरेशन पूरी तरह आपके ब्राउज़र में JavaScript का उपयोग करके चलता है — आपका टेक्स्ट कभी आपके डिवाइस से बाहर नहीं जाता। आप टूल को ऑफ़लाइन और संवेदनशील सामग्री पर बिना किसी गोपनीयता जोखिम के इस्तेमाल कर सकते हैं।

संबंधित टूल

• शब्द गणना काउंटर
• केस कन्वर्टर
• टेक्स्ट डिफ़ चेकर
• संख्या को शब्दों में बदलें
• रेगेक्स टेस्टर
• HTML एंटिटी एन्कोडर / डिकोडर