Base32, Base58, Ascii85 और Z85 एन्कोडर व डिकोडर

इसका इस्तेमाल कैसे करें

फॉर्मेट चुनें, और मोड में एन्कोड या डिकोड।
टेक्स्ट में टेक्स्ट लिखें। परिणाम लिखते समय दिखता है।
जाँच पढ़ें। जब वह बताए कि टेक्स्ट मान्य नहीं है, तो जो अक्षर वह नाम ले उसे सुधारें; मान्य होने पर परिणाम कॉपी करें।

पाँच फॉर्मेट

हर फॉर्मेट बाइनरी डेटा को छपने योग्य अक्षरों के एक तय सेट में लिखता है। फॉर्मेट इस बात में अलग हैं कि वे कितने अक्षर इस्तेमाल करते हैं, और परिणाम इनपुट से कितना लंबा होता है।

Base32 (RFC 4648, खंड 6): A से Z और 2 से 7। हर अक्षर में पाँच बिट जाते हैं, इसलिए आठ अक्षर पाँच बाइट रखते हैं, और टेक्स्ट को आठ के गुणज तक = से पैड किया जाता है।
Base32hex (RFC 4648, खंड 7): 0 से 9 और A से V। यह डेटा का सॉर्ट क्रम रखता है, जो Base32 नहीं रखता।
Base58 बिटकॉइन वर्णमाला इस्तेमाल करता है, जो 0, O, I और l छोड़ती है ताकि मिलते-जुलते अक्षर न उलझें। हर आगे का शून्य बाइट 1 बन जाता है, और कोई पैडिंग नहीं होती।
Ascii85 चार बाइट को ! से u तक के पाँच अक्षरों में लिखता है, जो डेटा से लगभग एक-चौथाई लंबा है। चार शून्य बाइट z लिखे जाते हैं।
Z85 Ascii85 का वह रूप है जो सोर्स कोड के लिए बना है: चार बाइट पाँच अक्षरों में बदलते हैं, एक 85 अक्षरों की वर्णमाला से जो स्ट्रिंग में सुरक्षित है। उसका डेटा चार बाइट का गुणज होना चाहिए।

टेक्स्ट और बाइट

टेक्स्ट को उसके UTF-8 बाइट (RFC 3629) के रूप में एन्कोड किया जाता है। अंग्रेजी का A एक बाइट लेता है, देवनागरी का हर अक्षर तीन बाइट और इमोजी चार। डिकोड करने पर बाइट वापस टेक्स्ट बनते हैं। जब डिकोड हुए बाइट मान्य UTF-8 नहीं होते, जैसे कोई फ़ाइल या कुंजी, तो पेज उन्हें हेक्साडेसिमल में दिखाता है, ताकि कोई बाइट न खोए।

डिकोड क्या स्वीकार और क्या मना करता है

RFC 4648 का खंड 3.3 कहता है कि डिकोडर अपनी वर्णमाला से बाहर के अक्षर मना करे। यह पेज ऐसा ही करता है, इसलिए Base32 छोटे अक्षर स्वीकार नहीं करता। यह स्पेस और लाइन-ब्रेक अनदेखे करता है, क्योंकि वे कॉपी-पेस्ट से आते हैं। Base32 की पैडिंग वैकल्पिक है। पेज उस Base32 टेक्स्ट को भी मना करता है जिसके आखिरी अक्षर के पैड बिट शून्य नहीं हैं, जिसकी अनुमति खंड 3.5 डिकोडर को देता है।

हल किया हुआ उदाहरण: नमस्ते, Base32 में

टेक्स्ट नमस्ते के छह अक्षर हैं, पर देवनागरी का हर अक्षर UTF-8 में तीन बाइट लेता है, इसलिए वह 18 बाइट का है। Base32 उसे 32 अक्षरों में लिखता है: 4CSKRYFEV3QKJOHAUWG6BJFE4CSYO===, जिसके आखिर में = चिह्न हैं।

RFC 4648 का खंड 10 foobar का Base32 मान देता है: MZXW6YTBOI======। पेज उसे इसी तरह जाँच सकता है। नीचे की तालिका वही है जो पेज मोड को एन्कोड पर रखकर नमस्ते के लिए दिखाता है।

परिणाम	नमस्ते के लिए
जाँच	Base32 में एन्कोड किया गया।
परिणाम	4CSKRYFEV3QKJOHAUWG6BJFE4CSYO===
बाइट	18
अक्षर	32

अक्सर पूछे जाने वाले सवाल

क्या Base32 एक तरह का एन्क्रिप्शन है?

नहीं। Base32 वही बाइट एक अलग वर्णमाला में लिखता है। कोई भी इसे बिना कुंजी के डिकोड कर सकता है, इसलिए यह कुछ छिपाता नहीं और डेटा की सुरक्षा के लिए इसका इस्तेमाल नहीं होना चाहिए।

Base58 0, O, I और l क्यों छोड़ता है?

बिटकॉइन वर्णमाला, जिसे यह पेज इस्तेमाल करता है, वे अक्षर छोड़ती है जो कई फॉन्ट में एक जैसे दिखते हैं, ताकि हाथ से कॉपी किया गया मान गलत न पढ़ा जाए। यह वर्णमाला Bitcoin Core के सोर्स कोड में है।

मेरा Z85 टेक्स्ट क्यों मना हो गया?

Z85 चार-चार बाइट में एन्कोड करता है, इसलिए डेटा चार बाइट का गुणज होना चाहिए। डिकोड करते समय टेक्स्ट पाँच अक्षरों का गुणज होना चाहिए, और हर अक्षर Z85 वर्णमाला में होना चाहिए। कोई अक्षर छूटना या ज्यादा होना आम कारण है।

टेक्स्ट की जगह हेक्साडेसिमल क्यों दिखता है?

डिकोड हुए बाइट मान्य UTF-8 टेक्स्ट नहीं हैं। उन्हें टेक्स्ट के रूप में दिखाने पर कुछ बाइट खो जाते या बदल जाते, इसलिए पेज हर बाइट हेक्साडेसिमल में दिखाता है।

क्या Ascii85 और Base85 एक ही हैं?

Ascii85 base 85 का एक रूप है, जिसमें ! से u तक के अक्षर और z का छोटा रास्ता है। Z85 एक और base 85 है, जो Ascii85 से निकला है और जिसकी वर्णमाला सोर्स कोड में सुरक्षित है।

क्या मेरा टेक्स्ट कहीं भेजा जाता है?

नहीं। एन्कोड और डिकोड आपके ब्राउज़र में होता है, और आप जो लिखते हैं वह हमारे सर्वर पर न भेजा जाता है न वहाँ सहेजा जाता है।

स्रोत

आँकड़े और टेक्स्ट आखिरी बार मंगलवार, 10 नवंबर 2026 को जाँचे गए।

परिणाम