डेवलपर टूल · SHA हैश कैलकुलेटर
समान पाठ, भिन्न SHA-256: न्यूलाइन्स, एन्कोडिंग और छिपे हुए बाइट्स
· यह काम किस प्रकार करता है
शा-256 एन्कोडिंग पाठ प्रसंस्करण डिबगिंग
कमांड लाइन एक बात कहती है और ब्राउज़र एक ही पाठ जैसा दिखने के लिए कुछ और कहता है। अनुवर्ती नई पंक्तियाँ, UTF-16 और CRLF लगभग हर मामले की व्याख्या करती हैं; यह पोस्ट दिखाती है कि छिपे हुए बाइट्स को कैसे खोजा जाए।
इको एक हैश कहता है, टूल दूसरा कहता है - रोजमर्रा का बेमेल और दोनों में से कोई भी गलत क्यों नहीं है
एक टर्मिनल एक SHA-256 डाइजेस्ट की रिपोर्ट करता है और एक ब्राउज़र समान टेक्स्ट प्रतीत होने वाले दूसरे डाइजेस्ट की रिपोर्ट करता है। कमांड-लाइन टूल टूटा नहीं है, और ब्राउज़र भी नहीं टूटा है। हैश किए जा रहे बाइट्स समान नहीं हैं, भले ही दृश्यमान अक्षर समान दिखते हों। यह पोस्ट उन छिपे हुए बाइट्स के सबसे सामान्य स्रोतों का पता लगाती है और दिखाती है कि टेक्स्ट फ़ील्ड और हेक्स व्यूअर के साथ उन्हें कैसे खोजा जाए।
समस्या लगभग कभी भी SHA-256 एल्गोरिदम की ही नहीं है। SHA-256 नियतिवादी है: समान बाइट्स हमेशा एक ही डाइजेस्ट उत्पन्न करते हैं, और डाइजेस्ट सही होता है। जब आउटपुट भिन्न होते हैं, तो बाइट्स भिन्न होते हैं। भ्रम इसलिए पैदा होता है क्योंकि "समान पाठ" अस्पष्ट है: एक व्यक्ति पात्रों को देखता है, लेकिन एक हैश फ़ंक्शन बाइट्स देखता है, और उनके बीच का अनुवाद वह जगह है जहां छिपे हुए अंतर छिपते हैं।
अनुगामी नई पंक्ति - कैसे इको एक बाइट जोड़ता है और प्रिंटफ नहीं जोड़ता है, और वह डाइजेस्ट में क्या करता है
शेल में इको कमांड अपने आउटपुट में एक न्यूलाइन कैरेक्टर (U+000A, बाइट 0x0A) जोड़ता है। यह डिज़ाइन के अनुसार है: Unix में यह परंपरा कि टेक्स्ट फ़ाइलें एक नई लाइन के साथ समाप्त होती हैं, एक सरल कार्य की प्रतिध्वनि देती है। जब आप किसी टर्मिनल में echo abc टाइप करते हैं और इसे sha256sum पर पाइप करते हैं, तो पचे हुए बाइट्स होते हैं 61 62 63 0ए (द ASCII ए, बी, सी के लिए कोड और न्यूलाइन के लिए बाइट), नहीं 61 62 63. साधन ToolAcre हैश हैश बाइट्स की गणना करने के लिए उपयोग करता है 61 62 63 और एक अलग परिणाम उत्पन्न करता है।
जब तक आप फॉर्मेट स्ट्रिंग में एक नहीं लिखते, प्रिंटफ कमांड एक नई लाइन नहीं जोड़ता है। प्रिंटफ एबीसी | sha256sum अकेले बाइट्स के डाइजेस्ट 61 62 63 की गणना करता है, जो ब्राउज़र टूल से मेल खाता है। यही कारण है कि हैश की तुलना करने का मतलब अक्सर इको के बजाय प्रिंटफ चलाना, या -z ध्वज के साथ sha256sum पर पाइप करना, या आपका टूल जो भी रूप प्रदान करता है उसमें कच्चे इनपुट को निर्दिष्ट करना होता है। छुपी हुई नई लाइन ब्राउज़र टूल और कमांड-लाइन टूल के असहमत होने का सबसे आम कारण है।
UTF-8 बनाम UTF-16 - कुछ शेल और एडिटर में समान वर्ण अलग-अलग बाइट्स क्यों हैं
UTF-8 और UTF-16 समान वर्णों को अलग-अलग बाइट अनुक्रमों के रूप में एन्कोड करते हैं। वर्ण é (U+00E9, तीव्र उच्चारण वाला e) दो UTF-8 बाइट्स के रूप में एन्कोड होता है: 0xC3 0xA9। UTF-16 में, जो कि JavaScript आंतरिक रूप से स्ट्रिंग्स का प्रतिनिधित्व करता है, एक ही वर्ण एक अलग क्रम में दो बाइट्स रखता है (एंडियननेस के आधार पर) या पूरी तरह से एक अलग रूप में यदि आधार वर्ण और एक संयोजन चिह्न से बना हो। जब आप विंडोज एप्लिकेशन से कैफे कॉपी करते हैं और इसे ब्राउज़र हैश टूल में पेस्ट करते हैं, तो टूल हैश बाइट्स मैक टर्मिनल हैश से मेल नहीं खा सकते हैं, क्योंकि सिस्टम अलग-अलग एन्कोडिंग या सामान्यीकरण रूपों में डिफ़ॉल्ट होते हैं।
ToolAcre हैश टूल TextEncoder के माध्यम से हैशिंग से पहले टेक्स्ट को स्पष्ट रूप से UTF-8 में परिवर्तित करता है। यह वही एन्कोडिंग है जिसका उपयोग Unix कमांड-लाइन डिफ़ॉल्ट रूप से करती है। ऐप्स/dev/src/lib/base64.js में स्रोत कोड textToBytes फ़ंक्शन को नए TextEncoder().encode() को कॉल करते हुए दिखाता है, जो UTF-8 की गारंटी देता है। यदि कोई अन्य सिस्टम UTF-16 या लैटिन-1 या किसी अन्य एन्कोडिंग का उपयोग कर रहा है, तो उत्पादित बाइट्स भिन्न होंगे। टूल डाइजेस्ट के साथ-साथ बाइट गिनती प्रदर्शित करता है, यही कारण है कि कैफे पेस्ट करने और कमांड-लाइन हैश के साथ तुलना करने पर एन्कोडिंग भिन्न होने पर अलग-अलग बाइट गिनती दिखाई देगी।
CRLF, BOM और सामान्यीकरण - पंक्ति अंत, बाइट-ऑर्डर चिह्न और अदृश्य इनपुट अंतर के रूप में निर्मित बनाम विघटित उच्चारण
CRLF (कैरिज रिटर्न + लाइन फ़ीड, बाइट्स 0x0D 0x0A) विंडोज़ पर लाइन एंडिंग कन्वेंशन है; LF (अकेले लाइन फ़ीड, बाइट 0x0A) Unix सम्मेलन है। एक टेक्स्ट फ़ाइल जो टेक्स्ट एडिटर में खोले जाने पर समान दिखती है, उसमें अलग-अलग पंक्ति के अंत हो सकते हैं, और वे बाइट्स हैश के इनपुट का हिस्सा हैं। विंडोज़ पर संपादित की गई फ़ाइल और Unix सिस्टम पर गणना की गई SHA-256 के विरुद्ध जाँच की गई फ़ाइल मेल नहीं खाएगी यदि एक सिस्टम ने लाइन एंडिंग को परिवर्तित कर दिया है और दूसरे ने नहीं किया है।
बाइट-ऑर्डर चिह्न (BOM, UTF-8 के लिए बाइट्स 0xEF 0xBB 0xBF) फ़ाइल की शुरुआत में एक वैकल्पिक अनुक्रम है जो एन्कोडिंग का संकेत देता है। कुछ एडिटर इसे जोड़ते हैं; कुछ टूल इसे छीन लेते हैं; कुछ लोग इसे नजरअंदाज कर देते हैं. यदि किसी फ़ाइल में BOM है और आप इसे बाइट-दर-बाइट हैश करते हैं, तो BOM बाइट डाइजेस्ट का हिस्सा हैं। यदि आप फिर दृश्यमान पाठ (जिसमें दर्शक BOM को छुपाता है) को एक ऐसे टूल में कॉपी करते हैं जो BOM नहीं जोड़ता है, तो डाइजेस्ट मेल नहीं खाएगा। पाठ सामान्यीकरण फॉर्म (रचित और विघटित उच्चारण के लिए NFD बनाम NFC) एक और परत जोड़ते हैं: एक ही उच्चारण अक्षर को एक एकल पूर्वनिर्मित वर्ण के रूप में या संयोजन उच्चारण के बाद आधार वर्ण के रूप में दर्शाया जा सकता है, और बाइट अनुक्रम अलग-अलग होते हैं।
कार्यान्वित उदाहरण - एक स्ट्रिंग को नई लाइन के साथ और उसके बिना, फिर दो एन्कोडिंग में, प्रत्येक बाइट अंतर के साथ हैश किया गया
निदान विधि एक: यह देखने के लिए हेक्स डंप टूल या ऑनलाइन कन्वर्टर का उपयोग करें कि आपके टूल वास्तव में किस बाइट्स पर काम कर रहे हैं। टेक्स्ट को Base64 एनकोडर में पेस्ट करें, उसे एनकोड करें, और आपके पास बाइट्स का एक टेक्स्टुअल रिकॉर्ड होगा। फिर कमांड लाइन पर Base64 को Base64 -d से डीकोड करें और हेक्स बाइट अनुक्रम देखने के लिए इसे od -A x -t x1z पर पाइप करें। यदि बाइट्स मेल खाते हैं, तो एल्गोरिदम सही है; यदि वे ऐसा नहीं करते हैं, तो अंतर दिखाई देगा।
डायग्नोस्टिक विधि दो: एकल वर्ण से शुरू करके उत्तरोत्तर लंबे इनपुट को हैश करने के लिए ToolAcre SHA हैश कैलकुलेटर का उपयोग करें। एक नई पंक्ति जोड़ें (जिसका अर्थ है टेक्स्ट बॉक्स के अंदर एंटर टाइप करना), रिक्त स्थान जोड़ें, यदि इनपुट गैर-ASCII स्रोत से आया है तो उसी टेक्स्ट को UTF-16 एस्केप अनुक्रमों के साथ जोड़ें। प्रत्येक जोड़ के साथ डाइजेस्ट परिवर्तन को देखें। डाइजेस्ट के साथ प्रदर्शित बाइट गिनती आपको बताती है कि टूल कितने बाइट हैशिंग कर रहा है, जो खोज को नाटकीय रूप से सीमित कर देता है।
आउटपुट में हेक्स केस और रिक्त स्थान - वे अंतर जो पूरी तरह से कॉस्मेटिक हैं
डाइजेस्ट का हेक्साडेसिमल प्रतिनिधित्व केस-असंवेदनशील है। अपरकेस और लोअरकेस अक्षर दोनों समान बाइट्स का प्रतिनिधित्व करते हैं: A = 10, a = 10। कुछ टूल अपरकेस उत्सर्जित करते हैं, कुछ लोअरकेस, कुछ या तो अनुमति देते हैं। यदि एक डाइजेस्ट लोअरकेस है और दूसरा अपरकेस है, तो वे एक ही डाइजेस्ट हैं। डाइजेस्ट डिस्प्ले में व्हाइटस्पेस पूरी तरह से कॉस्मेटिक है। ba78 16bf बनाम ba7816bf के रूप में प्रदर्शित डाइजेस्ट समान है; स्थान केवल एक स्वरूपण विकल्प है। केस या रिक्त स्थान के कारण उत्पन्न बेमेल वास्तविक बेमेल नहीं हैं।
बाइट स्तर पर निश्चित-चौड़ाई स्वरूपण अंतर भी अदृश्य हैं। हाइफ़न, रिक्त स्थान या कोलन (जैसे ba-78-16-bf) के साथ दिखाया गया डाइजेस्ट एक फ़ॉर्मेटिंग कन्वेंशन है जो मनुष्यों के लिए पढ़ना आसान बनाता है, वास्तविक बाइट्स में कोई बदलाव नहीं। ToolAcre टूल हमेशा बिना विभाजक के लोअरकेस उत्सर्जित करता है, जो कि अधिकांश कमांड-लाइन टूल प्रिंट का प्रारूप है। यदि आप किसी ऐसे टूल से तुलना कर रहे हैं जो अलग-अलग उत्सर्जन करता है, तो पहले उसी प्रतिनिधित्व में कन्वर्ट करें।
इसमें क्या शामिल नहीं है - हैशिंग फ़ाइलें, जहां समान सिद्धांत लागू होते हैं लेकिन बाइट्स टेक्स्ट फ़ील्ड के बजाय डिस्क से आते हैं
ToolAcre SHA हैश कैलकुलेटर हैशिंग से पहले UTF-8 रूपांतरण करता है, इनपुट बाइट गिनती प्रदर्शित करता है, और Base64 और हेक्साडेसिमल आउटपुट फॉर्म प्रदान करता है। स्रोत फ़ाइल ऐप्स/dev/src/lib/hash.js हैशटेक्स्ट फ़ंक्शन को डाइजेस्टबाइट्स को कॉल करते हुए दिखाती है, जो bytes.slice().बफर को crypto.subtle.digest तक भेजती है। उस फ़ाइल में टिप्पणियाँ स्पष्ट रूप से दस्तावेज़ करती हैं कि UTF-8 चरण जानबूझकर किया गया है और विभिन्न एन्कोडिंग के बीच अंतर पर ध्यान दें। ज्ञात वेक्टर (एबीसी हैश से ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad हेक्स में) के विरुद्ध आपके इनपुट का परीक्षण यह स्थापित करता है कि ब्राउज़र टूल सही ढंग से काम कर रहा है; कोई भी विचलन इनपुट में बाइट अंतर को इंगित करता है।
फ़ाइल हैशिंग उसी सिद्धांत का पालन करती है। फ़ाइल में बाइट्स मायने रखते हैं: जब आप एक सिस्टम से निर्यात करते हैं और दूसरे में आयात करते हैं तो लाइन-एंडिंग अंतर हर डाइजेस्ट को बदल सकता है। कुछ टूल तुलना के दौरान पंक्ति के अंत को संभालने के लिए विकल्प प्रदान करते हैं; अन्य ने फ़ाइल को वैसे ही हैश किया है। यह जानना कि क्या आपका टूल फ़ाइल को बाइनरी के रूप में हैश करता है या पहले टेक्स्ट सामान्यीकरण करता है, प्रतिलिपि प्रस्तुत करने योग्यता के लिए आवश्यक है।
टेकअवे: हैश बाइट्स, टेक्स्ट नहीं - ToolAcre SHA हैश कैलकुलेटर आपके द्वारा पेस्ट किए गए बाइट्स को हैश कर देता है, इसलिए पहले जांच लें कि आपने क्या पेस्ट किया है
तुलना और सत्यापन तभी काम करते हैं जब आपके पास समान बाइट्स हों। यह पुष्टि करके प्रारंभ करें कि आप ठीक उसी इनपुट को हैश कर रहे हैं: नई लाइन से बचने के लिए इको के बजाय इको -n (या प्रिंटफ) चलाएं, यदि आपका टूल इसकी अनुमति देता है तो UTF-8 एन्कोडिंग को स्पष्ट रूप से निर्दिष्ट करें, जांचें कि CRLF किCAडिटर या सिस्टम उपयोगिता द्वारा नहीं डाला गया है। फिर ToolAcre कैलकुलेटर और कमांड-लाइन टूल को साथ-साथ हैश करें। यदि डाइजेस्ट मेल खाता है, तो बाइट्स समान थे। यदि वे नहीं करते हैं, तो छिपे हुए अंतर को खोजने के लिए बाइट-काउंट डिस्प्ले और हेक्स डंप विधि का उपयोग करें।
एक बार जब आप समझ जाते हैं कि बाइट्स कहाँ अलग हो गए हैं, तो आप चुन सकते हैं कि तुलना के लिए उन्हें सामान्य करना है या नहीं। कुछ चेकसम फ़ाइल की अखंडता को ठीक उसी तरह सत्यापित करने के लिए होते हैं जैसे वह डिस्क पर मौजूद होती है, इस मामले में बाइट-फॉर-बाइट हैशिंग लक्ष्य है। अन्य का उद्देश्य यह सत्यापित करना है कि दृश्यमान सामग्री समान है, ऐसी स्थिति में पंक्ति के अंत और एन्कोडिंग को सामान्य करना सही है। न तो गलत है; वे विभिन्न प्रश्नों का उत्तर देते हैं। SHA-256 एल्गोरिथम हमेशा सही होता है; प्रश्न केवल यह है कि क्या आप इसे दोनों मामलों में समान इनपुट हैश करने के लिए कह रहे हैं।