हिन्दी

डेवलपर टूल · SHA हैश कैलकुलेटर

हेक्स, Base64 और रॉ बाइट्स: समान लिखने के तीन तरीके SHA डाइजेस्ट

· यह काम किस प्रकार करता है

शा-256 Base64 एन्कोडिंग फ़ाइल स्वरूपों

एक 32-बाइट डाइजेस्ट को 64 हेक्स वर्णों, 44 Base64 वर्णों के साथ पैडिंग, Base64url और कच्चे बाइट्स के साथ चिह्नित बाइट सीमाओं के रूप में दिखाया गया है।
मूल ToolAcre वेक्टर चित्रण

sha256sum हेक्स प्रिंट करता है, package-lock.json Base64 को स्टोर करता है और Docker sha256: उपसर्ग का उपयोग करता है। वे सभी एक जैसे हो सकते हैं 32 bytes। यह पोस्ट प्रत्येक प्रतिनिधित्व और उनके बीच रूपांतरण कैसे करें, इसकी व्याख्या करती है।

हैश जो अलग दिखते हैं लेकिन सहमत होते हैं - एक लॉकफ़ाइल स्ट्रिंग और एक ही फ़ाइल के लिए एक टर्मिनल चेकसम

एक SHA-256 डाइजेस्ट मूलतः 32 bytes है। आप उन बाइट्स को कैसे लिखते हैं यह निर्धारित करता है कि डाइजेस्ट कैसा दिखता है। एक डाइजेस्ट, 32 समान बाइट्स, 64 हेक्साडेसिमल वर्ण (दो प्रति बाइट), या 44 Base64 वर्ण (लगभग चार प्रति तीन बाइट्स), या एन्कोडिंग के आधार पर अलग-अलग लंबाई और प्रारूप के रूप में दिखाई देता है। भ्रम इसलिए पैदा होता है क्योंकि एक लॉकफ़ाइल एक प्रतिनिधित्व दिखा सकता है और एक टर्मिनल दूसरा दिखा सकता है, दोनों समान अंतर्निहित 32 bytes के लिए।

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

एक डाइजेस्ट बाइट्स है - 20, 32, 48 या 64 जो किसी भी टेक्स्ट एन्कोडिंग से पहले एल्गोरिदम पर निर्भर करता है।

किसी भी पाठ्य प्रतिनिधित्व के अस्तित्व में आने से पहले, परिणाम डाइजेस्ट बाइट्स का एक ArrayBuffer होता है। ToolAcre उस बफ़र को Uint8Array के साथ लपेटता है, फिर या तो प्रत्येक बाइट को दो हेक्साडेसिमल अंकों के रूप में लिखता है या btoa को कॉल करने से पहले प्रत्येक बाइट को बाइनरी कैरेक्टर में परिवर्तित करता है। न तो फ़ॉर्मेटर हैश को दोबारा चलाता है, और न ही एक भी डाइजेस्ट बिट बदलता है।

बाइट की चौड़ाई इस टूल में चयनित एल्गोरिदम का अनुसरण करती है: SHA-1 बीस बाइट्स लौटाता है, SHA-256 बत्तीस, SHA-384 अड़तालीस और SHA-512 चौसठ बाइट्स देता है। वे एल्गोरिदम मेटाडेटा और परीक्षणों द्वारा सत्यापित समर्थित आउटपुट हैं। प्रोग्रामेटिक तुलना के लिए रॉ बाइट्स उपयुक्त हैं; हेक्स और Base64 उन चैनलों के लिए ट्रांसपोर्ट नोटेशन हैं जो टेक्स्ट की अपेक्षा करते हैं।

हेक्स - प्रति बाइट दो अक्षर, यह कमांड-लाइन टूल पर हावी क्यों है, और केस प्रश्न

हेक्साडेसिमल प्रतिनिधित्व 4-बिट निबल के 16 संभावित मानों का प्रतिनिधित्व करने के लिए अंकों 0-9 और अक्षरों A-F (या a-f) का उपयोग करता है। दो हेक्स अंक एक बाइट का प्रतिनिधित्व करते हैं। इनपुट एबीसी का SHA-256 डाइजेस्ट 32 bytes है, इसलिए यह 64 हेक्स वर्णों के रूप में प्रदर्शित होता है: ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad। यह वह प्रारूप है जिसे अधिकांश कमांड-लाइन टूल प्रिंट करते हैं। हेक्साडेसिमल मानव-पठनीय और स्पष्ट है; प्रत्येक बाइट को हर बार बिल्कुल समान दो वर्णों द्वारा दर्शाया जाता है।

हेक्साडेसिमल दस्तावेज़ीकरण और कमांड लाइन पर चेकसम और हैश के लिए डिफ़ॉल्ट प्रारूप है। इसे पढ़ना और कॉपी करना आसान है, और इसमें कोई पैडिंग नहीं है, व्याख्या में कोई केस संवेदनशीलता नहीं है (हालांकि परंपरा लगातार लोअरकेस या अपरकेस तय करती है), और कोई विशेष वर्ण नहीं है जिसे URL या JSON में भागने की आवश्यकता है। नकारात्मक पक्ष यह है कि इसमें कच्चे बाइट्स की तुलना में दोगुने अक्षर लगते हैं, यही कारण है कि अन्य प्रारूप मौजूद हैं।

Base64 और Base64url - प्रति तीन बाइट्स में लगभग चार अक्षर, पैडिंग, और जहां प्रत्येक दिखाई देता है (SRI, npm, SSH फ़िंगरप्रिंट)

Base64 तीन बाइट्स को 64-वर्ण वर्णमाला से लिए गए चार वर्णों के रूप में एनकोड करता है: A-Z, a-z, 0-9, +, /. तीन बाइट्स 61 62 63 (द abc के लिए ASCII कोड) Base64 में YWJj के रूप में एन्कोड करते हैं। एक पूर्ण 32-बाइट SHA-256 डाइजेस्ट लगभग 44 Base64 वर्णों के रूप में एन्कोड होता है। = वर्णों के साथ पैडिंग आउटपुट लंबाई को 4 के गुणक में लाती है, इसलिए 44 वर्ण प्लस 0 पैडिंग (क्योंकि 32 3 का गुणज है, किसी पैडिंग की आवश्यकता नहीं है)। डिकोडिंग प्रक्रिया को उलट देती है: चार Base64 अक्षर तीन बाइट्स में डिकोड हो जाते हैं।

Base64 package-lock.json फ़ाइलों, npm श्रिंकवैप, SRI (सबरेसोर्स इंटीग्रिटी) विशेषताओं में HTML और SSH कुंजी फ़िंगरप्रिंट में दिखाई देता है। यह कॉम्पैक्ट है - कच्चे बाइट्स की तुलना में लगभग 33% लंबा, जबकि हेक्साडेसिमल का 100% लंबा है। समस्या यह है कि सभी पाठ प्रस्तुतियों को पढ़ना समान रूप से आसान नहीं है; Base64 हेक्स की तुलना में मानव आँख को अधिक उलझा हुआ दिखता है।

उपसर्ग प्रपत्र - sha256: कंटेनर डाइजेस्ट में, sha384- अखंडता विशेषताओं में, SHA256: SSH में

Base64url RFC 4648 में परिभाषित एक प्रकार है जो + और /. के लिए - और _ को प्रतिस्थापित करता है, वर्णमाला A-Z, a-z, 0-9, -, _ बन जाती है। JWTs Base64url का उपयोग करते हैं क्योंकि + और / के URL में विशेष अर्थ होते हैं (+ को क्वेरी स्ट्रिंग्स में एक स्थान के रूप में पढ़ा जा सकता है, / एक पथ विभाजक है)। एक JWT खंड हमेशा Base64url-एन्कोडेड होता है, और एक डिकोडर जो मानक Base64 पर जोर देता है वह इसे अस्वीकार कर देगा। इसके विपरीत, एक Base64url डिकोडर जो मानक वर्णमाला को स्वीकार नहीं करता है वह मानक Base64 पर विफल हो जाएगा।

Base64url में पैडिंग वैकल्पिक है। यह सुनिश्चित करने के लिए कि आउटपुट लंबाई 4 का गुणज है, = के साथ मानक Base64 पैड। Base64url आमतौर पर पैडिंग को छोड़ देता है क्योंकि = स्वयं URL-अजीब है। एक डिकोडर को Base64url को पैडिंग के साथ या उसके बिना स्वीकार करना चाहिए, और एनकोडर को स्पष्ट होना चाहिए कि वह क्या उत्पन्न करता है। ToolAcre Base64 टूल दोनों अक्षरों को स्वीकार करता है और इनपुट पर गायब पैडिंग को सहन करता है, और आपको आउटपुट पर प्रारूप चुनने देता है।

कार्यान्वित उदाहरण - एक डाइजेस्ट को हेक्स से Base64 और पीछे में परिवर्तित किया गया, जिसमें बाइट सीमाएँ चिह्नित थीं

उपसर्ग प्रपत्र डाइजेस्ट में एक योजना पहचानकर्ता जोड़ते हैं। Docker छवि डाइजेस्ट sha256:ba7816bf... का उपयोग करती है, जहां sha256: उपसर्ग है। SSH फ़िंगरप्रिंट कोलन के साथ SHA256: का उपयोग करते हैं। कुछ टूल sha256= या SHA256= (बराबर चिह्न के साथ) का उपयोग करते हैं। उपसर्ग विशुद्ध रूप से सूचनात्मक है; यह आपको बताता है कि किस एल्गोरिदम ने डाइजेस्ट तैयार किया है। उपसर्ग को हटाने से समान बाइट्स समान एन्कोडिंग में रह जाती हैं।

डाइजेस्ट की तुलना करते समय, उपसर्ग शोर है। यदि एक टूल SHA256:ba78... प्रिंट करता है और दूसरा ba78... प्रिंट करता है, तो वे एक ही डाइजेस्ट हैं; उपसर्ग केवल प्रारूप के बारे में मेटाडेटा है। इसी तरह, sha256:- (कुछ कंटेनर संदर्भों में प्रयुक्त) या sha384- (अखंडता विशेषताओं में प्रयुक्त) जैसे उपसर्ग स्वरूपण सम्मेलन हैं जो बाइट्स को नहीं बदलते हैं। तुलना के लिए उन्हें अलग करें.

इसमें क्या शामिल नहीं है - किसी दिए गए टूल से कौन सा एन्कोडिंग उत्सर्जित होता है; तुलना करने से पहले आउटपुट स्वरूप की जाँच करें

एक डाइजेस्ट, इनपुट एबीसी का SHA-256, कई रूपों में दिखाई देता है: हेक्स (64 वर्ण), पैडिंग के साथ Base64 (44 वर्ण), पैडिंग के साथ Base64url (44 वर्ण, + के बजाय - और _ और /), या विभिन्न उपसर्गों के साथ। यह पुष्टि करने के लिए कि वे समान हैं, डीकोड करें प्रत्येक बाइट्स पर वापस जाएं और बाइट्स की तुलना करें। हेक्स प्रतिनिधित्व ba7816bf... बाइट्स को डिकोड करता है 0xba 0x78 0x16 0xbf 0x8f 0x01 0xcf 0xea ... डिकोड होने पर Base64 प्रतिनिधित्व उसी बाइट अनुक्रम में परिवर्तित हो जाता है।

ToolAcre SHA हैश कैलकुलेटर डिफ़ॉल्ट रूप से हेक्साडेसिमल में आउटपुट करता है। यदि आपको Base64 की आवश्यकता है, तो आप हेक्स को Base64 में बदलने के लिए एक अलग टूल का उपयोग कर सकते हैं, या टेक्स्ट को सीधे एनकोड करने के लिए उसी साइट पर Base64 उपयोगिता का उपयोग कर सकते हैं। विशिष्ट संदर्भों के लिए डिज़ाइन किए गए टूल (package-lock.json के लिए npm, इमेज डाइजेस्ट के लिए Docker) उनके संदर्भ द्वारा अपेक्षित प्रारूप में आउटपुट करते हैं। यह समझना कि ये सभी अलग-अलग कपड़ों में एक ही 32 bytes हैं, जब टूल प्रारूप पर असहमत होते हैं तो भ्रम दूर हो जाता है।

टेकअवे: बाइट्स की तुलना करें, स्ट्रिंग्स की नहीं - ToolAcre SHA हैश कैलकुलेटर के साथ डाइजेस्ट की गणना करें, फिर उस प्रतिनिधित्व में कन्वर्ट करें जिसके विरुद्ध आप जाँच कर रहे हैं

हेक्स डाइजेस्ट को मैन्युअल रूप से Base64 में बदलने के लिए, हेक्स अंकों को बाइट्स में समूहित करें, प्रत्येक बाइट को दशमलव में बदलें, फिर Base64 वर्णमाला का उपयोग करके एनकोड करें। बाइट 0xba (हेक्स बा) दशमलव 186 है; 0x78 120 है; 0x16 22 है; 0xbf 191 है। इन चार बाइट्स को समूहीकृत करने और Base64 के रूप में एन्कोड करने से वर्णमाला में w (0 + 22) अक्षर मिलते हैं, जैसे (एनकोडिंग 186), AA (एनकोडिंग 120), vw (एनकोडिंग 191)। पूर्ण डाइजेस्ट के लिए इसे 10 बार करना और यदि आवश्यक हो तो पैडिंग करना आवश्यक है। यह मैन्युअल प्रक्रिया शिक्षाप्रद लेकिन थकाऊ है; Base64 कन्वर्टर टूल इसे तुरंत बनाता है।

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