संक्षेप में: "डुप्लीकेट" लाइनें हमेशा एक जैसे बाइट्स नहीं होतीं — अंत में लगी स्पेस, अलग केस, या अलग यूनिकोड नॉर्मलाइज़ेशन वास्तविक डुप्लीकेट छिपा सकते हैं या झूठे डुप्लीकेट बना सकते हैं। यह समझना कि तुलना कैसे काम करती है, आपकी सफ़ाई को सटीक बनाता है, बजाय ज़रूरी लाइनों को गलती से हटा देने के। इस गाइड को Remove Duplicate Lines, Text Difference, Word Frequency और Remove Extra Spaces के साथ जोड़ें।
CharCount पर Duplicate Finder लिस्ट, लॉग, CSV एक्सपोर्ट और कीवर्ड लिस्ट से डुप्लीकेट लाइनें हटाता है। मुश्किल हिस्सा हटाना नहीं है — यह तय करना है कि कुछ भी हटाने से पहले "वही लाइन" किसे माना जाए।
पृष्ठभूमि: JavaScript Set पर MDN रेफ़रेंस उस डेटा स्ट्रक्चर को समझाता है जिसे ज़्यादातर डी-डुप्लीकेशन टूल आंतरिक रूप से उपयोग करते हैं, String.normalize() पर MDN गाइड यूनिकोड नॉर्मलाइज़ेशन को कवर करता है, और यूनिकोड टेक्स्ट सेगमेंटेशन रिपोर्ट (UAX #29) परिभाषित करती है कि टेक्स्ट को अर्थपूर्ण इकाइयों में कैसे बाँटा जाता है।
डुप्लीकेट डिटेक्शन वास्तव में कैसे काम करता है
पर्दे के पीछे, डुप्लीकेट-लाइन टूल हर लाइन पर जाता है और जाँचता है कि क्या यह पहले देखी जा चुकी है — आमतौर पर Set का उपयोग करके, जो अद्वितीय मान संग्रहीत करता है और सटीक डुप्लीकेट को स्थिर समय में अस्वीकार कर देता है। यह तेज़ है, लेकिन "सटीक" शब्द इस वाक्य में बहुत काम कर रहा है: Set स्ट्रिंग्स के UTF-16 कोड यूनिट अनुक्रम की तुलना करता है, इसलिए "सेब" और "सेब " (अंत में स्पेस के साथ) अलग-अलग एंट्री हैं।
यही कारण है कि CSV एक्सपोर्ट या स्क्रैप की गई कीवर्ड लिस्ट पर एक सीधी-सादी डी-डुप्लीकेशन अक्सर "फेल" होती दिखती है — यह टूटी नहीं है, यह ठीक वही तुलना कर रही है जो आपने उसे दिया, जिसमें अदृश्य स्पेस और केस के अंतर भी शामिल हैं जिन पर आपका ध्यान नहीं गया।
क्रम बनाए रखना बनाम पहले सॉर्ट करके फिर डी-डुप्लीकेट करना
दो सामान्य रणनीतियाँ हैं। क्रम-संरक्षक डी-डुप्लीकेशन हर लाइन की पहली उपस्थिति और उसकी मूल स्थिति बनाए रखती है — लॉग, चैट एक्सपोर्ट, या किसी भी ऐसी चीज़ के लिए सही विकल्प जहाँ क्रम मायने रखता है। सॉर्ट-करके-फिर-डी-डुप्लीकेट (क्लासिक Unix पाइपलाइन sort | uniq की तरह) पहले सब कुछ वर्णमाला क्रम में लगा देता है, जो बड़ी फ़ाइलों पर तेज़ है लेकिन मूल क्रम को नष्ट कर देता है — कीवर्ड लिस्ट के लिए ठीक, चेंजलॉग के लिए गलत।
जब भी "पहले क्या आया" मायने रखता है तो क्रम-संरक्षक डी-डुप्लीकेशन चुनें; सॉर्ट-करके-फिर-डी-डुप्लीकेट तभी चुनें जब लिस्ट का क्रम शुरू से ही मनमाना था।
नॉर्मलाइज़ेशन कहाँ परिणाम बदल देता है
यूनिकोड एक ही दिखने वाले कैरेक्टर को अलग-अलग बाइट सीक्वेंस के रूप में मौजूद रहने देता है — एक एक्सेंट वाला कैरेक्टर एक ही संयुक्त कोड पॉइंट (NFC) हो सकता है या एक बेस लेटर प्लस एक अलग कॉम्बाइनिंग एक्सेंट मार्क (NFD)। स्क्रीन पर एक जैसी दिखने वाली दो लाइनें एक सटीक-मिलान डी-डुप्लीकेशन में फेल हो सकती हैं अगर एक Mac एक्सपोर्ट से आई हो और दूसरी Windows से, क्योंकि वे अलग-अलग नॉर्मलाइज़ेशन फ़ॉर्म में हैं।
String.normalize('NFC') तुलना से पहले दोनों फ़ॉर्म को एक ही रिप्रेज़ेंटेशन में समेट देता है, यही कारण है कि एक अच्छा डुप्लीकेट टूल पहले टेक्स्ट को नॉर्मलाइज़ करता है — वरना यह उन डुप्लीकेट को चुपचाप छोड़ देता है जो देखने में एक जैसे हैं, लेकिन उनके Unicode अनुक्रम अलग हैं।
एक सुरक्षित सफ़ाई वर्कफ़्लो
- पहले तय करें: क्या इस लिस्ट के लिए लाइन का क्रम मायने रखता है? यह आपकी रणनीति तय करता है।
- अंत की स्पेस केवल तभी हटाएँ और केस केवल तभी नॉर्मलाइज़ करें जब लिस्ट केस-इनसेंसिटिव मानी गई हो (कीवर्ड लिस्ट अक्सर होती है; पासवर्ड लिस्ट कभी नहीं)।
- डी-डुप्लीकेशन चलाएँ, फिर हटाई गई लाइनों के एक नमूने की जाँच करें कि वे वाकई डुप्लीकेट थीं।
- साफ़ किए गए वर्शन की पुष्टि होने तक मूल फ़ाइल रखें।
किसी भी अस्पष्ट मामले के लिए, पहले/बाद को Text Difference से गुज़ारें ताकि ठीक-ठीक देख सकें कि क्या हटाया गया, और Word Frequency से जाँचें कि किसी वैध दोहराए गए शब्द को शोर मानकर नहीं हटाया गया।