डेवलपर टूल · पाठ तुलना
हर पंक्ति बदल गई? लाइन एंडिंग्स, ट्रेलिंग स्पेस और बीओएम एक अंतर में
· यह काम किस प्रकार करता है
पाठ-अंतर पंक्ति-अंत डिबगिंग
तुलना के तीन अदृश्य कारणों का निदान करता है जो प्रत्येक पंक्ति को अलग बताता है, और दिखाता है कि लेखक को दोष देने से पहले यह कैसे बताया जाए कि आपके पास कौन सा है।
एक ही फ़ाइल, दो बार सहेजी गई, जाहिरा तौर पर फिर से लिखी गई - दो ऑपरेटिंग सिस्टम पर संपादित फ़ाइल का सामान्य मामला सेट करती है
जब कोई एडिटर अदृश्य वर्णों को बदलता है तो दो सेव पुनर्लेखन की तरह दिख सकते हैं, लेकिन ToolAcre का व्यवहार इस बात पर निर्भर करता है कि कौन से वर्ण बदले गए हैं। यह मिलान से पहले लाइन के अंत को सामान्य कर देता है, जबकि लाइन के किनारे पर रिक्त स्थान और शुरुआत में U+FEFF सामान्य लाइन सामग्री बने रहते हैं जब तक कि कोई अन्य विकल्प कुंजी नहीं बदलता।
रंग से अनुमान लगाने के बजाय एक डायग्नोस्टिक फिक्स्चर बनाएं। एक जोड़ी की तुलना करें जो केवल अंत में भिन्न है, दूसरे की अनुगामी रिक्त स्थान में भिन्नता है, और तीसरी की अग्रणी BOM के साथ तुलना करें। नियंत्रित जोड़े एक वास्तविक फ़ाइल की तुलना में टूल की सीमाओं को अधिक विश्वसनीय रूप से प्रकट करते हैं जिसमें एक साथ कई अदृश्य परिवर्तन होते हैं।
CRLF बनाम LF: प्रत्येक पंक्ति के अंत में वर्ण - बताता है कि विंडोज़ दो वर्णों के साथ पंक्तियों को क्यों समाप्त करता है, Unix एक के साथ, और एक अंतर अतिरिक्त कैरिज रिटर्न को कैसे देखता है
`splitLines` CRLF को प्रतिस्थापित करता है और अकेले CR को LF से बदल देता है, फिर विभाजित हो जाता है। परीक्षण स्थापित करते हैं कि सभी तीन सम्मेलन समान सरणियाँ उत्पन्न करते हैं। इसलिए CRLF-केवल अंतर तब भी अदृश्य रहता है, जब इग्नोर व्हाइटस्पेस बंद हो; रूपरेखा का दावा है कि प्रत्येक पंक्ति अलग-अलग होगी, इस कार्यान्वयन का खंडन करती है।
एक अंतिम नई पंक्ति भी एक अतिरिक्त पंक्ति नहीं बनाती है। विभाजन के बाद, एक टर्मिनल खाली प्रविष्टि हटा दी जाती है। बीच में वास्तविक खाली रेखाएँ तुलनात्मक इकाइयाँ बनी रहती हैं, इसलिए व्यवहार फ़ाइल-समाप्ति सम्मेलन को दस्तावेज़ के अंदर जानबूझकर लंबवत पृथक्करण से अलग करता है।
ToolAcre तुलना से पहले CRLF, CR और LF को सामान्य कर देता है, इसलिए केवल अंत वाले परिवर्तन गायब हो जाते हैं
अनुगामी स्थान मूल पंक्तियों में बने रहते हैं। सामान्य तुलना के साथ, `name=value` और `name=value ` की अलग-अलग कुंजियाँ हैं। व्हाइटस्पेस के दोनों सिरों को ट्रिम करने और आंतरिक रन को ढहाने पर ध्यान न दें, ताकि विकल्प प्रदर्शित समान पंक्ति में बाएं मूल पाठ को संरक्षित करते हुए जोड़ी को मैच कर सके।
लाइब्रेरी एक संकीर्ण `ignoreTrailingWhitespace` विकल्प भी लागू करती है, लेकिन वर्तमान UI इसे उजागर नहीं करती है। लेखों में ऐसे चेकबॉक्स का वर्णन नहीं होना चाहिए जिसे उपयोगकर्ता नहीं चुन सकते। शिप किया गया पैनल इग्नोर केस, सभी व्हाइटस्पेस अंतरों को इग्नोर करें और लंबे समय तक अपरिवर्तित रन को संक्षिप्त करने की पेशकश करता है।
फ़ाइल के शीर्ष पर बाइट-ऑर्डर चिह्न - U+FEFF वर्ण का वर्णन करता है जिसे कुछ एडिटर UTF-8 फ़ाइलों से जोड़ते हैं और यह केवल पहली पंक्ति को भिन्न क्यों बनाता है
UTF-8 बाइट-ऑर्डर मार्क को JavaScript टेक्स्ट में डिकोड किया गया है जो पहली पंक्ति की शुरुआत में U+FEFF है। `splitLines` में कोई स्पष्ट BOM निष्कासन नहीं है। साधारण मिलान के साथ, वह वर्ण केवल पहली पंक्ति को भिन्न बना सकता है जबकि बाद की पंक्तियाँ समान रहती हैं।
JavaScript व्हाइटस्पेस ऑपरेशंस U+FEFF को व्हाइटस्पेस के रूप में मान सकते हैं जब व्हाइटस्पेस कॉल `trim` को इग्नोर करता है, लेकिन यह आलेख इसे फ़ाइल डिकोडिंग व्यवहार में सामान्यीकृत नहीं करता है। एडिटर को तार प्राप्त होते हैं; यह फ़ाइल बाइट्स या रिपोर्ट एन्कोडिंग नहीं पढ़ता है। जब बाइट-स्तरीय उत्पत्ति मायने रखती है तो वास्तविक चरित्र का निरीक्षण करें।
व्यावहारिक उदाहरण: तीन कारणों को अलग-अलग बताना - एक निर्णय पथ देता है: पहली-पंक्ति-केवल अंतर BOM को इंगित करता है, प्रत्येक पंक्ति अंत को इंगित करती है, बिखरी हुई रेखाएं अनुगामी स्थानों को इंगित करती हैं
पहले `alpha beta` और `alpha beta` की तुलना करें: नतीजा एक जैसा है। फिर `alpha beta` और `alpha beta` की तुलना करें: सामान्य मोड रिप्लेसमेंट रो दिखाता है, जबकि व्हाइटस्पेस मोड उन्हें एक जैसा मानता है। अंत में एक तरफ़ के alpha से पहले U+FEFF लगाएँ और पहली लाइन पर उसका असर देखें।
वह क्रम रिपॉजिटरी-सिद्ध संचालन का उपयोग करके कारणों को अलग करता है। यदि सामान्यीकरण समाप्त होने के बाद भी प्रत्येक पंक्ति भिन्न है, तो अकेले CRLF को दोष देने के बजाय सामग्री, इंडेंटेशन या अनुगामी वर्णों की जांच करें। यदि केवल पंक्ति एक भिन्न है, तो संपूर्ण फ़ाइल को दोबारा लिखने से पहले उसके प्रमुख कोड बिंदुओं की जाँच करें।
डायग्नोस्टिक के रूप में व्हाइटस्पेस विकल्प का उपयोग करना - दिखाता है कि कैसे ToolAcre के टेक्स्ट तुलना में इग्नोर-व्हाट्सएप को सक्षम करने से ट्रेलिंग-स्पेस और लाइन-एंडिंग शोर को अवशोषित किया जा सकता है ताकि वास्तविक संपादन सामने आ सकें
व्हाईटस्पेस को अनदेखा करना ट्रेलिंग-स्पेस शोर के लिए उपयोगी है क्योंकि यह लाइन कुंजियों को ट्रिम और संघनित करता है। यह CRLF बनाम LF को छिपाने के लिए ज़िम्मेदार नहीं है; बंटवारे के दौरान ऐसा पहले ही हो चुका है। उन चरणों को अलग रखने से यह भ्रामक निष्कर्ष नहीं निकलता है कि किस विकल्प ने तुलना में सुधार किया है।
दोनों दृश्य चलाएँ क्योंकि ट्रिमिंग सार्थक इंडेंटेशन को छिपा सकती है और संघनक निश्चित-चौड़ाई मान या स्ट्रिंग अक्षर को बदल सकता है। एक शांत सामान्यीकृत परिणाम कहता है कि चाबियाँ उस परिवर्तन के तहत मेल खाती हैं। यह प्रमाणित नहीं करता है कि मूल फ़ाइलें बाइट-समान या शब्दार्थ रूप से विनिमेय हैं।
व्हाइटस्पेस मोड पिछली जगहों का निदान करता है, जबकि लाइन अंत पहले से ही सामान्यीकृत हैं
टेक्स्ट अंतर फ़ाइलों को परिवर्तित नहीं करता है, Git को कॉन्फ़िगर नहीं करता है, एडिटर सेटिंग्स को नहीं बदलता है या हेक्साडेसिमल बाइट्स को उजागर नहीं करता है। यह चिपकाई गई स्ट्रिंग्स को स्वीकार करता है और लाइन संचालन की रिपोर्ट करता है। `.gitattributes`, `core.autocrlf` या एन्कोडिंग मरम्मत के बारे में सलाह उन टूलों से संबंधित है जिनके व्यवहार को अलग से सत्यापित किया जा सकता है।
टूल यह भी भेद नहीं कर सकता कि कोई अदृश्य पात्र पाठ में कैसे प्रवेश कर गया। एक फ़ॉर्मेटर, क्लिपबोर्ड, डिकोडर या मैन्युअल संपादन समान स्ट्रिंग उत्पन्न कर सकता है। पंक्ति का पता लगाने के लिए तुलना का उपयोग करें, फिर कारण बताने से पहले स्रोत पाइपलाइन का निरीक्षण करें।
टेकअवे: लेखक को दोष देने से पहले अदृश्य चीजों की जांच करें - निदान पथ का सारांश देता है और तुलना को आपके ब्राउज़र में नोट करता है, ताकि संवेदनशील फ़ाइलें आपकी मशीन पर बनी रहें
अदृश्यों को एक निश्चित क्रम में जांचें: अंत, अनुगामी या आंतरिक रिक्त स्थान, फिर अग्रणी विशेष वर्ण। ToolAcre के परीक्षण पहली कैटेगरी के लिए एक ठोस परिणाम देते हैं और इसके विकल्प दूसरी कैटेगरी को अलग करने में मदद करते हैं। तीसरे को इस मार्ग के बाहर एक चरित्र निरीक्षक की आवश्यकता हो सकती है।
ब्राउज़र-साइड लाइन विभाजन डिज़ाइन द्वारा क्रॉस-प्लेटफ़ॉर्म समाप्ति अंतर को गायब कर देता है। यह सुविधाजनक है, लेकिन इसका मतलब यह भी है कि यह टूल यह साबित नहीं कर सकता कि दो स्रोत फ़ाइलें समान भौतिक न्यूलाइन बाइट्स का उपयोग करती हैं। जब सटीक तार या रिपॉजिटरी प्रतिनिधित्व को संरक्षित करना आवश्यक हो तो बाइट-अवेयर उपयोगिता चुनें।