Hex encode करें

Hexadecimal बाइट लिखने का एक तरीक़ा है, और एक बाइट के ठीक 256 संभव मान हैं, यानी दो hexadecimal अंक। इसीलिए नतीजे में अंकों की संख्या हमेशा सम होती है — विषम लंबाई पक्का संकेत है कि रास्ते में कुछ खो गया।

दूसरी ओर अक्षर ज़रूरी नहीं कि एक बाइट हो। `a` एक है, देवनागरी का हर अक्षर और हर मात्रा तीन है, कोई चीनी अक्षर तीन और कोई emoji चार। जिसे किसी टेक्स्ट की बाइट में लंबाई जाननी है वह उसे यहाँ सीधे देख लेता है, और हिंदी में वह उस अक्षर-गिनती से लगभग तीन गुनी निकलती है जिससे किसी फ़ील्ड की सीमा तय की गई थी।

टेक्स्ट अक्षरों का क्रम है; वह बाइट में सिर्फ़ किसी encoding के ज़रिये बदलता है। इसलिए «इस टेक्स्ट की बाइट क्या हैं» वाला सवाल तब तक अधूरा है जब तक यह न कहा जाए कि कौन-सी encoding। यहाँ UTF-8 है, क्योंकि वेब, Linux, macOS, JSON और व्यावहारिक रूप से हर आधुनिक प्रोटोकॉल उसी पर टिका है।

जहाँ बीच में कुछ और हो — ISCII जैसी भारतीय आठ-बिट encoding, या Kruti Dev जैसी फ़ॉन्ट-आधारित सामग्री — वहाँ बाइट अलग होती हैं, और वे ठीक ASCII से ऊपर वाले अक्षरों पर अलग होती हैं। «क» UTF-8 में `e0 a4 95` है; Kruti Dev वाले टेक्स्ट में वही अक्षर एक अकेली ASCII बाइट होता। अगर आपके मान नहीं मिल रहे, तो सबसे पहले यहीं देखिए।

पूरा देवनागरी खंड U+0900 से U+097F तक है, और UTF-8 में वह पूरा दायरा तीन बाइट में लिखा जाता है जिनकी शुरुआत `e0 a4` या `e0 a5` से होती है। इसलिए किसी dump में `e0 a4` की बार-बार वापसी अपने आप में जवाब है: वह हिंदी टेक्स्ट है, कुछ और नहीं।

ब्योरे में: U+0900 से U+093F तक `e0 a4` से शुरू होते हैं और U+0940 से U+097F तक `e0 a5` से। «क» `e0 a4 95` है, «न» `e0 a4 a8` है, और वाक्य के अंत का दंड `e0 a5 a4` है। यह उतना ही काम का नियम है जितना किसी और भाषा में उसका अपना — किसी लॉग में `e0 a4` दिखते ही आपको पता है कि बाइट सही हैं और गड़बड़ दिखाने में है।

बाइट के बीच विसर्ग वह रूप है जिसमें OpenSSL प्रमाणपत्रों की fingerprint छापता है और जिसमें MAC पते पढ़े जाते हैं। स्पेस किसी hex dump का रूप है, जैसा `xxd` या कोई नेटवर्क कैप्चर दिखाता है। बिना विभाजक वाला रूप वह है जो किसी डेटाबेस फ़ील्ड में, किसी कॉन्फ़िग पंक्ति में या किसी hash की तुलना में जाता है।

व्यवहार में चुनाव इस पर निर्भर है कि मान कहाँ जा रहा है, इस पर नहीं कि क्या ज़्यादा अच्छा दिखता है। दो fingerprint की तुलना हैरतअंगेज़ ढंग से अक्सर सिर्फ़ इसलिए विफल होती है कि एक विसर्ग के साथ लिखी है और दूसरी उनके बिना — बाइट वही हैं, स्ट्रिंग नहीं।

बाइट के मान के लिए अंकों का रूप बेमानी है: `ff` और `FF` एक ही संख्या है। टेक्स्ट की तुलना के लिए यह सब कुछ बदल देता है, इसलिए यह सवाल उसी क्षण सजावटी नहीं रह जाता जब मान की तुलना हो, उस पर hash निकले या उसे किसी key की तरह इस्तेमाल किया जाए।

परिपाटियाँ एक जैसी नहीं हैं: Unix के औज़ार और अधिकतर लाइब्रेरियाँ छोटे अक्षरों में लिखती हैं, Windows वाले और प्रमाणपत्र दिखाने वाली बहुत सी खिड़कियाँ बड़े अक्षरों में, और MAC पते निर्माता के हिसाब से दोनों तरह। जो तुलना करता है वह पहले सामान्य करता है; और जो हस्ताक्षर निकालता है उसे जानना होगा कि विनिर्देश कौन-सा रूप माँगता है, वरना hash दूसरा निकलेगा।

किसी टेक्स्ट को hexadecimal में देखने की सबसे आम गंभीर वजह वह तुलना है जो विफल हो रही है जबकि दोनों मान एक जैसे दिखते हैं। बाइट वाली दृष्टि में वह तुरंत दिख जाता है जो स्क्रीन छिपा लेती है: किसी कड़े स्पेस का `c2 a0`, Windows की पंक्ति के `0a` से पहले पड़ा `0d`, या किसी स्पेस की जगह tab का `09`।

हिंदी में इसमें दो और जुड़ जाते हैं जो और भी चुपचाप काम करते हैं: zero-width non-joiner `e2 80 8c` और zero-width joiner `e2 80 8d`। ये संयुक्ताक्षर के जुड़ने-न-जुड़ने को तय करते हैं, कुछ दिखाते नहीं, और हिंदी टाइपिंग तथा सामग्री-प्रबंधन तंत्रों से आने वाले टेक्स्ट में आम हैं। दो नाम जो पढ़ने में एक जैसे हैं, इन्हीं की वजह से बराबर नहीं निकलते।

Windows पंक्ति `0d 0a` से ख़त्म करता है, Unix और macOS `0a` से। स्क्रीन पर दोनों एक जैसे दिखते हैं; बाइट में नहीं — और इसीलिए दो «एक जैसी» फ़ाइलों के checksum अलग निकलते हैं, version तंत्र उन पंक्तियों में बदलाव दिखाते हैं जिन्हें छुआ नहीं गया, और वह तुलना विफल होती है जिसे मामूली माना जा रहा था।

इस पन्ने पर यह सीधे दिखता है: पंक्ति-विच्छेद वाला टेक्स्ट चिपकाइए और देखिए कि `0a` से पहले `0d` है या नहीं। यह सबसे तेज़ तरीक़ा है यह तय करने का कि शृंखला के किसी औज़ार ने पंक्ति के अंत दोबारा लिखे हैं या नहीं — जो Git सेटिंग के हिसाब से खुलेआम करता है।

दोनों बाइट को छापने लायक़ टेक्स्ट के रूप में लिखते हैं, और इनके बीच चुनना पठनीयता और आकार के बीच चुनना है। Hexadecimal को हर बाइट के लिए दो अक्षर चाहिए, यानी दोगुनी जगह; Base64 को कच्चे डेटा से लगभग एक-तिहाई ज़्यादा चाहिए और वह इसलिए काफ़ी किफ़ायती है।

बदले में hexadecimal पढ़ा जाता है। किसी तय जगह की तय बाइट देखी जा सकती है, दो मान अगल-बग़ल रखकर पहला फ़र्क़ ढूँढ़ा जा सकता है, और बाइट की सीमाएँ दिखती हैं। Base64 में इनमें से कुछ नहीं चलता, क्योंकि वहाँ तीन बाइट चार अक्षरों में घुल जाती हैं। इसीलिए hash और fingerprint में hexadecimal चलन में है और काम के डेटा में Base64।

`0x` उपसर्ग प्रोग्रामिंग भाषाओं की परिपाटी है और compiler को बताता है कि आगे के अंक hexadecimal में पढ़े जाएँ। वह कोड में किसी अकेली संख्या के आगे लगता है, किसी क्रम की हर बाइट के आगे नहीं: `0x48 0x61` दो संख्याओं की सूची है, `4861` दो बाइट हैं।

इसीलिए यहाँ उपसर्ग नहीं बनाया जाता। उलटी दिशा ज़्यादा उदार है: इस साइट का decoder हर बाइट के आगे `0x` क़बूल करता है, क्योंकि स्रोत-कोड से कॉपी की गई ऐसी सूचियाँ सचमुच आती हैं। बनाना और क़बूल करना अलग हो सकते हैं, और यहाँ वे जान-बूझकर अलग हैं।

इस खाने में आम तौर पर वही मान आता है जिसे कोई हिलाना नहीं चाहता: किसी रिकॉर्ड का ऐसा फ़ील्ड जो अजीब बर्ताव कर रहा है, कोई कुंजी, कोई पासवर्ड-उम्मीदवार जिसे किसी checksum से मिलाना है। चूँकि रूपांतरण पन्ने पर ही होता है, वह हम तक नहीं पहुँचता।

यह नेटवर्क पैनल में जाँचा जा सकता है: इस्तेमाल के दौरान ऐसी कोई रिक्वेस्ट नहीं निकलती जो आपका इनपुट ले जाए। जो बचता है वह निजता पन्ने पर लिखा है — आपका आना और विज्ञापन तथा आँकड़ों की रिक्वेस्ट। खाने की सामग्री उनमें नहीं है, और इस क़िस्म के मान के साथ यही एक बात गिनी जाती है।