Hex decode करें

स्पेस, विसर्ग, अल्पविराम, पंक्ति-विच्छेद और `0x` उपसर्ग पढ़ने से पहले हटा दिए जाते हैं। आप जो चिपकाते हैं वह किसी नेटवर्क कैप्चर से, OpenSSL के किसी नतीजे से या C में किसी array की परिभाषा से आ सकता है, बिना आपको पहले कुछ साफ़ किए।

जो बेमानी नहीं है वह बचे हुए अंकों की संख्या है: उसे सम होना चाहिए, क्योंकि एक बाइट दो अंक है। विषम लंबाई कोई ऐसी किनारे की हालत नहीं जिसे चुपचाप एक शून्य से भर देना चाहिए — उसका मतलब है कि कॉपी करते समय कुछ खो गया, और इसीलिए बता दिया जाता है।

बाइट का कोई क्रम उतनी ही आसानी से PNG, PDF या ZIP हो सकता है जितनी आसानी से कोई वाक्य। PNG `89 50 4e 47` से शुरू होता है, PDF `25 50 44 46` से, ZIP `50 4b` से। उस डेटा को UTF-8 की तरह पढ़ने पर प्रतिस्थापन-चिह्न निकलते हैं, या तकनीकी रूप से वैध कोई ऐसा क्रम जिसका कोई मतलब नहीं।

नतीजे जैसी कोई चीज़ लौटाने के बजाय यहाँ कहा जाता है कि बाइट टेक्स्ट नहीं हैं और वे कितनी हैं। यही काम का जवाब है: यह उस encoding-त्रुटि की तलाश बंद कर देता है जो है ही नहीं, और ध्यान वहाँ ले जाता है जहाँ जाना चाहिए, यानी इस पर कि यह डेटा असल में किस क़िस्म का है।

UTF-8 का ढाँचा थोड़े अभ्यास से पढ़ा जाने लगता है। `80` से नीचे की बाइट ASCII हैं, हर एक एक अक्षर। `c2` से `df` के बीच की बाइट दो का क्रम खोलती है, `e0` से `ef` के बीच वाली तीन का, `f0` से `f4` के बीच वाली चार का, और सारी अनुवर्ती बाइट `80` से `bf` के बीच होती हैं।

इससे एक बहुत काम का नियम निकलता है: किसी dump के बीच में दिखने वाला `e0 a4` या `e0 a5` लगभग निश्चित रूप से देवनागरी है, क्योंकि पूरा देवनागरी खंड इन्हीं दो शुरुआतों से तीन-तीन बाइट में लिखा जाता है — `e0 a4 95` «क» है, `e0 a4 a8` «न» है और `e0 a5 a4` वाक्य के अंत का दंड है। जिसे किसी लॉग में हिंदी की जगह `e0 a4` दिखे उसे इससे पता चल जाता है कि बाइट ठीक हैं और समस्या दिखाने में है।

अगर क्रम `ef bb bf` से शुरू होता है तो वहाँ UTF-8 का BOM है। वह अदृश्य है, सामग्री का हिस्सा है, और यही वजह है कि Excel से निर्यात हुई किसी CSV के पहले कॉलम का नाम कभी-कभी कोई भी पढ़ने वाला कार्यक्रम नहीं पहचानता।

वही निशान दूसरी encoding में `fe ff` या `ff fe` हो सकता है — तब बात UTF-16 की है, UTF-8 की नहीं, और वे बाइट यहाँ टेक्स्ट की तरह पढ़ी नहीं जा सकतीं। शुरुआत में `ff fe` और उसके बाद अक्षरों के बीच शून्य पुराने Windows Notepad की फ़ाइल का चिरपरिचित हस्ताक्षर है।

अगर dump में हर पढ़ने लायक़ बाइट के बीच `00` दिखे, तो encoding UTF-16 है, UTF-8 नहीं। `48 00 61 00` UTF-16 में «Ha» है, कम महत्व वाली बाइट पहले — वही अक्षर, दूसरी encoding, और UTF-8 की तरह पढ़ने पर बीच-बीच में नियंत्रण-अक्षरों वाला टेक्स्ट।

यह Windows की registry के निर्यात में, SQL Server के कुछ फ़ील्ड में और उस हर चीज़ में मिलता है जो Windows API के Unicode रूप से गुज़री हो। बाइट दिख जाने के बाद इसे पहचानना आसान है — और उस औज़ार के मुक़ाबले इस पन्ने की असली उपयोगिता यही है जो सिर्फ़ एक जवाब उगल देता है।

भारतीय डेटा में एक ख़ास हालत है जिसका ऊपर वाला कोई नियम पकड़ नहीं पाता: वह टेक्स्ट जो Kruti Dev, Chanakya या उसी परिवार के किसी फ़ॉन्ट में टाइप हुआ है। उसकी बाइट पूरी तरह ASCII दायरे में होती हैं, इसलिए dump साफ़-सुथरा दिखता है और decode होकर बेतरतीब रोमन अक्षर देता है — भले मूल दस्तावेज़ स्क्रीन पर हिंदी दिखता हो।

पहचान का नियम सीधा है: अगर सामग्री हिंदी होनी चाहिए और dump में एक भी `e0 a4` या `e0 a5` नहीं है, तो वह Unicode हिंदी है ही नहीं। सुधार encoding बदलने से नहीं होता बल्कि एक असली रूपांतरण से, क्योंकि उन बाइट में देवनागरी की कोई जानकारी है ही नहीं — वह अक्षरों का ऐसा नक़्शा है जो सिर्फ़ उस एक फ़ॉन्ट के भीतर अर्थ रखता है।

बाइट का कोई भी क्रम Latin-1 की तरह पढ़ा जा सकता है, क्योंकि वहाँ 256 में से हर बाइट एक अक्षर है। जो decoder अवैध UTF-8 के सामने चुपचाप उस पर लौट जाए वह हमेशा कुछ न कुछ लौटाता है — और वह कुछ binary डेटा के साथ कचरा होता है और ग़लत पढ़े गए UTF-8 के साथ अजीब अक्षरों की वह मशहूर खिचड़ी।

ऐसे चक्कर एक पहचानने लायक़ त्रुटि को एक भरोसे लायक़ नतीजे में बदल देते हैं, जो दोनों गुणों में बुरा है। यहाँ कोई चुपचाप दूसरी encoding नहीं आज़माई जाती: या तो यह वैध UTF-8 है, या आपको पता चल जाता है कि नहीं है और आप ख़ुद तय करते हैं कि इसका क्या मतलब है।

एक आम वजह दो प्रमाणपत्र-fingerprint या दो checksum की तुलना है, जिनमें एक विसर्ग के साथ और बड़े अक्षरों में लिखी है और दूसरी उनके बिना और छोटे अक्षरों में। बाइट एक जैसी हैं, स्ट्रिंग नहीं, और इसलिए टेक्स्ट की तुलना अंतर बता देती है।

जो दोनों को इस खाने से गुज़ार देता है उसे तुरंत दिख जाता है कि बाइट वही हैं या नहीं। अगर वही हैं तो समस्या रूप की थी; अगर नहीं, तो वे सचमुच अलग हैं, और तब अगला सवाल सुरक्षा का है, सजावट का नहीं।

फ़ाइल के रूप में कोई निर्गम नहीं है। अगर बाइट कोई PNG हैं तो इस पन्ने के पास उसे डाउनलोड के रूप में देने भर की जानकारी होती — और वह ऐसा नहीं करता, क्योंकि वह दूसरा काम है और ऐसा काम है जिसमें यह जानना ज़रूरी है कि आप क्या कर रहे हैं। किसी और के दिए dump से कोई चलने वाली फ़ाइल बना देना ऐसा इशारा नहीं जो कोई टेक्स्ट का औज़ार चलते-चलते पेश करे।

Encoding की अपने-आप पहचान भी नहीं है। छोटे इनपुट पर वह अविश्वसनीय होती और ठीक तब ग़लत होती जब मायने रखता। इसके बजाय यह पन्ना आपको बताता है कि यह UTF-8 नहीं है — और फिर यह क्या है, इसका फ़ैसला आपके पास किसी अनुमान-नियम से बेहतर ढंग से है।

किसी लॉग या किसी नेटवर्क कैप्चर के hex dump में अक्सर वही होता है जो भेजा जा रहा था: क्रेडेंशियल, session की कुंजियाँ, नामों वाला काम का डेटा। चूँकि यहाँ decoding पन्ने पर ही होती है, वह सामग्री हम तक नहीं पहुँचती और उस पर कोई प्रोसेसिंग की भूमिका नहीं बनती।

इस क़िस्म के मान के साथ यही निर्णायक बिंदु है। कैप्चर परिभाषा से ही ऐसी चीज़ है जिसे कोई दोबारा बाहर नहीं भेजना चाहता, और जो औज़ार उसे किसी पराए सर्वर पर decode करता है वह उसे देख चुका होता है। नेटवर्क पैनल दिखा देता है कि यहाँ से कुछ नहीं निकलता।