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

Visual Basic को बोझ उठाने दें: Convert.ToBase64String और उसके साथी पैकिंग संभालते हैं, इसलिए पहले बाइट्स चुनें, MIME पंक्तियाँ रैप करें, और JWTs, ईमेल और बहुत कुछ बनाएँ।

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

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

एन्कोडर का टूलबॉक्स: सब कुछ बिल्ट-इन

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

API	कब से उपलब्ध	इसे किस काम के लिए
`System.Convert.ToBase64String`	.NET Framework 1.1 (2003)	क्लासिक। एक ऐरे अंदर, एक स्ट्रिंग बाहर, ऐरे सबसेट्स, स्पैन, और वैकल्पिक MIME-शैली लाइन ब्रेक्स के लिए ओवरलोड समेत।
`System.Convert.ToBase64CharArray`	.NET Framework 1.1 (2003)	एन्कोडेड चर को उसी चर बफ़र में लिखता है जो आप पहले से अलोकेट कर चुके हैं, और बताता है कि उसने कितने चर इस्तेमाल किए।
`System.Convert.TryToBase64Chars`	.NET Core 2.1 (2018)	स्पैन-आधारित, अलोकेशन-हल्की एन्कोडिंग, उसी चर स्पैन में जो आप देते हैं, एक्सेप्शन की जगह Boolean जवाब के साथ।
`System.Buffers.Text.Base64`	.NET Core 2.1 (2018)	निचली-स्तरीय, स्पैन-आधारित एन्कोडिंग: अपने UTF-8 बफ़र में लिखें, इन-प्लेस फुलाएँ, और `GetMaxEncodedToUtf8Length` से बफ़र्स की साइज़ लगाएँ।
`System.Buffers.Text.Base64Url`	.NET 9 (2024)	URL-सुरक्षित वर्णमाला (`+` और `/` की जगह `-` और `_`), बिना पैडिंग। पुराने रनटाइम पर यह `Microsoft.Bcl.Memory` NuGet पैकेज के साथ आती है।
`ToBase64Transform` + `CryptoStream`	.NET Framework 1.1 (2003)	स्ट्रीमिंग एन्कोडिंग: फ़ाइल को चंकों में पढ़ें, एन्कोडेड टेक्स्ट बाहर लिखें, बहुत बड़े इनपुट पर भी मेमोरी सपाट रखें।

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

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

आपकी पहली एन्कोडिंग: बाइट्स अंदर, टेक्स्ट बाहर

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

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

वह तीन-पंक्तियों वाला मध्य हिस्सा ही पूरा हुनर है, और स्ट्रिंग "TWFu" हर उस एन्कोडर के लिए परिपूर्ण स्मोक टेस्ट है जो आप लिखें। जब ज़रूरत पड़े, ओवरलोड आपको काबू देते हैं। सबसेट फ़ॉर्म किसी ऐरे के हिस्से को एन्कोड करती हैं, उसे पहले बाहर कॉपी किए बिना, जो तब काम आता है जब असली पेलोड किसी बड़े बफ़र के अंदर बसा हो:

Imports System
Module SlicePacker
    Sub Main()
        Dim data() As Byte = {1, 2, 3, 4, 5, 6, 7, 8}
        Dim packed As String = System.Convert.ToBase64String(data, 2, 4)
        Console.WriteLine(packed)
        ' AwQFBg==  (सिर्फ़ बाइट्स 3 से 6 एन्कोड हुए)
    End Sub
End Module

और ऐरे-से-चर फ़ॉर्म, ToBase64CharArray, उस चर बफ़र में लिखता है जो आप अलोकेट करते हैं और बताता है कि उसने कितने चर भरे, और यही सही औज़ार है जब गंतव्य किसी बड़े टेक्स्ट संरचना का हिस्सा हो जो आप हाथ से बना रहे हैं। Visual Basic सिंटैक्स का घर का नियम नोट करें: बाइट ऐरे Byte() लिखा जाता है, ख़ाली कोष्ठक के साथ। उन्हें छोड़िए और पास में एक अकेला बाइट रह गया, और Option Strict On (टेम्पलेट्स में डिफ़ॉल्ट से ऑफ़ - हर प्रोजेक्ट में ऑन करने लायक) यह गड़बड़ कम्पाइल टाइम पर पकड़ लेगा।

आउटपुट को मोड़ना: पैडिंग, लाइन ब्रेक्स और सटीक साइज़

वही बाइट्स दो बार एन्कोड करने से वैध रूप में दो अलग-अलग स्ट्रिंग्स निकल सकती हैं, और अंतर सब आउटपुट मोड़ने की बात है। पहला, पैडिंग: जब इनपुट की लंबाई तीन की गुणज नहीं होती, तो एन्कोडर आख़िरी समूह को एक-दो = चरों से भर देता है। RFC कहती है कि उन्हें शामिल करें, जब तक कि आप जिस विनिर्देश को फॉलो कर रहे हैं, वह कुछ और न कहता हो, और ToBase64String डिफ़ॉल्ट से उन्हें शामिल करता है। दूसरा, लाइन ब्रेक्स: फ़ॉर्मेटिंग ओवरलोड्स का दूसरा पैरामीटर, Base64FormattingOptions.InsertLineBreaks, एन्कोडर को CRLF से अलग 76-चर की पंक्तियाँ निकलने देता है, जो बिल्कुल MIME नियम है। MIME खुद 76-चर की सीमा इस्तेमाल करता है, जो पुरानी 64-चर PEM पंक्तियों का निकट रिश्तेदार है, और दोनों सीमाएँ SMTP की अंदरूनी सीमाओं तक जाती हैं। अगर आपका उपभोक्ता एक ईमेल पाइपलाइन है, तो लाइन ब्रेक्स ऑन करें; अगर वह URL, JSON फ़ील्ड, या डेटाबेस कॉलम है, तो उन्हें ऑफ़ छोड़ें, क्योंकि आपके डेटा के अंदर छिपा एक अदृश्य CRLF बाद में आपको सरप्राइज़ देने का राह निकाल लेगा:

Imports System
Module MimePacker
    Sub Main()
        Dim data(113) As Byte
        For i As Integer = 0 To 113
            data(i) = CByte(i)
        Next
        Dim wrapped As String = System.Convert.ToBase64String(data, Base64FormattingOptions.InsertLineBreaks)
        Console.WriteLine(wrapped.Length)
        ' 154: दो 76-चर की पंक्तियाँ और उनके बीच एक CRLF
    End Sub
End Module

तीसरा, सटीक साइज़, क्योंकि आप बफ़र्स और कॉलम चौड़ाई पहले से अलोकेट करना चाहेंगे। नियम है: हर तीन इनपुट बाइट्स पर चार चर, ऊपर गोल किया हुआ: 1000 बाइट्स 1336 चर बन जाते हैं। हिसाब-किताब हाथ से करने के बजाय, रनटाइम के पास एक हेल्पर है जो दिए गए इनपुट साइज़ के लिए अधिकतम एन्कोडेड लंबाई लौटाता है, और यही वह चीज़ है जो आप बफ़र अलोकेशन को देते हैं:

Imports System.Buffers.Text
Module Sizing
    Sub Main()
        Dim dataLength As Integer = 1000
        Dim textNeeded As Integer = Base64.GetMaxEncodedToUtf8Length(dataLength)
        Console.WriteLine(textNeeded)
        ' 1336
    End Sub
End Module

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

एन्कोड से पहले कैरेक्टर सेट चुनना

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

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

Imports System
Imports System.Text
Module CharsetPacker
    Sub Main()
        Dim text As String = "Café"
        Dim utf8() As Byte = Encoding.UTF8.GetBytes(text)
        Dim ascii() As Byte = Encoding.ASCII.GetBytes(text)
        Console.WriteLine(System.Convert.ToBase64String(utf8))
        ' Q2Fmw6k=
        Console.WriteLine(System.Convert.ToBase64String(ascii))
        ' Q2FmPw==  (अक्सेंट प्रश्न चिह्न बन गया)
    End Sub
End Module

दो अलग-अलग Base64 स्ट्रिंग्स, एक शब्द, और उनमें से बस एक ही यात्रा से बचती है। प्रैक्टिकल नियम: जब तक आप जिस प्रोटोकॉल को फॉलो कर रहे हैं, वह कोई और स्कीम नाम न ले, टेक्स्ट को UTF-8 में एन्कोड करें और यह भी कह दें।

Base64Url: वह वर्णमाला जो URLs में बनी रहती है

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

Imports System.Buffers.Text
Module UrlSafePacker
    Sub Main()
        Dim data() As Byte = {219, 255, 0, 63, 16}
        Dim packed As String = Base64Url.EncodeToString(data)
        Console.WriteLine(packed)
        ' 2_8APxA  (ंडरस्कोर, आख़िर में कोई पैडिंग नहीं)
    End Sub
End Module

ऊपर का उदाहरण अच्छा है: चुने गए बाइट्स एक ख़ास चर को सतह पर लाते हैं - न्डरस्कोर, जहाँ स्टैंडर्ड वर्णमाला में स्लैश होता है - इसलिए आप बदलाव को घटते देख सकते हैं। जब आप पुराने रनटाइम पर हों, तो वही वर्णमाला दो चर-बदलाव और एक ट्रिम है, और आपको ड्रॉप-इन कम्पाटिबल रिज़ल्ट मिलता है:

Imports System
Module CompatPacker
    Function ToUrlSafe(ByVal packed As String) As String
        Return packed.Replace("+"c, "-"c).Replace("/"c, "_"c).TrimEnd("="c)
    End Function
End Module

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

फ़ाइलें पैक करना

फ़ाइलें मूल प्रयोजन हैं: बाइनरी फ़ाइल को टेक्स्ट फ़ाइल में बदल दें, जिसे ईमेल, FTP, और कॉन्फ़िग सिस्टम सब खुशी-खुशी ढो लेंगे। Visual Basic में पूरा काम तीन कॉल है, जिनमें से एक पढ़ता है और एक लिखता है:

Imports System.IO
Module FilePacker
    Sub Main()
        Dim bytes() As Byte = File.ReadAllBytes("photo.png")
        Dim packed As String = System.Convert.ToBase64String(bytes)
        File.WriteAllText("photo.b64", packed)
    End Sub
End Module

साइज़ अनुपात जेब में रखें: 10 मेगाबाइट की फोटो करीब 13.4 मेगाबाइट की टेक्स्ट फ़ाइल बन जाती है। मॉडर्न हार्डवेयर पर यह काम तेज़ है (उसके बारे में नीचे और), इसलिए ख़र्च ज़्यादातर स्टोरेज और बैंडविड्थ का होता है, CPU का नहीं, जो 33 प्रतिशत टैक्स की रोज़मर्रा की बिल है। जब फ़ाइल बस उस टेक्स्ट के बगल में बसेगी जो उसे रिफ़रेंस करता है, तो यह पैटर्न बिल्कुल ठीक है; जब फ़ाइल बड़ी और दीर्घकालिक हो, तो पूछें कि क्या चैनल को वाक़ई टेक्स्ट फ़ॉर्म चाहिए।

इमेजेस: हाथ से डेटा URIs बनाना

डेटा URI स्कीम (RFC 2397) फ़ाइल कंटेंट को सीधे URL में एम्बेड करती है: data:, मीडिया टाइप, लिटरल मार्कर ;base64, एक कॉमा, और एन्कोडेड बाइट्स। ब्राउज़र इन्हें छोटी इमेजेस और फ़ॉन्ट्स को इनलाइन करने के लिए इस्तेमाल करते हैं। WPF डेटा URI को सीधे खपत नहीं कर सकता - BitmapImage के पास data: स्कीम के लिए कोई हैंडलर नहीं है - इसलिए प्रचलित कदम है प्रिफ़िक्स छीलना और बाइट्स MemoryStream को सौंपना। Visual Basic में URI बनाना एक स्ट्रिंग कंकेटनेशन है, और खपत एक छोटा सा इनिट ब्लॉक:

Imports System.IO
Imports System.Windows.Media.Imaging
Module DataUriPacker
    Sub Main()
        Dim bytes() As Byte = File.ReadAllBytes("logo.png")
        Dim dataUri As String = "data:image/png;base64," & System.Convert.ToBase64String(bytes)
        Dim image As New BitmapImage()
        image.BeginInit()
        image.StreamSource = New MemoryStream(System.Convert.FromBase64String(dataUri.Substring(dataUri.IndexOf(","c) + 1)))
        image.EndInit()
        ' अब image को किसी Image कंट्रोल पर सेट किया जा सकता है
    End Sub
End Module

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

HTTP: ऑथ हेडर्स और JSON पेलोड्स

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

Imports System
Imports System.Text
Module AuthPacker
    Function MakeBasicHeader(ByVal user As String, ByVal password As String) As String
        Dim raw() As Byte = Encoding.UTF8.GetBytes(user & ":" & password)
        Return "Basic " & System.Convert.ToBase64String(raw)
    End Function
End Module

JSON का केस उतना ही रूटीन है। अगर किसी API को रिक्वेस्ट बॉडी के अंदर इमेज या सर्टिफ़िकेट चाहिए, तो आप बाइट्स एन्कोड करते हैं और स्ट्रिंग को पेलोड में रख देते हैं, और System.Text.Json (.NET Core 3.0 से बॉक्स में) उसके चारों ओर की सीरीलाइज़ेशन संभालता है:

Imports System.Text.Json
Module ApiPacker
    Function WidgetPayload(ByVal name As String, ByVal imageBytes() As Byte) As String
        Dim payload = New With {
            .name = name,
            .image = System.Convert.ToBase64String(imageBytes)
        }
        Return JsonSerializer.Serialize(payload)
    End Function
End Module

दो घर के नियम: क्रेडेंशियल्स सिर्फ़ HTTPS के ऊपर भेजें, क्योंकि सादे HTTP के ऊपर Base64 एक कपड़ा है, ताला नहीं, और कभी भी न तो कच्चा ऑथ हेडर लॉग करें न वह क्रेडेंशियल जो वह डिकोड करता है।

ईमेल एटैचमेंट्स और MIME रैपिंग

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

Imports System.IO
Imports System.Net.Mail
Imports System.Net.Mime
Module MailPacker
    Sub Main()
        Using message As New MailMessage("me@example.com", "you@example.com")
            message.Subject = "Quarterly report"
            message.Body = "Please find the report attached."
            Using stream As New FileStream("report.bin", FileMode.Open, FileAccess.Read)
                Dim attachment As New Attachment(stream, "report.bin")
                attachment.TransferEncoding = TransferEncoding.Base64
                message.Attachments.Add(attachment)
            End Using
        End Using
    End Sub
End Module

आपको रैप्ड फ़ॉर्म खुद तभी बनानी होगी, Base64FormattingOptions.InsertLineBreaks के साथ, जब आप हाथ से कच्चा MIME टेक्स्ट लिख रहे हों: एक मेलर टेस्ट फ़िक्सचर, एक लीगेसी गेटवे, या एक टूल जो .eml फ़ाइलें निकालता हो। 76-चर का नियम कोई शैली-पसंद नहीं है; कुछ रिसीविंग सिस्टम लंबी पंक्तियाँ काट देते हैं, और यही वजह है कि यह सीमा दशकों से विनिर्देश में बनी हुई है।

एन्कोडेड वैल्यूज़ स्टोर करना: डेटाबेसेस, कॉन्फ़िग फ़ाइलें और एनवर्स

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

Imports System
Module EnvPacker
    Sub Main()
        Dim blob() As Byte = {1, 2, 3, 4, 5}
        Dim packed As String = System.Convert.ToBase64String(blob)
        Environment.SetEnvironmentVariable("APP_BLOB", packed)
        Console.WriteLine(packed)
        ' AQIDBAU=
    End Sub
End Module

कॉन्फ़िग फ़ाइलें वही स्वरूप फॉलो करती हैं, जहाँ वैल्यू XML या JSON टेक्स्ट में बसती है और डिकोड आपकी स्टार्टअप कोड में होता है। एंटरप्राइज़ कोने के लिए एक लीगेसी नोट: WCF और XML डेटा कॉन्ट्रैक्ट्स बाइट ऐरे को base64Binary XML स्कीमा टाइप के रूप में सीरीलाइज़ करते हैं, इसलिए पुराने .NET सर्विस का बड़ा समूह बाइनरी बिल्कुल इसी तरह स्टोर करता है, और उस XML में जो वैल्यू आप मिलेंगी वह सादा ToBase64String आउटपुट है।

JWTs: कम्पैक्ट फ़ॉर्म बनाना

कम्पैक्ट फ़ॉर्म में JSON Web Token तीन डॉट-सेपरेटेड टुकड़ों की base64url है: हेडर, पेलोड, और सिग्नेचर। पहले दो सादा JSON हैं, और तीसरा एक क्रिप्टोग्राफ़िक प्रूफ़ है कि सही की के धारक ने यही टोकन बनाया है। साइन-बिना स्वरूप को हाथ से बनाना दो एन्कोडिंग और एक स्ट्रिंग जोड़ है, लेकिन असली JWT को सिग्नेचर का कदम चाहिए, और एक छोटा सा HMAC-SHA256 उदाहरण पूरी चीज़ को ठोस बना देता है:

Imports System
Imports System.Buffers.Text
Imports System.Security.Cryptography
Imports System.Text
Module JwtPacker
    Function BuildHs256Jwt(ByVal headerJson As String, ByVal payloadJson As String, ByVal secret() As Byte) As String
        Dim header As String = Base64Url.EncodeToString(Encoding.UTF8.GetBytes(headerJson))
        Dim body As String = Base64Url.EncodeToString(Encoding.UTF8.GetBytes(payloadJson))
        Dim signingInput As String = header & "." & body
        Using hmac As New HMACSHA256(secret)
            Dim signature() As Byte = hmac.ComputeHash(Encoding.UTF8.GetBytes(signingInput))
            Return signingInput & "." & Base64Url.EncodeToString(signature)
        End Using
    End Function
End Module

उसे हेडर {"alg":"HS256","typ":"JWT"} और आपके चुनाव का कोई भी पेलोड के साथ चलाइए, तो रिज़ल्ट एक असली कम्पैक्ट JWT है: कहीं भी कोई पैडिंग नहीं, तीनों हिस्सों में URL-सुरक्षित चर। ध्यान दें कि सिग्नेचर भी base64url है, क्योंकि पूरे टोकन को URL या HTTP हेडर में बचना है। प्रोडक्शन सिस्टम के लिए, System.IdentityModel.Tokens.Jwt पैकेज (Microsoft Entra टीम का IdentityModel सूट) इन टोकन्स को आपके लिए बनाता है, साइन करता है, और वैरिफ़ी करता है, और यही वह लेयर है जहाँ की मैनेजमेंट, अल्गोरिथम पिनिंग, और एक्सपायरि चेक बसते हैं। एन्कोडिंग हाथ से बनाना समझने के लिए और छोटे टूल्स के लिए ठीक है; जो भी एक्सेस की रक्षा करता है, उस वज़न लाइब्रेरी को उठाए।

फँसाव: जहाँ VB एन्कोडर फिसलते हैं

यहाँ के फँसाव भाषा-आदतों और आउटपुट-मोड़ने के सरप्राइज़ का मिश्रण हैं, और ज़्यादातर का दाम डीबगिंग सेशन का पड़ता है, क्रैश का नहीं:

Byte बरस Byte()। एन्कोडर को ऐरे चाहिए। Visual Basic में एक अकेला बाइट Byte होता है और ऐरे Byte(), और फ़र्क़ एक जोड़ी कोष्ठक है। Option Strict On के तहत ग़लत अनुमान कम्पाइल एरर है; उसे ऑफ़ रखिए तो शायद आपको रनटाइम सरप्राइज़ मिले। सख़्ताइयों को ऑन रखें और कोष्ठक को नज़र आए रखें।
Encoding.Default का फँसाव, उल्टी तरफ़। लोकल-अंतर का क़िस्सा .NET Framework वाला है: मॉडर्न .NET पर Default हमेशा UTF-8 है, इसलिए वही स्ट्रिंग हर मशीन पर एक ही तरह एन्कोड होती है। जो भी मशीनों के बीच जाता है, उसके लिए एन्कोडिंग जाहिर तौर पर नाम दें, आमतौर पर UTF-8 - यह सलाह दोनों हालत में लागू रहती है।
CRLF का रास्ता खुला रहता है। InsertLineBreaks MIME के लिए शानदार है और URLs, JSON, और डेटाबेस टेक्स्ट कॉलम के लिए बेहद ख़राब, जहाँ यह एक कैरिएज रिटर्न और लाइन फ़ीड डाल देता है जो किसी ने माँगा ही नहीं। बस तभी इस्तेमाल करें जब उपभोक्ता रैप्ड पंक्तियों की उम्मीद करे, और शक हो तो डिफ़ॉल्ट None इस्तेमाल करें।
सीमा पर पैडिंग का मेल न खाना। .NET की Base64Url कोई पैडिंग नहीं देती, जबकि दूसरे एकोसिस्टम की कुछ लाइब्रेरियाँ उसे जोड़ती हैं (और कुछ सख़्त डिकोडर उसके लिए ही मज़बूर करते हैं)। जब आपका एन्कोडेड वैल्यू किसी एकोसिस्टम में जाता है, तो स्ट्रिंग भेजने से पहले दूसरे पक्ष की उम्मीद पक्की करें; JWT बिना-पैडिंग फ़ॉर्म माँगता है, जो .NET डिफ़ॉल्ट है।
रउंड ट्रिप पहिचान नहीं होते। एक रैप्ड, पैडेड स्ट्रिंग डिकोड करें और दोबारा एन्कोड करें, तो आपको साफ़ एक पंक्ति ताज़ी पैडिंग के साथ मिलती है, मूल टेक्स्ट नहीं। अगर आपकी लॉजिक एक्वालिटी के लिए एन्कोडेड वैल्यूज़ की तुलना करती है, तो बजाय इसके डिकोड बाइट्स की तुलना करें।
साइज़ की छत असली है। आउटपुट लंबाई का सूत्र, हर तीन बाइट्स पर चार चर ऊपर गोल किया हुआ, करीब 1.5 गिगाबाइट इनपुट पर 32-बिट गिनती को ओवरफ़्लो कर देता है, और एन्कोडर एक अधूरी स्ट्रिंग के बजाय OutOfMemoryException से जवाब देता है। उस पैमाने के करीब कहीं भी इनपुट के लिए, बजाय इसके स्ट्रीम करें (नीचे)।
स्पैन की दीवार। स्पैन-आधारित एन्कोडर 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 को जोड़ों के बीच डैश के साथ दिखाता है, इसलिए यह एक आकर्षक ग़लत जवाब है जो वहाँ 4D-61-6E बनाता है जहाँ दूसरी प्रणाली TWFu की उम्मीद करती है। Base64 के लिए, क्लास हर बार System.Convert है।

स्पीड और साइज़: परफ़ॉर्मेंस नोट्स

Base64 का "धीमा टेक्स्ट कोडेक" वाला ख़याल मॉडर्न रनटाइम से मिलने पर बचा नहीं। .NET के अंदर एन्कोडर, जब मशीन समर्थित करती है, हार्डवेयर-वेक्टराइज़्ड कोड चलाता है, AVX-512, AVX2, और SSE इंस्ट्रक्शन सेट्स के लिए विशेष फ़ास्ट पथ के साथ, और AVX-512 पथ हर स्टेप पर 48 बाइट्स निगल जाता है। साधारण पेलोड्स के लिए, क्लासिक ToBase64String कॉल इतना तेज़ है कि अल्गोरिथम ज़्यादातर बॉटलनेक नहीं बनता; जो ख़र्च आप महसूस करते हैं वे 33 प्रतिशत साइज़ टैक्स हैं और, हॉट पथ के लिए, मध्यवर्ती अलोकेशन। अगर आप लाखों छोटी वैल्यूज़ एन्कोड कर रहे हैं, तो स्पैन-आधारित API वह रिफ़ाइनमेंट है: TryToBase64Chars उस चर स्पैन में लिखता है जो आप नियंत्रित करते हैं और Boolean से सफलता बताता है, और System.Buffers.Text.Base64 आगे जाता है, सीधे उन UTF-8 बफ़र्स में एन्कोड करता है जो आप अलोकेट करते हैं, और डेटा को इन-प्लेस फुलाने तक जाता है:

Imports System
Imports System.Buffers
Imports System.Buffers.Text
Imports System.Text
Module BufferPacker
    Sub Main()
        Dim data() As Byte = {1, 2, 3, 4, 5}
        Dim textLength As Integer = Base64.GetMaxEncodedToUtf8Length(data.Length)
        Dim buffer(textLength) As Byte
        Dim written As Integer
        Dim consumed As Integer
        Dim status As OperationStatus = Base64.EncodeToUtf8(data, buffer, consumed, written)
        Dim packed As String = Encoding.ASCII.GetString(buffer, 0, written)
        Console.WriteLine(packed)
        ' AQIDBAU=
    End Sub
End Module

जो पैटर्न नोट करने लायक है वह है कि आप हेल्पर से बफ़र की साइज़ लगाते हैं, उसमें एन्कोड करते हैं, और सिर्फ़ इस्तेमाल हुई प्रीफ़िक्स को स्ट्रिंग में बदलते हैं, जिससे मध्यवर्ती सतह जितनी छोटी हो सकती है उतनी रहती है। और उन फ़ाइलों के लिए जो स्ट्रिंग्स को बेचैन करने के लिए पर्याप्त बड़ी हैं, स्ट्रीमिंग जोड़ी मेमोरी सपाट रखती है: ToBase64Transform ट्रांसफ़ॉर्म, CryptoStream में लपेटा हुआ, आपका इनपुट चंकों में पढ़ता है और एन्कोडेड टेक्स्ट बाहर लिखता है, इसलिए दो गिगाबाइट की फ़ाइल को कभी 2.7 गिगाबाइट की एक टुकड़ी वाली स्ट्रिंग बनना नहीं पड़ता:

Imports System.IO
Imports System.Security.Cryptography
Module StreamPacker
    Sub EncodeFile(ByVal inputPath As String, ByVal packedPath As String)
        Using inputStream As New FileStream(inputPath, FileMode.Open, FileAccess.Read)
            Using packedStream As New CryptoStream(New FileStream(packedPath, FileMode.Create), New ToBase64Transform(), CryptoStreamMode.Write)
                Dim buffer(65535) As Byte
                While True
                    Dim read As Integer = inputStream.Read(buffer, 0, buffer.Length)
                    If read = 0 Then Exit While
                    packedStream.Write(buffer, 0, read)
                End While
            End Using
        End Using
    End Sub
End Module

आगे की एक नोट: प्रिव्यू .NET 11 लाइब्रेरियाँ मौजूदा Base64 टाइप्स में नई सुविधा और स्पैन ओवरलोड जोड़ती हैं, इसलिए अगर आपका प्रोजेक्ट प्रिव्यू ट्रैक कर सकता है, तो टूलबॉक्स बढ़ता ही जाएगा; अगर नहीं, तो ऊपर की सब चीज़ें हर समर्थित रिलीज़ पर स्थिर हैं।

छोटा सा इतिहास: MSXML से स्पैन तक

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

मॉडर्न अध्याय छोटे हैं। 2018 में, .NET Core 2.1 ने अलोकेशन-हल्की TryToBase64Chars मीथड और निचली-स्तरीय स्पैन-आधारित System.Buffers.Text.Base64 क्लास जोड़ी। 2024 में, .NET 9 ने URL-सुरक्षित वर्णमाला को Base64Url के रूप में स्टैंडर्ड किया, जिसने दशक भर की हाथ-से-बनाई Replace कॉल ख़त्म कीं। 2026 तक, .NET 10 - नवंबर 2025 में रिलीज़ - वह लॉन्ग-टर्म-सपोर्ट रिलीज़ है जो सब कुछ ढोती है, और प्रिव्यू .NET 11 लाइब्रेरियाँ सुविधा मीथड्स की एक नई पीढ़ी जोड़ रही हैं, इसलिए एन्कोडर 2003 के वन-लाइनर से स्पैन युग तक उसी क्लास के तेज़ और सटीक बनने की कहानी है, कभी नया शुरू करने की नहीं।

रुचिकर तथ्य, VB एडिशन

InsertLineBreaks MIME के 76-चर के नियम को बिल्कुल दोहराता है, CRLF समेत, जिसका मतलब है कि जो लाइन ब्रेक्स आपका एन्कोडर 2026 में लिखता है, वे बाइट-दर-बाइट उसी आकार के हैं जैसे 1990 के दशक में एक ईमेल स्टैंडर्ड ने तय किए थे।
IsNot ऑपरेटर, जो Visual Basic 2005 के साथ जुड़ा, एक वक़्त में Microsoft की एक पेटेंट आवेदन के विषय के रूप में ख़बरों में आया। बहुत ही कम भाषा ऑपरेटर्स को उस पड़ाव का दावा करने का हक़ है।
पहला Visual Basic 1991 में शिप किया गया, जब World Wide Web का अस्तित्व तक नहीं था। तब तक जब डेटा URI स्कीम 1998 में सामने आई, तब तक Base64 ने पाँच साल से ईमेल एटैचमेंट्स ढोना शुरू कर दिया था, और VB ने तीन साल पहले, 1995 में Visual Basic 4 के साथ, 32-बिट भाषा के रूप में पनप चुका था।
AVX-512 वाले हार्डवेयर पर, रनटाइम एन्कोडर हर वेक्टर स्टेप में 48 बाइट्स प्रोसेस करता है, जो म्यूज़ियम में टेबल लुकअप और फैक्ट्री में कंवेयर बेल्ट के फ़र्क़ की तरह है।
My नेमस्पेस, Visual Basic की 2005 की मशहूर शुगर लेयर, को कभी Base64 हेल्पर जोड़ने की ज़रूरत नहीं पड़ी। System.Convert हमेशा एक नेमस्पेस इम्पोर्ट दूर था, एक दुर्लभ केस जहाँ VB रनटाइम ने फ्रेमवर्क द्वारा बताई जा चुकी कहानी में कुछ भी नहीं जोड़ा।

सिक्के का दूसरा पहलू

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

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

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