Base64, हेक्स, प्रतिशत एन्कोडिंग और Base85: परिवहन द्वारा चुनें

संख्यात्मक रेडिक्स रूपांतरण के साथ टेक्स्ट एन्कोडिंग को भ्रमित किए बिना बाइट ओवरहेड, एस्केपिंग और इंटरऑपरेबिलिटी की तुलना करें।

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

हेक्स क्रियात्मक है लेकिन निरीक्षण करना आसान है

हेक्साडेसिमल प्रत्येक बाइट को दो अंकों के रूप में लिखता है। बाइट अनुक्रम FF 00 41 बन जाता है ff0041. प्रत्येक जोड़ी में एक दृश्यमान बाइट सीमा होती है, जो फ़ाइल हस्ताक्षर, चेकसम और प्रोटोकॉल पैकेट का निरीक्षण करते समय मदद करती है। यह वर्णों की संख्या को दोगुना कर देता है, लेकिन इसका छोटा अक्षर आमतौर पर लॉग और डिबगिंग टूल में आसानी से फिट हो जाता है।

Base64 आकार और अंतरसंचालनीयता को संतुलित करता है

Base64 चार वर्णों वाले तीन बाइट्स का प्रतिनिधित्व करता है। यह टेक्स्ट-आधारित प्रारूपों के अंदर बाइनरी फ़ील्ड के लिए एक सामान्य फिट है। मानक Base64 में प्लस और स्लैश शामिल हैं; Base64URL उन वर्णों को प्रतिस्थापित करता है जब प्रोटोकॉल को एक अलग वर्णमाला की आवश्यकता होती है। पैडिंग और रिक्त स्थान नियमों को अभी भी सहमति की आवश्यकता है। कोई भी फॉर्म रिसीवर को यह नहीं बताता कि डिकोड किए गए बाइट्स टेक्स्ट हैं, एक छवि हैं या संपीड़ित सामग्री हैं।

प्रतिशत एन्कोडिंग URL घटकों से संबंधित है

प्रतिशत एन्कोडिंग एक एस्केप्ड बाइट को इस प्रकार लिखता है %HH. यह केवल Base64 का एक बड़ा विकल्प नहीं है। घटक निर्धारित करता है कि किन वर्णों से बचना चाहिए, और पाठ को पहले UTF-8 के रूप में एन्कोड किया जाना चाहिए। एक स्लैश पथ खंडों को अलग कर सकता है जबकि एक प्रश्न चिह्न एक क्वेरी शुरू करता है; संपूर्ण URL को एक अपारदर्शी घटक मानने से इसका अर्थ बदल जाता है।

console.log(encodeURIComponent('a+b / 中文'));
// a%2Bb%20%2F%20%E4%B8%AD%E6%96%87

Base85 को एक सटीक संस्करण की आवश्यकता है

कई Base85 योजनाएं पांच वर्णों वाले चार बाइट्स का प्रतिनिधित्व करती हैं, लेकिन उनके अक्षर, सीमांकक और विशेष मामले भिन्न होते हैं। ASCII85 और Z85 को विनिमेय नहीं माना जा सकता। Z85 ब्लॉक-आकार की आवश्यकताओं को भी लागू करता है। एक उच्च-घनत्व वर्णमाला में विराम चिह्न हो सकते हैं जिन्हें स्पष्ट लाभ को कम करते हुए आसपास के प्रारूप में फिर से छोड़ दिया जाना चाहिए।

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

बाइट निरीक्षण के लिए हेक्स का उपयोग करें, इंटरऑपरेबल बाइनरी ट्रांसपोर्ट के लिए निर्दिष्ट Base64 वेरिएंट, यूआरएल के लिए URL घटक एन्कोडिंग, और एक विशेष योजना का उपयोग केवल तभी करें जब दोनों पक्ष एक ही अनुबंध लागू करें। भागने और संपीड़न के बाद अंत-से-अंत आकार की तुलना करें। RFC 4648 मानक Base16, Base32 और Base64 परिवारों को उनके विशिष्ट वर्णमाला सहित परिभाषित करता है।