Visual Basic में Base64 डिकोडिंग: एक सम्पूर्ण गाइड

मंज़र सोचिए: आपकी Visual Basic प्रोजेक्ट में एक स्ट्रिंग उतर आती है। वह अक्षरों और अंकों की एक बेली हुई ताश की डेक जैसी लगती है, बीच-बीच में कभी-कभार प्लस, स्लैश या बराबर चिह्न भी मिल जाएँ, और जो इंसान ने यह भेजा है, वह क़सम खाता है कि यह कभी एक बिल्कुल साधारण वाक्य था, एक JPEG, या एक कॉन्फ़िग ब्लॉब। वही स्ट्रिंग Base64 है, और यह पेज उसी को वापस उस चीज़ में बदलने की फील्ड गाइड है जो वह पहले था। शुरू में ही अच्छी खबर: बहुत पहले, .NET Framework की शुरुआती दिनों से ही, Visual Basic के पास फर्स्ट-क्लास Base64 डिकोडर है, वह रनटाइम के अंदर बसा है, और इसे इस्तेमाल करने के लिए आपको एक भी पैकेज इंस्टॉल करने की ज़रूरत नहीं है।

एक तेज़ दोहराई, क्योंकि इस साइट का होम पेज इस फ़ॉर्मैट को पूरा-पूरा गहराई से समझाता है: Base64 तीन बाइट्स को 64 चिह्नों की वर्णमाला से लिए चार चरों के रूप में लिखता है, और पूंछ में एक-दो = चर बताते हैं कि असली डेटा कहाँ ख़त्म हुआ। इसलिए एन्कोडेड टेक्स्ट मूल की तुलना में थोड़ा फूल गया हुआ होता है: हर तीन इनपुट बाइट्स पर चार चर, करीब एक-तिहाई ज़्यादा। डिकोडिंग बस उसी सौदे को उल्टा चलाती है। सवाल का स्वरूप समझ कर, चलिए कुछ एन्वेलॉप खोलते हैं।

डिकोडर परिवार: एक रनटाइम, चार दौर

डिकोडिंग के लिए जो कुछ भी ज़रूरी है, वह सब .NET रनटाइम के अंदर बसा है। बीस सालों में यह चार लहरों में बढ़ा, और पुरानी लहरें आज भी बिल्कुल वैसे ही चलती हैं जैसे पहले चलती थीं, इसलिए असल दुनिया में आप इन सभी को चलते देखेंगे:

आगे बढ़ने से पहले Visual Basic की एक क्लेरिफ़िकेशन। VB प्रोजेक्ट में सादा नाम Convert का रिज़ॉल्यूशन System.Convert पर होता है, क्योंकि स्टैंडर्ड प्रोजेक्ट टेम्पलेट आपके लिए System नेमस्पेस इम्पोर्ट कर देते हैं, और Visual Basic रनटाइम में कोई चीज़ उस नाम पर शैडो नहीं करती। फिर भी, यह लेख ज़्यादातर पूरा System.Convert रूप लिखता है: इसमें कोई ख़र्च नहीं, और जो भी कोड पढ़ रहा है, उसे मक़सद बिना किसी ग़लतफ़हमी से साफ़ दिखता है।

वर्ज़नों की बात: .NET 10 वर्तमान लॉन्ग-टर्म-सपोर्ट रिलीज़ है (नवंबर 2025, समर्थन नवंबर 2028 तक), और .NET 8 भी .NET 9 भी नवंबर 2026 तक समर्थित रहते हैं, जबकि .NET 11 प्रिव्यू में है और नई Base64 सुविधा मीथड्स का एक दस्ता जोड़ता है। डिकोडिंग वाली API हर एक में स्थिर हैं। एकमात्र वर्ज़न-गेट Base64Url है: .NET 9 और उसके बाद यह बिल्ट-इन है, और .NET Framework 4.6.2 या उससे नया हो तो Microsoft.Bcl.Memory पैकेज से इसे लाया जा सकता है। इस लेख में बाक़ी कुछ भी पैकेज मांगता नहीं।

अगर आप शून्य से सेटअप कर रहे हैं, तो .NET SDK में Visual Basic पहले से बॉक्स में है, इसलिए पूरा रस्म बस इतना है:

dotnet new console -lang VB -o EnvelopeOpener
cd EnvelopeOpener
dotnet run

इससे आपको एक छोटी सी Program.vb मिलती है, जिसकी सबसे ऊपर Imports System लिखा है, और अब आप डिकोड करने के लिए तैयार हैं।

वन-लाइनर: FromBase64String

Visual Basic की डिकोडिंग वाली ज़िंदगी का नब्बे प्रतिशत एक ही कॉल है। इसे एक स्ट्रिंग दें, और वह वापस वही बिल्कुल सटीक बाइट्स सौंपेगा जो अंदर पैक थे:

Imports System
Imports System.Text
Module EnvelopeOpener
    Sub Main()
        Dim packed As String = "TWFu"
        Dim bytes() As Byte = System.Convert.FromBase64String(packed)
        Dim text As String = Encoding.UTF8.GetString(bytes)
        Console.WriteLine(text)
        ' Man
    End Sub
End Module

तीन बातें याद रखने लायक हैं। पहली, रिज़ल्ट बाइट्स हैं, टेक्स्ट नहीं: डिकोडर सिरे-से-सिर बाइट-ओरिएंटेड है, और यही बिल्कुल वह चीज़ है जो चाहिए, क्योंकि पेलोड एक वाक्य हो, JPEG हो, सर्टिफ़िकेट हो, या हैश हो, इनमें से किसी को भी ख़ास नहीं मानना चाहिए। उन बाइट्स को पढ़ने लायक स्ट्रिंग में बदलना एक अलग, जान-बूझ कर लिया गया कदम है, Encoding ऑबजेक्ट के रास्ते, और बस उसी कदम पर आपका कैरेक्टर-सेट का फैसला होता है (उसके बारे में नीचे और)। दूसरी, FromBase64String एक ताज़ा ऐरे अलोकेट करता है जो बिल्कुल डिकोड की गई लंबाई के बराबर साइज़ में होता है, इसलिए आप कभी भी बेकार की खाली क्षमता के साथ घूमते नहीं। तीसरी, "TWFu" शब्द "Man" में डिकोड होता है, तीन बाइट्स, बिल्कुल कोई सरप्राइज़ नहीं, और यही इसे हर उस डिकोड कोड के लिए परिपूर्ण स्मोक टेस्ट बनाता है जो आप लिखें।

क्या क्षमा करता है, क्या ठुकराता है

यहीं .NET डिकोडर अपनी शख़्सियत दिखाता है, और काफ़ी पक्की शख़्सियत: एक चीज़ में वह बिल्कुल दयालु है और बाक़ी सब में बेरहम। वह दयालु चीज़ है व्हाइटस्पेस। डिकोडर बस चार चर छोड़ देता है, चाहे वे कहीं भी आएँ: स्पेस (U+0020), टैब (U+0009), लाइन फ़ीड (U+000A) और कैरिएज रिटर्न (U+000D)। यह नीति ईमेल की ओर एक जान-बूझ कर किया गया इशारा है, जहाँ Base64 पेलोड्स छोटी-छोटी पंक्तियों में रैप्ड आते हैं, और इसका मतलब यह है कि एक MIME-रैप्ड एटैचमेंट ज़ीरो प्रीप्रोसेसिंग में डिकोड हो जाता है। एक मज़ेदार तथ्य: यह दयालुता पूरे बिल्ट-इन परिवार का साझा गुण है, स्पैन-आधारित System.Buffers.Text.Base64 और URL-सुरक्षित Base64Url क्लास समेत, इसलिए आप जो भी API चुनें, आपको वही क्षमाशील व्यवहार मिलता है। 64-चिह्न वर्णमाला से बाहर कुछ भी, लंबाई का नियम तोड़ने वाला कुछ भी, या ग़लत जगह की पैडिंग, इन तीनों को एक्सेप्शन का हक़ मिलता है। एक ही डिकोडर को कुछ अलग-अलग इनपुट पर चलते देखें:

तो ईमानदार करार छोटा और याद रखने लायक है: Nothing रेफ़रेंस ArgumentNullException थ्रो करता है, ख़ाली या सिर्फ़-व्हाइटस्पेस इनपुट ख़ाली ऐरे में डिकोड होता है, वैध इनपुट बाइट्स में डिकोड होता है, और ग़लत चीज़ें सब एक बहुत ही ख़ास एक्सेप्शन थ्रो करती हैं, FormatException।

बाइट्स से टेक्स्ट तक: कैरेक्टर सेट का चुनाव

उस पल जब आप तय करते हैं कि डिकोड हुए बाइट्स वाक़ई टेक्स्ट हैं, आपको एक कैरेक्टर सेट नाम देना होगा, क्योंकि बाइट्स तभी तक टेक्स्ट नहीं जब तक आप न बताएं कि उन्हें कैसे पढ़ना है। Visual Basic स्ट्रिंग्स के अंदर के अंदर UTF-16 होती हैं, लेकिन डिकोडर से बाहर आ रहे बाइट्स किसी और ने बनाए हैं, शायद किसी अलग स्कीम के तहत, इसलिए आपको उनके चुनाव से मेल खाना होगा। प्रैक्टिकल मेन्यू:

• Encoding.UTF8: जो कुछ भी वेब से या किसी API से गुज़रा है, उसके लिए सुरक्षित डिफ़ॉल्ट। शक हो, तो यहीं से शुरू करें।
• Encoding.Unicode: UTF-16 लिटल-एंडियन, .NET का अपना स्वाद। तब सही विकल्प जब एक्सचेंज के दोनों सिरे .NET प्रोग्राम हों जिन्होंने स्पष्ट रूप से UTF-16 चुना हो।
• Encoding.ASCII: सिर्फ़ 7-बिट। ग़ैर-ASCII बाइट्स की जगह प्रश्न चिह्न भर दिए जाते हैं, इसलिए यह लॉसी चुनाव है जो चुपचाप अक्सेंट्स को ख़त्म कर देता है।
• Encoding.Default: .NET Framework पर यह मशीन की ANSI कोड पेज थी, लेकिन .NET (Core) पर यह लोकल के बावजूद हमेशा UTF-8 है। फिर भी, जो डेटा आप एक्सचेंज करते हैं, उसके लिए इसे टालें - एन्कोडिंग जाहिर तौर पर नाम दें, आमतौर पर Encoding.UTF8।

Imports System
Imports System.Text
Module CharsetDemo
    Sub Main()
        ' शब्द "Café" UTF-8 बाइट्स के रूप में स्टोर
        Dim bytes() As Byte = System.Convert.FromBase64String("Q2Fmw6k=")
        Dim correct As String = Encoding.UTF8.GetString(bytes)
        Console.WriteLine(correct)
        ' Café
    End Sub
End Module

वही पाँच बाइट्स Encoding.Unicode से पढ़िए, तो आपको बेअर्थ चरों की एक छोटी स्ट्रिंग मिलती है - कुछ अजीब CJK-रेंज के चर और एक रिप्लेसमेंट मार्क - क्योंकि डिकोडिंग बाइट्स को दो-दो का जोड़ा बनाती है। "Café" के UTF-8 बाइट्स Encoding.ASCII से पढ़िए, तो अक्सेंट ?? बन जाता है, दो प्रश्न चिह्नों की जोड़ी, क्योंकि अक्सेंट UTF-8 में दो बाइट्स का होता है। इनमें से कोई भी चुनाव एक्सेप्शन थ्रो नहीं करता; वे बस चुपचाप ग़लत टेक्स्ट बना देते हैं, और यही वजह है कि कैरेक्टर सेट वह फैसला है जो आप जान-बूझ कर लेते हैं, वह डिफ़ॉल्ट नहीं जो आप विरासत में पाते हैं।

URL-सुरक्षित वर्णमाला: Base64Url

स्टैंडर्ड Base64 में + और / का इस्तेमाल होता है, और इन दोनों चरों के URL के अंदर अपने-अपने मतलब हैं, इसलिए स्टैंडर्ड वर्णमाला क्वेरी स्ट्रिंग में उतरते ही एक लिंक तोड़ सकती है। उपाय, जिसका विनियमन RFC 4648 के सेक्शन 5 में हुआ है, URL- और फ़ाइल-नेम-सुरक्षित वेरिएंट है: वही 64-चर स्कीम, जिसमें - + की जगह लेता है और _ / की जगह, और आख़िरी पैडिंग आमतौर पर छोड़ दी जाती है क्योंकि लंबाई ही उसे संकेतित कर देती है। इस वर्णमाला से आप JWTs, API टोकन्स और हर उस जगह मिलेंगे जहाँ Base64 किसी URL के अंदर सवारी करता है। .NET 9 ने इसके लिए एक पक्की क्लास जोड़ी, System.Buffers.Text.Base64Url, और इस्तेमाल में यह सुकून देती है:

Imports System.Buffers.Text
Imports System.Text
Module UrlSafeOpener
    Sub Main()
        ' URL-सुरक्षित इनपुट, आख़िर में कोई पैडिंग नहीं
        Dim packed As String = "SGVsbG8gd29ybGQ"
        Dim bytes() As Byte = Base64Url.DecodeFromChars(packed)
        Dim text As String = Encoding.UTF8.GetString(bytes)
        Console.WriteLine(text)
        ' Hello world
    End Sub
End Module

दो व्यवहार जानने लायक हैं। Base64Url एन्कोडर डिज़ाइन से ही बिना पैडिंग के आउटपुट देता है, लेकिन इसका डिकोडर पैडेड और अन-पैडेड दोनों इनपुट मान लेता है, इसलिए यह दूसरे एकोसिस्टम के डेटा के लिए भी दोस्ताना है। और Base64Url.IsValid आपको डिकोड से पहले किसी उम्मीदवार स्ट्रिंग की प्री-चेक करने देता है, जो तब काम आता है जब डेटा बाहरी दुनिया से आ रहा हो। अगर आप उस क्लास के बिना पुराने रनटाइम पर फँसे हैं, तो रूपांतरण दो चर-बदलाव और एक पैडिंग की भरपाई है, बिल्कुल उल्टा जैसा एन्कोडर ने किया था:

Imports System
Module CompatOpener
    Function FromUrlSafe(ByVal packed As String) As Byte()
        Dim standard As String = packed.Replace("-"c, "+"c).Replace("_"c, "/"c)
        Select Case standard.Length Mod 4
            Case 2
                standard &= "=="
            Case 3
                standard &= "="
        End Select
        Return System.Convert.FromBase64String(standard)
    End Function
End Module

.NET Framework 4.6.2 या उससे नया हो तो आप बजाय इसके Microsoft.Bcl.Memory NuGet पैकेज इंस्टॉल कर सकते हैं और असली Base64Url क्लास इस्तेमाल कर सकते हैं। दोनों तरीकों से नियम सरल है: संदर्भ (URL, JWT, API टोकन) से वर्णमाला पहचानें, फिर उससे मेल खाता डिकोडर चुनें।

फ़ाइलें खोलना

Base64 के सबसे पुराने इस्तेमालों में से एक है टेक्स्ट फ़ाइलों के ज़रिए बाइनरी की तस्करी: एक .b64 या .txt फ़ाइल जिसमें एन्कोडेड बाइट्स बसे हों। Visual Basic में रउंड ट्रिप दो फ़ाइल कॉल और एक डिकोड है। टेक्स्ट पढ़ो, उसे डिकोड करो, बाइट्स लिखो:

Imports System.IO
Module FileOpener
    Sub Main()
        Dim packed As String = File.ReadAllText("payload.b64")
        Dim bytes() As Byte = System.Convert.FromBase64String(packed)
        File.WriteAllBytes("payload.bin", bytes)
    End Sub
End Module

व्हाइटस्पेस की यह छूट इसे एक संतोषजनक तरीके से मज़बूत बनाती है: फ़ाइल को इससे कोई फ़र्क़ नहीं पड़ता कि पेलोड एक लंबी पंक्ति में लिखा गया था, 76 चर पर रैप्ड, या 64 पर रैप्ड, क्योंकि डिकोडर लाइन ब्रेक्स दोनों हालत में छोड़ देता है। एक साइज़िंग वाला तथ्य जेब में रखें: टेक्स्ट फ़ाइल उस बाइनरी की तुलना में करीब एक-तिहाई बड़ी होती है जिसे वह छुपाती है, इसलिए 10 मेगाबाइट की फ़ाइल करीब 13.3 मेगाबाइट चरों के रूप में आती है। कोई बड़ी बात नहीं, लेकिन जब कोई "छोटी" टेक्स्ट फ़ाइल बड़ी लगे, तो यही वह नंबर है जिसे याद रखना चाहिए।

इमेजेस और डेटा URIs

डेटा URI स्कीम (RFC 2397) किसी URL को अपना खुद का कंटेंट ढोने देती है: data: के बाद मीडिया टाइप, लिटरल मार्कर ;base64, एक कॉमा, और फिर एन्कोडेड बाइट्स। आपने इसे वेब के हर कोने-कोने में देखा है, HTML और CSS में, जहाँ यह छोटी इमेजेस और फ़ॉन्ट्स को अलग फ़ाइल की ओर इशारे के बजाय सीधे मार्कअप में एम्बेड करती है। Visual Basic में उसको खोलना बस एक स्ट्रिंग स्प्लिट और एक डिकोड है। नीचे का उदाहरण किसी डेटा URI से एक PNG बाहर निकालता है और उससे एक WPF इमेज बनाता है:

Imports System.IO
Imports System.Windows.Media.Imaging
Module DataUriOpener
    Function ImageFromDataUri(ByVal dataUri As String) As BitmapImage
        Dim comma As Integer = dataUri.IndexOf(","c)
        Dim header As String = dataUri.Substring(0, comma)
        If Not header.EndsWith(";base64") Then
            Throw New FormatException("Not a base64 data URI")
        End If
        Dim packed As String = dataUri.Substring(comma + 1)
        Dim bytes() As Byte = System.Convert.FromBase64String(packed)
        Dim image As New BitmapImage()
        image.BeginInit()
        image.CacheOption = BitmapCacheOption.OnLoad
        image.StreamSource = New MemoryStream(bytes)
        image.EndInit()
        Return image
    End Function
End Module

हेडर पर डिफेंसिव चेक पर ध्यान दें: ;base64 मार्कर के बिना डेटा URI के अंदर बजाय इसके URL-एस्केप्ड डेटा होता है, और उसे Base64 की तरह डिकोड करने पर या तो फेल हो जाएगा या कबाड़ी टेक्स्ट निकलेगा। RFC खुद चेतावनी देती है कि डेटा URIs सिर्फ़ छोटी वैल्यूज़ के लिए काम आते हैं, और HTML के अपने एट्रिब्यूट लंबाई की सीमाएँ हैं, इसलिए इसे आइकॉन्स, एवेटार और थंबनेल के लिए सही औज़ार मानें, अपनी पूरी फोटो लाइब्रेरी एक एट्रिब्यूट में भेजने के लिए नहीं।

HTTP, APIs और Basic Auth

Base64 वेब API में हर जगह है, और दो सबसे आम रूप हैं HTTP Basic ऑथ हेडर और JSON फ़ील्ड्स जो बाइनरी या पहले से एन्कोडेड डेटा ढोती हैं। Basic ऑथ सबसे सरल केस है: क्लाइंट Authorization: Basic भेजता है, उसके बाद username:password का Base64। इसे Visual Basic में डिकोड करना एक प्रिफ़िक्स चेक और एक कॉल है:

Imports System
Imports System.Text
Module BasicAuthOpener
    Function ReadCredentials(ByVal header As String) As String
        If Not header.StartsWith("Basic ", StringComparison.OrdinalIgnoreCase) Then
            Throw New FormatException("Not a Basic auth header")
        End If
        Dim packed As String = header.Substring(6)
        Dim bytes() As Byte = System.Convert.FromBase64String(packed)
        Return Encoding.UTF8.GetString(bytes)
    End Function
End Module

यह फंक्शन username:password को एक ही स्ट्रिंग के रूप में सौंपता है, जो आप कॉलन पर स्प्लिट कर देते हैं। दूसरा रोज़मर्रा का केस है JSON रिस्पॉन्स, जहाँ कोई फ़ील्ड एक पहले से एन्कोडेड ब्लॉब हो, जैसे इमेज या सर्टिफ़िकेट। HttpClient और System.Text.Json के साथ (System.Text.Json .NET Core 3.0 से बॉक्स में है, और HttpClient बहुत पहले से) पैटर्न सीधा है:

Imports System.Net.Http
Imports System.Text.Json
Module ApiOpener
    Async Function ReadImageAsync() As Task(Of Byte())
        Using client As New HttpClient()
            Dim json As String = Await client.GetStringAsync("https://httpbin.org/get?attachment=TWFuIGlzIGhlcmU%3D&name=man.txt")
            Dim doc As JsonDocument = JsonDocument.Parse(json)
            Dim packed As String = doc.RootElement.GetProperty("args").GetProperty("attachment").GetString()
            Return System.Convert.FromBase64String(packed)
        End Using
    End Function
End Module

दो हाउसकीपिंग नोट्स। कभी डिकोड किया हुआ क्रेडेंशियल किसी लॉग या UI में बस इसलिए प्रिंट न करें कि आप कर सकते हैं, और सादे HTTP के ऊपर Basic ऑथ पर कभी भरोसा न करें, क्योंकि तब आप बस पासवर्ड को एक ज़्यादा रोचक वर्णमाला में लिख रहे होते हैं।

JWTs: तीनों टुकड़े पढ़ना

कम्पैक्ट फ़ॉर्म में JSON Web Token तीन डॉट-सेपरेटेड टुकड़ों की Base64Url है: हेडर, पेलोड, और सिग्नेचर। पहले दो सादा JSON हैं जिसे आप आँखों से पढ़ सकते हैं (या एक डिकोड कॉल से), जबकि तीसरा एक क्रिप्टोग्राफ़िक सिग्नेचर है जिसे सही की से चेक करना होगा, डिकोड नहीं। एक आम डेमो का नमूना टोकन ऐसा दिखता है: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIn0.W-5gI_FdnMBdpgG4twX96rptvh13gmXQ75kKLRXVaGs। इसका पेलोड Visual Basic में पढ़ने का मतलब है डॉट्स पर स्प्लिट करना, URL-सुरक्षित वर्णमाला को वापस स्टैंडर्ड में बदलना, और डिकोड करना:

Imports System
Imports System.Text
Module JwtOpener
    Function ReadPayload(ByVal token As String) As String
        Dim parts() As String = token.Split("."c)
        If parts.Length <> 3 Then
            Throw New FormatException("Not a compact JWT")
        End If
        ' URL-सुरक्षित वर्णमाला को वापस स्टैंडर्ड में बदलें
        Dim packed As String = parts(1).Replace("-"c, "+"c).Replace("_"c, "/"c)
        Select Case packed.Length Mod 4
            Case 2
                packed &= "=="
            Case 3
                packed &= "="
        End Select
        Dim bytes() As Byte = System.Convert.FromBase64String(packed)
        Return Encoding.UTF8.GetString(bytes)
    End Function
End Module

उसे नमूना टोकन पर चलाइए, तो आपको JSON {"sub":"1234567890","name":"John Doe"} मिलती है। हेडर को उसी तरह पढ़िए, तो मिलता है {"alg":"HS256","typ":"JWT"}। यहाँ वह चेतावनी जो मायने रखती है: JWT पढ़ना उसे वैरिफ़ी करना नहीं है। कोई भी टोकन बना सकता है, इसलिए उसमें किसी भी क्लेम पर भरोसा करने से पहले, सिग्नेचर को इशुअर की की से वैलिडेट करें। इस काम के लिए System.IdentityModel.Tokens.Jwt NuGet पैकेज (Microsoft Entra टीम का IdentityModel सूट) Base64Url की बारीकियाँ, सिग्नेचर चेक, और क्लेम पार्सिंग आपके लिए संभालता है, और यही बिल्कुल वह लेयर है जहाँ आप अपने हाथों से कोई चीज़ नहीं बनाना चाहेंगे।

ईमेल एटैचमेंट्स, 76 चर पर रैप्ड

ईमेल वह जगह है जहाँ Base64 ने अपनी पहचान बनाई। SMTP 7-बिट ASCII के लिए बना था, इसलिए बाइनरी एटैचमेंट को उड़ने से पहले टेक्स्ट बनना पड़ता है, और MIME स्टैंडर्ड (RFC 2045) ने 76-चर की पंक्ति-सीमा के साथ Base64 चुना, जो और भी पुरानी 64-चर PEM पंक्तियों का निकट रिश्तेदार है। अगर आपने कभी कच्चा ईमेल देखा है, तो आपने परिणाम देखा है: घने Base64 का एक ब्लॉक, साफ़-सुथरी छोटी पंक्तियों में तोड़ा हुआ, Content-Transfer-Encoding: base64 हेडर के नीचे। डिकोडर के लिए ख़ूबसूरत हिस्सा यह है कि आपको किसी चीज़ को अन-रैप करने की ज़रूरत नहीं। .NET डिकोडर लाइन ब्रेक्स और स्पेस को चाहे कहाँ मिलें छोड़ देता है, इसलिए रैप्ड ब्लॉक जैसा-सा है वैसे ही डिकोड हो जाता है:

Imports System
Imports System.Text
Module MimeOpener
    Sub Main()
        ' 59-बाइट का वाक्य, 76 चर पर CRLF के साथ MIME-रैप्ड
        Dim wrapped As String = "VGhlIHF1aWNrIGJyb3duIGZveCBqdW1wcyBvdmVyIHRoZSBsYXp5IGRvZywgYW5kIHRoZW4gc29t" & vbCr & vbLf & "ZS4="
        Dim bytes() As Byte = System.Convert.FromBase64String(wrapped)
        Console.WriteLine(Encoding.UTF8.GetString(bytes))
        ' The quick brown fox jumps over the lazy dog, and then some.
    End Sub
End Module

अगर आप System.Net.Mail क्लासेस के साथ काम कर रहे हैं, तो डिकोडिंग और भी अदृश्य हो जाती है: MailMessage में जोड़ा गया Attachment ContentEncoding के रूप में TransferEncoding.Base64 ढोता है, और मेल लाइब्रेरी आपके लिए रैप करती है, भेजती है, और पूरा रस्म अन-रैप कर देती है। आपको हाथ से डिकोड तभी ज़रूरत जब आप स्ट्रीम, टेस्ट फ़िक्सचर, या लीगेसी मेलबॉक्स फ़ाइल से कच्चा MIME पढ़ रहे हों।

डेटाबेसेस, कॉन्फ़िग और एनवायरनमेंट वेरिएबल्स

टेक्स्ट-ओनली स्टोरेज बार-बार Base64 माँगता रहता है: टेक्स्ट के रूप में टाइप किया डेटाबेस कॉलम, XML कॉन्फ़िग वैल्यू, एनवायरनमेंट वेरिएबल। इन सबको सादे चर चाहिए, इसलिए बाइनरी को स्टोर करने से पहले एन्कोड कर दिया जाता है और वापस आने पर डिकोड। डिकोड वाली तरफ़ हमेशा वही वन-लाइनर है, और दिलचस्प हिस्सा साइज़ की हिसाब-किताब है। SQL Server में एक साधारण NVARCHAR कॉलम 8,000 चर पर रुक जाता है, जिसका मतलब है कि 33 प्रतिशत की टैक्स आपको सीमा पार कराने से पहले, यह सिर्फ़ करीब 6,000 बाइट्स बाइनरी की जगह है; उसके बाद आप MAX वेरिएंट्स की ओर बढ़ते हैं या, ईमानदारी से कहें, असली बाइनरी कॉलम की। Windows पर एक यूज़र-डिफ़ाइन्ड एनवायरनमेंट वेरिएबल 32,767 चर पर कैप होता है (और XP-के-ज़माने के सिस्टम पर पूरा एनवायरनमेंट ब्लॉक भी उसी साइज़ पर कैप था), इसलिए "पूरा लाइसेंस ब्लॉब एक एनवर्स में स्टोर करो" के पास एक सख़्त सीमा है। यहाँ एक डिकोडिंग पैटर्न है जो दिमाग़ के किसी कोने में रखने लायक है: स्टोर की गई फिंगरप्रिंट को किसी फ़ाइल से चेक करना, कॉन्स्टेंट-टाइम कंपैरिज़न के साथ, ताकि मेल न खाने पर टाइमिंग की जानकारी लीक न हो:

Imports System.Security.Cryptography
Module FingerprintCheck
    Function FingerprintsMatch(ByVal expectedPacked As String, ByVal fileBytes() As Byte) As Boolean
        Dim expected() As Byte = System.Convert.FromBase64String(expectedPacked)
        Dim actual() As Byte = SHA256.HashData(fileBytes)
        Return CryptographicOperations.FixedTimeEquals(expected, actual)
    End Function
End Module

वही स्वरूप किसी भी स्टोर किए गए हैश के लिए काम करता है: स्टोर की गई वैल्यू डिकोड करें, ताज़ा हैश कंप्यूट करें, और फिक्स्ड टाइम में तुलना करें। कॉन्फ़िग फ़ाइलें वही पैटर्न फॉलो करती हैं, चाहे वैल्यू XML app.config एंट्री से आई हो, JSON सेटिंग्स फ़ाइल से, या रेजिस्ट्री स्ट्रिंग से।

बड़ा डेटा: लोड किए बिना स्ट्रीम डिकोड करना

अब तक के हर उदाहरण ने पूरा पेलोड मेमोरी में पढ़ा है, जो एटैचमेंट्स और कॉन्फ़िग वैल्यूज़ के लिए ठीक है, लेकिन उस दो-गिगाबाइट फ़ाइल के लिए ग़लत है जिसे किसी ने टेक्स्ट फ़ाइल में एन्कोड कर दिया। उस पैमाने के लिए, .NET की एक स्ट्रीमिंग जोड़ी है जो .NET Framework 1.1 (2003) से मौजूद है: FromBase64Transform क्रिप्टो ट्रांसफ़ॉर्म, CryptoStream में लपेटा हुआ। आप एन्कोडेड टेक्स्ट के चंक पढ़ते हैं, ट्रांसफ़ॉर्म उन्हें ऑन-द-फ्लाई डिकोड करता है, और आप बाइट्स बाहर लिखते हैं, इसलिए फ़ाइल चाहे कितनी भी बड़ी हो, मेमोरी सपाट रहती है:

Imports System.IO
Imports System.Security.Cryptography
Module StreamOpener
    Sub DecodeFile(ByVal packedPath As String, ByVal outputPath As String)
        Using packedStream As New FileStream(packedPath, FileMode.Open, FileAccess.Read)
            Using decodedStream As New CryptoStream(packedStream, New FromBase64Transform(), CryptoStreamMode.Read)
                Using outputStream As New FileStream(outputPath, FileMode.Create)
                    Dim buffer(65535) As Byte
                    While True
                        Dim read As Integer = decodedStream.Read(buffer, 0, buffer.Length)
                        If read = 0 Then Exit While
                        outputStream.Write(buffer, 0, read)
                    End While
                End Using
            End Using
        End Using
    End Sub
End Module

चूँकि एन्कोडेड फ़ाइल सादा ASCII टेक्स्ट है, उसे बाइट स्ट्रीम की तरह पढ़ना बिल्कुल सुरक्षित है, और ट्रांसफ़ॉर्म लाइन रैपिंग का सामना आपके कुछ किए बिना कर लेता है। आउटपुट फ़ाइल इनपुट की करीब तीन-चौथाई साइज़ की बनती है, जो वही 33 प्रतिशत टैक्स है जो अंदर आते समय चुकाई गई, अब बाहर आते समय वसूल की जा रही है।

वे फँसाव जो ख़ासकर Visual Basic को काटते हैं

इस सेक्शन के ज़्यादातर फँसाव बाक़ी .NET भाषाओं के साथ साझा हैं, लेकिन कुछ पर ख़ासतौर पर VB की टोपी है, इसलिए यहाँ वे एक साथ हैं:

• Byte वर्सेस Byte()। Visual Basic में एक अकेला बाइट Byte होता है और बाइट्स का ऐरे Byte(), जहाँ ख़ाली कोष्ठक पूरा काम करते हैं। Byte() की जगह Dim b As Byte लिखना क्लासिक पहला-दिन ग़लती है, और यही बिल्कुल वही चीज़ है जिसे Option Strict On कम्पाइल टाइम पर पकड़ता है। अगर आपके प्रोजेक्ट में यह पहले से ऑन नहीं है, तो ऑन कर दें: dotnet new console -lang VB टेम्पलेट फैसला आपके हाथ में छोड़ता है, जबकि Visual Studio प्रोजेक्ट टेम्पलेट इसे सेट कर देते हैं।
• स्पैन की दीवार। मॉडर्न स्पैन-आधारित API VB से कॉल हो सकती हैं, लेकिन बस कॉल साइट पर: आप Byte() या Char() ऐरे सीधे किसी ऐसे मीथड में सौंप सकते हैं जो स्पैन लेता है, और कम्पाइलर आपके लिए उसे बदल देता है। जो आप नहीं कर सकते वह है अपने कोड में स्पैन का नाम लेना। Span या ReadOnlySpan टाइप की वैरिएबल, फ़ील्ड, या पैरामीटर घोषित कीजिए, तो कम्पाइलर का जवाब यही आता है: "Types with embedded references are not supported in this version of your compiler"। इसलिए VB की प्रचलित शैली है: स्पैन API को सादे ऐरे के साथ कॉल करें, और कभी भी स्पैन को वैरिएबल में स्टोर करने की कोशिश न करें।
• BitConverter Base64 नहीं है। BitConverter.ToString(bytes) बाइट्स को hex में दिखाता है, डैश से अलग किए हुए, जिससे यह "बाइट्स को स्ट्रिंग में बदलो" सुनने वाला हर किसी के लिए एक आकर्षक ग़लत जवाब बन जाता है। जब API TWFu की उम्मीद करती है, वह खुशी-खुशी आपको 4D-61-6E सौंप देगा। शक हो, तो System.Convert की ओर बढ़ें।
• MidB एक भूत है। क्लासिक Visual Basic में बाइट-लेवल स्ट्रिंग फंक्शन थे, MidB, LeftB, और RightB, डबल-बाइट कैरेक्टर सेट्स के लिए बने। अब हर .NET स्ट्रिंग Unicode है, और रनटाइम दस्तावेज़ सीधा कहते हैं: वे अब समर्थित नहीं हैं। अगर कोई लीगेसी स्निप्लेट इन्हें इस्तेमाल करता है, तो उसे बाइट ऐरे और इस लेख की API से दोबारा लिखें।
• Encoding.Default मशीन के पीछे चलता है। लोकल-अंतर का क़िस्सा .NET Framework वाला है: मॉडर्न .NET पर Default हमेशा UTF-8 है, इसलिए वही बाइट्स हर जगह एक ही तरह डिकोड होते हैं। जो डेटा आप साझा करते हैं, उसके लिए एन्कोडिंग जाहिर तौर पर नाम दें, आमतौर पर Encoding.UTF8 - यह सलाह दोनों हालत में लागू रहती है।
• रउंड ट्रिप पहिचान नहीं होते। अगर आप किसी स्ट्रिंग को डिकोड करते हैं और फिर रिज़ल्ट को एन्कोड करते हैं, तो नई स्ट्रिंग मूल से मेल खानी ज़रूरी नहीं: व्हाइटस्पेस गायब हो जाता है, और पैडिंग नॉर्मलाइज़ हो जाती है। लाइन ब्रेक्स वाला पेलोड एक साफ़ पंक्ति के रूप में वापस आता है। डेटा के लिए ठीक है, ख़तरनाक तब जब आपकी लॉजिक एन्कोडेड टेक्स्ट की तुलना डिकोड बाइट्स के बजाय कर रही हो।
• सिर्फ़-व्हाइटस्पेस इनपुट एक चुप सफलता है। बस स्पेस और लाइन ब्रेक्स की स्ट्रिंग बिना किसी एरर के ख़ाली बाइट ऐरे में डिकोड हो जाती है, जिसका मतलब है "यूज़र ने सिर्फ़ न्यूलाइन्स पेस्ट किए" बिल्कुल वैसा दिखता है जैसे "यूज़र ने ख़ाली पेलोड पेस्ट किया"। अगर यह फ़र्क़ मायने रखता है, तो डिकोड से पहले इनपुट की लंबाई जाँचें।

डिकोडिंग के लिए बेस्ट प्रैक्टिसेस

ऊपर की सब चीज़ों से छनकर, वे आदतें जो डिकोड कोड को बोरिंग रखती हैं (बेहतरीन अर्थ में):

• Base64 को ट्रांसपोर्ट मानें, संरक्षण नहीं। यह एन्कोडिंग है, एन्क्रिप्शन नहीं: कोई भी एक फंक्शन कॉल से मूल को पढ़ सकता है, और RFC 4648 यह भी नोट करती है कि वर्णमाला के ढिल्ले-ढालू हैंडलिंग से गुप्त चैनल खुल सकते हैं। पहले एन्क्रिप्ट करें, और फिर एन्कोड करें, अगर आपको कंटेंट छुपाना हो।
• अविश्वसनीय इनपुट के लिए, FormatException को उड़ने देने के बजाय Try मीथड्स या IsValid प्री-चेक को प्राथमिकता दें। Boolean को दोस्ताना एरर मेसेज में बदलना, एक्सेप्शन को निगलने से आसान है।
• कैरेक्टर सेट जान-बूझ कर चुनें, और डिफ़ॉल्ट UTF-8 रखें, जब तक कि किसी और स्कीम के लिए आपके पास दस्तावेज़ीकृत वजह न हो।
• वर्णमाला को स्रोत से मिलाएँ: MIME, ईमेल, और कॉन्फ़िग के लिए स्टैंडर्ड Base64; JWTs और URL के अंदर के कुछ भी के लिए Base64Url।
• बड़ी चीज़ें FromBase64Transform और CryptoStream से स्ट्रीम करें, स्ट्रिंग में लोड करने के बजाय।
• फिंगरप्रिंट्स और हैश की तुलना CryptographicOperations.FixedTimeEquals से करें, = से नहीं, ताकि टाइमिंग यह न लीक करे कि वैल्यू का कितना हिस्सा मिला।
• Option Strict On रखें, ताकि Byte/Byte() वाली ग़लती-परिवार कम्पाइल एरर बने, प्रोडक्शन रहस्य के बजाय।

Visual Basic को डिकोडर कैसे मिला

कहानी उस दौर से शुरू होती है जब Visual Basic के पास Base64 बिल्कुल नहीं था। Visual Basic 6 और VBA की दुनिया में (वह मैक्रो भाषा जो आज भी Excel और Office के अंदर चलती है), जिन डेवलपर्स को Base64 चाहिए थी, उन्होंने उसे मशीन पर पहले से मौजूद COM कंपोनेंट्स से उधार लिया। मशहूर ट्रिक एक XML DOM एलिमेंट का इस्तेमाल करती थी: MSXML पार्सर किसी नोड को अपनी DataType bin.base64 घोषित करने देता है, इसलिए Base64 स्ट्रिंग को नोड की text प्रॉपर्टी में डालना और उसके nodeTypedValue को वापस पढ़ना आपको कच्चे बाइट्स सौंप देता है, जबकि असली Base64 गणित DOM करती है (ADO Stream ऑबजेक्ट की अपनी Charset प्रॉपर्टी बस असली कैरेक्टर-सेट के नामों को समझती है, जैसे "utf-8" या "iso-8859-1", "base64" को नहीं, यही वजह है कि ट्रिक बजाय इसके MSXML की ओर बढ़ती है)। एन्कोडिंग उसी सोच को उल्टा चलाती थी: बाइट्स nodeTypedValue में लिखे जाते थे और एन्कोडेड स्ट्रिंग को text से वापस पढ़ा जाता था:

' क्लासिक VB6 / VBA डिकोड ट्रिक, संदर्भ के लिए
Dim node As Object
Set node = CreateObject("MSXML2.DOMDocument").createElement("b64")
node.DataType = "bin.base64"
node.text = packed            ' Base64 स्ट्रिंग
Dim bytes() As Byte
bytes = node.nodeTypedValue

यह काम करता था, यह चतुर था, और यही वजह है कि तीस दशकों बाद भी "base64 VBA" सर्च इंजनों को रोशन करता है। फिर 2002 ने सब बदल दिया: Visual Basic 7.0 (भाषा का पहला .NET वर्ज़न, तब इसे Visual Basic .NET कहा जाता था) नए Common Language Runtime में शामिल हुआ, और .NET Framework ने System.Convert को FromBase64String और उसके साथियों के साथ बॉक्स में ही सौंप दिया। 2003 के .NET Framework 1.1 से, हर VB प्रोग्राम के पास एक फर्स्ट-क्लास डिकोडर था, किसी कंपोनेंट को रजिस्टर किए बिना। मॉडर्न लहर 2018 में .NET Core 2.1 के साथ आई, जिसने एक्सेप्शन-मुक्त Try मीथड्स और तेज़ स्पैन-आधारित System.Buffers.Text.Base64 क्लास जोड़ी, और 2024 में .NET 9 के साथ, जिसने अंततः URL-सुरक्षित वर्णमाला को Base64Url के रूप में स्टैंडर्ड किया। 2026 तक, .NET 10 - नवंबर 2025 में रिलीज़ - लॉन्ग-टर्म-सपोर्ट रिलीज़ है, और प्रिव्यू .NET 11 लाइब्रेरियाँ Base64 सुविधा मीथड्स की एक नई पीढ़ी जोड़ रही हैं, इसलिए डिकोडर बेहतर होता जाता है, जबकि 2003 का मूल वन-लाइनर बिना बदलाव के चलता रहता है।

VB दुनिया से रुचिकर तथ्य

• आधिकारिक Visual Basic कम्पाइलर खुद Visual Basic में लिखा गया है। ओपन-सोर्स Roslyn प्रोजेक्ट का हिस्सा होने के नाते, यह भाषा खुद को कम्पाइल करती है।
• बिल्कुल पहला Visual Basic 1991 में शिप किया गया, जब वेब का दौर शुरू भी नहीं हुआ था। Base64 का बड़ा पल 1993 में MIME के साथ आया, और VB खुद ने दो साल बाद 32-बिट की क्षमता पाई, जब 1995 में Visual Basic 4 ने पहली बार 32-बिट प्रोग्राम संभव बनाए। 1997 की VB 5 ने पूरी राह तय की: सिर्फ़ 32-बिट, बॉक्स में 16-बिट का कोई नामोनिशान नहीं।
• क्लासिक VB के बाइट-लेवल फंक्शन MidB, LeftB, और RightB .NET में आधिकारिक तौर पर "अब समर्थित नहीं" हैं, क्योंकि फ्रेमवर्क के पहले दिन से हर VB स्ट्रिंग Unicode है। पूरा परिवार API, एक एन्कोडिंग चुनाव से सेवानिवृत्त।
• रनटाइम का Base64 मशीनरी कोई पुराने-फ़ैशन टेबल लुकअप नहीं है: मॉडर्न इम्प्लेमेंटेशन, जब मशीन उन्हें समर्थित करती है, तब हार्डवेयर-वेक्टराइज़्ड कोड पथ (AVX-512, AVX2, और SSE वेरिएंट) चलाती है, इसलिए "धीमा टेक्स्ट कोडेक" होना अंदर के अंदर घटित बात नहीं है।
• VB6-के-ज़माने की MSXML bin.base64 ट्रिक आज भी प्रोडक्शन Excel मैक्रो में चलती है, जिसका मतलब है कि 1990 के दशक के अंत की एक वर्कअराउंड और 2003 की Convert कॉल एक ही संगठन के कोडबेस में खुशी-खुशी साथ बसे हैं।

जाने से पहले

इस लेख ने Visual Basic में Base64 की डिकोडिंग वाली तरफ़ कवर की है, वन-लाइनर से स्ट्रीमिंग तक, JWTs से उन फँसाव तक जो VB की टोपी पहने हैं। सिक्के का दूसरा हिस्सा, अपने बाइट्स और टेक्स्ट को सबसे पहले Base64 में बदलना, पैडिंग, लाइन ब्रेक्स, और साइज़ टैक्स के बारे में अपने फैसलों वाला दस्ता है, और उसे sister साइट पर संगत एन्कोडिंग लेख में विस्तार से कवर किया गया है। उसका लिंक बस इस लाइन के नीचे है, और होम पेज पर वाला टूल छोटे पेलोड को हाथ से चेक करने की सबसे तेज़ राह बना हुआ है।

अंतिम अपडेट: 2026-09-08

संबंधित लेख: Visual Basic में Base64 एन्कोडिंग: एक सम्पूर्ण गाइड