डेवलपर टूल · Base64 एनकोडर और डिकोडर
क्यों चिपकाया गया Base64 डिकोड करने में विफल रहता है: लाइन रैप्स, न्यूलाइन्स और स्मार्ट कोट्स
· यह क्यों मायने रखती है
Base64 एन्कोडिंग
Base64 पारगमन में शायद ही कभी टूटता है; यह क्लिपबोर्ड में टूट जाता है. यह पोस्ट उन कॉपी-पेस्ट दोषों को सूचीबद्ध करती है जो अमान्य-वर्ण और लंबाई त्रुटियां उत्पन्न करते हैं और प्रत्येक को तुरंत कैसे पहचानें।
वह कुंजी जो टर्मिनल में काम करती थी और ब्राउज़र में विफल रही - एक अदृश्य चरित्र और दो घंटे की खोज
एक इंजीनियर ने एक स्क्रिप्ट में परीक्षण करने के लिए टर्मिनल से API कुंजी की प्रतिलिपि बनाई। कुंजी ने टर्मिनल में ठीक से काम किया लेकिन ब्राउज़र टूल में चिपकाए जाने पर अमान्य वर्ण के साथ विफल रही। दो घंटे बाद, कोड, कॉन्फ़िगरेशन और दस्तावेज़ीकरण के माध्यम से खोज करने के बाद, उन्हें एक अदृश्य चरित्र का पता चला। कुंजी के अंत में एक नई लाइन, इको द्वारा जोड़ी गई या टर्मिनल प्रॉम्प्ट लाइन से कॉपी की गई, एक अतिरिक्त चरित्र बन गई जिसने Base64 डिकोडर को तोड़ दिया। कुंजी सही थी; क्लिपबोर्ड नहीं था. Base64 डेटा तब विश्वसनीय होता है जब इसे इलेक्ट्रॉनिक रूप से प्रसारित किया जाता है, चेकसम किया जाता है और सत्यापित किया जाता है। यह लगभग विशेष रूप से मैन्युअल कॉपी और पेस्ट करने के दौरान टूट जाता है।
टर्मिनलों में लाइन रैपिंग, कमांड आउटपुट से न्यूलाइन्स को पीछे करना, रिच टेक्स्ट एडिटर्स में स्मार्ट कोट प्रतिस्थापन और विभिन्न अनुप्रयोगों के बीच कॉपी-पेस्ट से छिपे हुए यूनिकोड वर्ण सभी त्रुटियां पेश करते हैं जो Base64 की तरह दिखते हैं जब वास्तविक समस्या यह होती है कि इसे कैसे कॉपी किया गया था। यह पोस्ट सबसे आम दोषों को सूचीबद्ध करती है और दिखाती है कि हर एक को जल्दी से कैसे पहचाना और ठीक किया जाए। Base64 वर्णमाला में अपरकेस और लोअरकेस अक्षर, अंक, प्लस चिह्न, स्लैश और पैडिंग वर्ण (बराबर चिह्न) शामिल हैं। RFC 4648 विशिष्ट है: एक मानक Base64 स्ट्रिंग में केवल वे अक्षर होते हैं और यदि लाइनें लपेटी जाती हैं तो वैकल्पिक रिक्त स्थान होता है।
टर्मिनलों, ईमेल क्लाइंट और PEM फ़ॉर्मेटिंग से लाइन रैपिंग - क्यों 76-कॉलम ब्रेक कुछ डिकोडर्स के लिए ठीक है और दूसरों के लिए घातक है
कई टूल विचलन को सहन करते हैं: वे प्लस और स्लैश के बजाय डैश और अंडरस्कोर का उपयोग करके URL-सुरक्षित वेरिएंट को स्वीकार करते हैं, या वे नई लाइनों को अनदेखा करते हैं। एक सख्त डिकोडर जो RFC का पालन करता है, अपेक्षित वर्ण सेट के बाहर किसी भी चीज़ को अस्वीकार कर देता है और एक अमान्य वर्ण त्रुटि के साथ विफल हो जाता है। त्रुटि संदेश आमतौर पर आपत्तिजनक चरित्र का नाम देता है या नोट करता है कि स्ट्रिंग को बिल्कुल भी डिकोड नहीं किया जा सकता है। किसी ईमेल, टर्मिनल, चैट इतिहास या फ़ॉर्मेट किए गए दस्तावेज़ से Base64 चिपकाते समय, अदृश्य वर्ण या वर्ण प्रतिस्थापन अक्सर फिसल जाते हैं और डिकोडिंग विफल हो जाती है। डेटा स्वयं ठीक है; क्लिपबोर्ड स्थानांतरण ने इसे दूषित कर दिया।
लाइन रैपिंग चिपकाए गए Base64 विफलताओं का सबसे आम स्रोत है, और सबसे आसानी से ठीक किया जाने वाला भी है। टर्मिनल टूल आउटपुट को प्रति पंक्ति 76 वर्णों पर या कभी-कभी 80 पर लपेटते हैं, एक नई पंक्ति डालते हैं और अगली पंक्ति पर जारी रखते हैं। कुछ Base64-एन्कोडिंग लाइब्रेरीज़ सहित कई एनकोडर, MIME ईमेल के साथ संगतता के लिए अपने आउटपुट को समान 76-वर्ण सीमा पर लपेटते हैं। जब आप किसी टर्मिनल से लपेटे गए Base64 स्ट्रिंग को कॉपी करते हैं, तो नई लाइनें साथ आती हैं।
इको और क्लिपबोर्ड टूल से नई लाइनों को ट्रैक करना - अतिरिक्त बाइट जो एक अतिरिक्त चरित्र बन जाता है
कुछ डिकोडर नई लाइनों को स्वचालित रूप से स्वीकार और अनदेखा कर देते हैं। अन्य लोग उन्हें अमान्य वर्ण मानकर अस्वीकार कर देते हैं। समाधान सभी न्यूलाइन और रिक्त स्थान को हटाना है। यदि Base64 स्ट्रिंग को टर्मिनल में कई लाइनों में लपेटा गया है, तो सभी लाइनों का चयन करें, उन्हें एक एडिटर में कॉपी करें और सभी नई लाइनें हटा दें।
परिणामी सिंगल-लाइन स्ट्रिंग को कॉपी करें और इसे डिकोडर में पेस्ट करें। जब कोई पेस्ट विफल हो जाता है तो प्रयास करने वाली यह पहली चीज़ है। इको और क्लिपबोर्ड यूटिलिटीज़ से नई लाइनों को ट्रैक करना एक और आम अपराधी है। कमांड echo $API_KEY कुंजी के बाद एक नई लाइन प्रिंट करता है, जो कमांड मानक व्यवहार है। यदि आप उस आउटपुट को सीधे कॉपी करते हैं, तो कॉपी में नई लाइन शामिल हो जाती है। जब आप कॉपी करते हैं तो कुछ टर्मिनल एक अतिरिक्त नई लाइन जोड़ते हैं, और कुछ क्लिपबोर्ड प्रबंधक नई लाइनों को संरक्षित या डुप्लिकेट करते हैं। लक्षण लाइन रैपिंग के समान है: स्ट्रिंग के अंत में एक अतिरिक्त वर्ण जो Base64 में नहीं है।
स्मार्ट उद्धरण, गैर-ब्रेकिंग रिक्त स्थान और शून्य-चौड़ाई वाले वर्ण - कैसे समृद्ध-पाठ एडिटर सादे पाठ को फिर से लिखते हैं
समाधान भी उतना ही सरल है: डिकोड करने का प्रयास करने से पहले अपने एडिटर में चिपकाई गई स्ट्रिंग के सिरों को ट्रिम करें। अग्रणी और अनुगामी रिक्त स्थान और न्यूलाइन की तरह दिखने वाले किसी भी अक्षर को हटा दें। यदि स्ट्रिंग काफी छोटी है, तो आप इसे मैन्युअल रूप से फिर से टाइप कर सकते हैं, लेकिन लंबी कुंजियों के लिए, सावधानीपूर्वक मैन्युअल ट्रिमिंग तेज़ है। स्मार्ट उद्धरण, नॉन-ब्रेकिंग स्पेस और अन्य यूनिकोड प्रतिस्थापन सूक्ष्म जाल हैं। वर्ड जैसे रिच टेक्स्ट एडिटर स्वचालित रूप से सीधे उद्धरणों को घुंघराले उद्धरणों में परिवर्तित करते हैं, तीन हाइफ़न को एम-डैश में परिवर्तित करते हैं और कुछ स्पेस अनुक्रमों को नॉन-ब्रेकिंग स्पेस में परिवर्तित करते हैं। यदि कोई किसी दस्तावेज़ में Base64 स्ट्रिंग चिपकाता है और फिर आप उसे स्वरूपित दस्तावेज़ से एक टूल में कॉपी करते हैं, तो वे प्रतिस्थापन साथ आते हैं।
एक सीधा दोहरा उद्धरण (") एक घुंघराले बाएँ और दाएँ जोड़े में बदल जाता है, जिनमें से कोई भी मान्य Base64 नहीं है। एक गैर-ब्रेकिंग स्पेस (U+00A0) एक नियमित स्पेस के समान दिखता है, लेकिन इसमें एक अलग वर्ण कोड होता है और सभी पार्सर्स द्वारा व्हाइटस्पेस के रूप में पहचाना नहीं जाता है। समाधान पहले एक सादे टेक्स्ट एडिटर में पेस्ट करना है, जो सभी फ़ॉर्मेटिंग को हटा देता है। यदि आप किसी Word दस्तावेज़ या फ़ॉर्मेट की गई चैट से पेस्ट करते हैं, तो पहले एक प्लेन टेक्स्ट एडिटर या HTML में पेस्ट करें textarea और विषम वर्णों की जांच करें। फिर अपने टूल में उपयोग करने के लिए सादे पाठ संस्करण से कॉपी करें।
ट्रंकेशन और पैडिंग हानि - लंबाई-मॉड्यूलो-4 जांच जो आपको बताती है कि अक्षर गायब हैं
ट्रंकेशन तब होता है जब कॉपी करने या चिपकाने के दौरान कोई स्ट्रिंग कट जाती है। एक बहुत लंबी Base64 स्ट्रिंग कुछ सिस्टम पर क्लिपबोर्ड सीमा को पार कर सकती है या एप्लिकेशन बग के कारण कॉपी करने में विफल हो सकती है। परिणाम एक छोटी स्ट्रिंग है जो अधूरी है। पैडिंग लगाने के बाद Base64 स्ट्रिंग की लंबाई चार के गुणक में होनी चाहिए। यदि कोई लंबाई चार का गुणज नहीं है, तो उसे छोटा कर दिया जाता है या दूषित कर दिया जाता है। त्रुटि संदेश आमतौर पर नोट करता है कि स्ट्रिंग की लंबाई अमान्य है या कोई वर्ण गायब है। समाधान के लिए यह जानना आवश्यक है कि मूल रूप से क्या कॉपी किया गया था।
यदि आप स्रोत की दोबारा जांच कर सकते हैं, तो इसे सावधानीपूर्वक दोबारा कॉपी करें। यदि नहीं, तो काट-छाँट अप्राप्य है। पैडिंग हानि एक संबंधित मुद्दा है: कुछ बाइट्स को बचाने के लिए कभी-कभी समान चिह्नों वाली Base64 पैडिंग को हटा दिया जाता है। कुछ एप्लिकेशन पैडिंग छोड़ देते हैं और कुछ को इसकी आवश्यकता होती है। यदि कोई स्ट्रिंग मूल रूप से पैडेड थी और पैडिंग खो गई थी, तो उसे वापस जोड़ें। Base64 स्ट्रिंग में 0, 1 या 2 के बराबर चिह्न होने चाहिए, जिससे कुल लंबाई चार का गुणज हो। यदि इसमें कोई नहीं है और लंबाई चार का गुणज नहीं है, तो पैडिंग खो गई होगी।
व्यावहारिक उदाहरण: एक लपेटी हुई और कटी हुई डोरी की मरम्मत करना - इसे डीकोड होने तक चरण दर चरण साफ करना
एक कार्यशील उदाहरण इन मरम्मतों को चरण दर चरण दिखाता है। मान लीजिए कि एक कॉपी की गई API कुंजी आपके एडिटर में इस प्रकार दिखाई देती है: VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0Cg==. मुद्दों की पहचान करके शुरुआत करें। पिछला Cg== विषम है; सीजी एक न्यूलाइन कैरेक्टर (हेक्स 0ए) के लिए Base64 है, और अतिरिक्त == से पता चलता है कि कुछ जोड़ा गया था। पिछला Cg== हटाएँ और केवल VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0 आज़माएँ। यह अभी भी सही नहीं है; लंबाई 37 वर्ण है, चार का गुणज नहीं। फिर से ट्रिम करें: VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0 (35 अक्षर, अभी भी गलत)। मूल स्रोत की जाँच करें. सही स्ट्रिंग उचित पैडिंग के साथ VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0 (32 अक्षर) है: VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0। इसे जोड़ें: VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0=.
डिकोडर में परीक्षण करें. यह डिकोड करता है यह वास्तव में कोई रहस्य नहीं है। प्रत्येक चरण में, वर्तमान स्ट्रिंग का परीक्षण करने, पहचानी गई समस्या को ठीक करने और डीकोड होने तक फिर से परीक्षण करने के लिए Base64 एनकोडर और डिकोडर का उपयोग करें। Base64 बाइट्स के अंदर का भ्रष्टाचार डिकोडर द्वारा ठीक नहीं किया जा सकता है। यदि बाइट्स वास्तव में ट्रांज़िट, ट्रांसमिशन या स्टोरेज में दूषित हैं, तो Base64 स्वयं इसका पता नहीं लगा सकता है। RFC वैध वर्ण निर्दिष्ट करता है; उस सेट के बाहर के किसी भी चरित्र को पकड़ना डिकोडर का काम है। कोई भी बाइट भ्रष्टाचार, जैसे 0 का Base64 वर्ण के बीच में 1 बनना, पूरी तरह से एक अलग वर्ण कोड उत्पन्न करता है और अकेले Base64 द्वारा पता नहीं लगाया जा सकता है।
इसमें क्या शामिल नहीं है - एन्कोडेड बाइट्स के अंदर भ्रष्टाचार, जिसका Base64 स्वयं पता नहीं लगा सकता है
इस प्रकार के भ्रष्टाचार का पता लगाने के लिए चेकसम या डिजिटल हस्ताक्षर का उपयोग किया जाता है, और उन्हें Base64 एन्कोडिंग से पहले मूल बाइनरी डेटा पर गणना की जानी चाहिए। यदि आप Base64 स्ट्रिंग को डीकोड करते हैं और परिणाम बेकार है या आपकी अपेक्षा से भिन्न है, तो भ्रष्टाचार एन्कोडिंग से पहले या ट्रांसमिशन के दौरान हुआ था, कॉपी-पेस्ट चरण के दौरान नहीं। व्यवहार में यह दुर्लभ है. अधिकांश विफलताएँ उपरोक्त की तरह कॉपी-पेस्ट समस्याएँ हैं। Base64 कॉपी-पेस्ट विफलताओं को डीबग करने के लिए एक व्यवस्थित दृष्टिकोण प्रत्येक संभावित मुद्दे का क्रम में परीक्षण करना है। सबसे पहले, सभी रिक्त स्थान और नई पंक्तियाँ हटाएँ। फिर अग्रणी और अनुगामी स्थानों और किसी भी भटके हुए पात्रों को ट्रिम करें।
फिर लंबाई मॉड्यूलो चार की जांच करें और यदि आवश्यक हो तो पैडिंग जोड़ें। प्रत्येक संस्करण को Base64 एनकोडर और डिकोडर में चिपकाएँ और देखें कि क्या यह डिकोड होता है। यदि लंबाई की जांच विफल हो जाती है, तो पूछें कि क्या स्ट्रिंग को छोटा कर दिया गया था और इसे मूल स्रोत से पुनर्प्राप्त करें। यदि वर्णमाला जांच विफल हो जाती है और आपको असामान्य अक्षर दिखाई देते हैं, तो स्मार्ट उद्धरण या यूनिकोड प्रतिस्थापन देखें और उन्हें ASCII समकक्षों से बदलें। एक ऑनलाइन टूल का उपयोग करें जो आपको अमान्य वर्णों को नाम से दिखाता है ताकि आप उन्हें पहचान सकें और हटा सकें। Base64 एनकोडर और डिकोडर प्रत्येक अमान्य वर्ण के लिए ऐसा करता है, यह बताता है कि कौन सा वर्ण वर्णमाला में नहीं है।
टेकअवे: डेटा को दोष देने से पहले लंबाई और वर्णमाला की जांच करें - कैसे Base64 एनकोडर और डिकोडर आपको प्रत्येक मरम्मत का परीक्षण करने के लिए एक तेज़ स्थानीय स्थान देता है
प्रत्येक वर्ण को ठीक करने के लिए उस फीडबैक का उपयोग करें और स्ट्रिंग के डीकोड होने तक जारी रखें। डिबगिंग की तुलना में रोकथाम आसान है। जब आप जानते हैं कि आपको Base64 स्ट्रिंग की फिर से आवश्यकता होगी, तो इसे इस तरह से कॉपी करें कि फ़ॉर्मेटिंग सुरक्षित रहे। इसे किसी रिच टेक्स्ट दस्तावेज़ में पेस्ट न करें. इसे एक सादे पाठ फ़ाइल या निर्दिष्ट पाठ क्षेत्र में संग्रहीत करें जो कोई प्रतिस्थापन नहीं करता है। यदि कोई आपको फ़ॉर्मेट किए गए संदेश में Base64 स्ट्रिंग भेजता है, तो उन्हें इसे कोड फ़ॉर्मेटिंग या प्लेनटेक्स्ट में पुनः भेजने के लिए कहें। यदि आपको किसी स्वरूपित स्रोत से प्रतिलिपि बनाना है, तो पहले एक सादे पाठ एडिटर में पेस्ट करें और उपयोग करने से पहले स्ट्रिंग को सत्यापित करें।
जैसे ही आपके पास स्ट्रिंग हो, Base64 एनकोडर और डिकोडर में उसका परीक्षण करें, इससे पहले कि आप उस पर भरोसा करें। यदि यह विफल हो जाता है, तो आप एक नई प्रति मांग सकते हैं जबकि स्रोत अभी भी पहुंच योग्य है। यदि आप स्ट्रिंग के पुराने होने या स्रोत के चले जाने तक प्रतीक्षा करते हैं, तो काट-छाँट या भ्रष्टाचार को ठीक करना असंभव हो जाता है। Base64 एनकोडर और डिकोडर आपको किसी भी स्ट्रिंग का उपयोग करने से पहले उसका परीक्षण करने के लिए एक त्वरित स्थानीय स्थान देता है। जल्दी परीक्षण करें और बार-बार परीक्षण करें ताकि कॉपी-पेस्ट विफलताएं तुरंत पकड़ में आ जाएं।