Decodifica Base64 in Visual Basic: una guida completa

Immagina la scena: una stringa atterra nel tuo progetto Visual Basic. Sembra un mazzo di carte mescolato di lettere e cifre, e ogni tanto ci casca dentro un segno più, una barra o un segno di uguale, e chi te l'ha mandata giura che un tempo era una frase perfettamente ordinaria, una JPEG o un blob di configurazione. Quella stringa è Base64, e questa pagina è la tua guida sul campo per riportarla a ciò che era. La buona notizia, subito: Visual Basic ha un decoder Base64 di prima classe dai primissimi tempi del .NET Framework, arriva dentro il runtime, e non devi installare il minimo pacchetto per usarlo.

Un rapido ripasso, perché la home page di questo sito spiega il formato nel dettaglio: Base64 scrive tre byte come quattro caratteri tratti da un alfabeto di 64 simboli, e uno o due caratteri = in coda segnano dove finivano i dati veri. Quindi il testo codificato è un po' gonfio rispetto all'originale: quattro caratteri per ogni tre byte in ingresso, circa un terzo in più. La decodifica rifà semplicemente questo scambio al contrario. Con la forma del problema in mente, apriamo qualche busta.

La famiglia dei decoder: un runtime, quattro ere

Tutto ciò che ti serve per decodificare vive nel runtime .NET. Negli ultimi vent'anni è cresciuto in quattro ondate, e le ondate più vecchie funzionano ancora esattamente come sempre, quindi le vedrai tutte in giro:

Una precisazione su Visual Basic prima di andare oltre. In un progetto VB il nome nudo Convert si risolve in System.Convert, perché i modelli di progetto standard importano per te l'namespace System, e nulla nel runtime di Visual Basic oscura quel nome. In ogni caso, questo articolo scrive per lo più la forma completa System.Convert: non costa nulla e rende l'intento inconfondibile per chiunque legga il codice.

Sulle versioni: .NET 10 è la release con supporto a lungo termine attuale (novembre 2025, supportata fino a novembre 2028), e sia .NET 8 sia .NET 9 restano supportati fino a novembre 2026, mentre .NET 11 è in anteprima e aggiunge una serie di nuovi metodi Base64 di convenienza. Le API di decodifica sono stabili su tutte. L'unica soglia di versione è Base64Url: è integrata a partire da .NET 9, e su .NET Framework 4.6.2 o più recente puoi portarla con il pacchetto Microsoft.Bcl.Memory. Niente di altro in questo articolo richiede un pacchetto.

Se parti da zero, il .NET SDK porta Visual Basic già in dotazione, quindi la cerimonia completa è questa:

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

Ottieni un piccolo Program.vb con Imports System in cima, e sei pronto a decodificare.

La riga unica: FromBase64String

Il novanta per cento della vita di decodifica in Visual Basic è una singola chiamata. Passale una stringa, e ti restituisce i byte esatti che erano impacchettati dentro:

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

Tre cose meritano di essere memorizzate. Prima, il risultato è byte, non testo: il decoder è orientato ai byte da capo a piedi, ed è esattamente ciò che vuoi, perché il carico utile può essere una frase, una JPEG, un certificato o un hash, e nessuno di questi va trattato in modo speciale. Trasformare quei byte in una stringa leggibile è un passo a sé, fatto con intenzione attraverso un oggetto Encoding, ed è lì che vive la tua decisione sul set di caratteri (ci arriviamo sotto). Secondo, FromBase64String alloca un array nuovo della misura esatta della lunghezza decodificata, così non trasporti mai capacità in eccesso. Terzo, "TWFu" si decodifica nella parola "Man", tre byte, zero sorprese, il che la rende il test di fumo perfetto per qualsiasi codice di decodifica che scrivi.

Ciò che il decoder perdona, ciò che rifiuta

Ecco dove il decoder .NET ha una personalità, e di quelle decise: è generoso su una cosa e spietato su tutte le altre. La cosa su cui è generoso sono gli spazi bianchi. Il decoder salta esattamente quattro caratteri, dovunque compaiano: lo spazio (U+0020), la tabulazione (U+0009), il feed di riga (U+000A) e il ritorno a carro (U+000D). Questa politica è un cenno intenzionale alla posta elettronica, dove i carichi utili Base64 arrivano avvolti in righe corte, e significa che un allegato avvolto in MIME si decodifica con zero pre-elaborazione. Un fatto curioso: questa tolleranza è condivisa da tutta la famiglia integrata, incluse le classi basate su span System.Buffers.Text.Base64 e quella sicura per URL Base64Url, quindi ottieni lo stesso comportamento permissivo a prescindere da quale API scegli. Qualsiasi cosa fuori dall'alfabeto di 64 simboli, qualsiasi violazione delle regole di lunghezza, o qualsiasi padding fuori posto merita un'eccezione. Ecco lo stesso decoder che incontra alcuni input diversi:

Quindi il contratto onesto è piccolo e memorabile: un riferimento Nothing lancia ArgumentNullException, un input vuoto o solo di spazi bianchi si decodifica in un array vuoto, un input valido si decodifica in byte, e tutto il resto che non è valido lancia un'eccezione ben precisa, FormatException.

Dai byte al testo: scegliere il set di caratteri

Nel momento in cui decidi che i byte decodificati sono in realtà testo, devi nominare un set di caratteri, perché i byte non sono testo finché non dici come leggerli. Le stringhe di Visual Basic sono internamente UTF-16, ma i byte che escono dal decoder sono stati fatti da qualcun altro, probabilmente con uno schema diverso, quindi devi adeguarti alla loro scelta. Il menu pratico:

• Encoding.UTF8: il predefinito sicuro per tutto ciò che ha viaggiato sul web o attraverso un'API. In caso di dubbio, parti da qui.
• Encoding.Unicode: UTF-16 little-endian, il sapore nativo di .NET. Ragionevole quando entrambi i lati dello scambio sono programmi .NET che hanno scelto esplicitamente UTF-16.
• Encoding.ASCII: solo 7 bit. I byte non ASCII vengono sostituiti con un punto interrogativo, quindi è una scelta con perdita di informazioni che distrugge silenziosamente gli accenti.
• Encoding.Default: su .NET Framework era la code page ANSI della macchina, ma su .NET (Core) è sempre UTF-8 a prescindere dalla localizzazione. Evitala comunque per i dati che scambi - nomina la codifica esplicitamente, di solito Encoding.UTF8.

Imports System
Imports System.Text
Module CharsetDemo
    Sub Main()
        ' La parola "Café" immagazzinata come byte 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

Leggi quegli stessi cinque byte con Encoding.Unicode invece e ottieni una stringa corta e senza senso - un paio di caratteri strani dell'intervallo CJK più un segno di sostituzione - perché il decoder accoppia i byte a due a due. Leggi i byte UTF-8 di "Café" con Encoding.ASCII e l'accento diventa ??, una coppia di punti interrogativi, perché l'accento è due byte in UTF-8. Nessuna di queste scelte lancia un'eccezione; producono semplicemente il testo sbagliato in silenzio, ed è per questo che il set di caratteri è una decisione che prendi di proposito, non un predefinito che erediti.

L'alfabeto sicuro per URL: Base64Url

Il Base64 standard usa + e /, e entrambi questi caratteri portano i loro significati dentro gli URL, quindi un alfabeto standard può rompere un link nel momento in cui atterra in una stringa di query. La soluzione, standardizzata nella sezione 5 di RFC 4648, è la variante sicura per URL e nomi di file: lo stesso schema di 64 caratteri con - al posto di + e _ al posto di /, con il padding in coda di solito omesso perché è implicito dalla lunghezza. Incontrerai questo alfabeto nei JWT, nei token API e ovunque il Base64 viaggi dentro un URL. .NET 9 ha aggiunto una classe dedicata, System.Buffers.Text.Base64Url, ed è un piacere usarla:

Imports System.Buffers.Text
Imports System.Text
Module UrlSafeOpener
    Sub Main()
        ' Input sicuro per URL, senza padding in coda
        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

Due comportamenti meritano di essere conosciuti. L'encoder Base64Url produce output senza padding per progettazione, ma il suo decoder accetta input con e senza padding, quindi è amichevole con i dati di altri ecosistemi. E Base64Url.IsValid ti permette di pre-verificare una stringa candidata prima di decodificare, il che è comodo quando i dati arrivano dal mondo esterno. Se sei fermo su un runtime più vecchio senza la classe, la conversione è due scambi di caratteri e una reintegrazione del padding, esattamente il contrario di ciò che ha fatto l'encoder:

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

Su .NET Framework 4.6.2 o più recente puoi invece installare il pacchetto NuGet Microsoft.Bcl.Memory e usare la vera classe Base64Url. In ogni caso, la regola è semplice: riconosci l'alfabeto dal contesto (URL, JWT, token API), poi scegli il decoder corrispondente.

Aprire i file

Uno degli usi più antichi del Base64 è contrabbandare binari attraverso file di testo: un file .b64 o .txt che contiene byte codificati. In Visual Basic il viaggio di andata e ritorno sono due chiamate di file e una decodifica. Leggi il testo, decodificalo, scrivi i byte:

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

La tolleranza verso gli spazi bianchi rende il tutto robusto in un modo appagante: al file non importa se il carico utile è stato scritto in una riga lunghissima, avvolto a 76 caratteri, o avvolto a 64, perché il decoder salta gli a capo in entrambi i casi. Tieni in tasca un fatto sulle dimensioni: il file di testo è circa un terzo più grande del binario che nasconde, quindi un file da 10 megabyte arriva come circa 13,3 megabyte di caratteri. Nulla di drammatico, ma è il numero da ricordare quando un file di testo "piccolo" sembra grande.

Immagini e data URI

Lo schema data URI (RFC 2397) lascia che un URL trasporti il proprio contenuto: data: seguito dal media type, dal marcatore letterale ;base64, da una virgola, e poi dai byte codificati. L'hai visto dappertutto sul web, in HTML e CSS, dove incorpora piccole immagini e font direttamente nel markup invece di puntare a un file separato. In Visual Basic, aprirne uno è solo uno spezzamento di stringa e una decodifica. L'esempio sotto estrae un PNG da un data URI e ne costruisce un'immagine 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

Nota il controllo difensivo sull'intestazione: un data URI senza il marcatore ;base64 contiene invece dati URL-escaped, e decodificarlo come Base64 fallirebbe o produrrebbe spazzatura. Lo stesso RFC avverte che i data URI sono utili solo per valori corti, e l'HTML ha i suoi limiti di lunghezza sugli attributi, quindi trattalo come lo strumento giusto per icone, avatar e miniature, non per spedire l'intera libreria fotografica in un attributo.

HTTP, API e Basic Auth

Il Base64 è dappertutto nelle API web, e le due apparizioni più comuni sono l'intestazione HTTP di Basic auth e i campi JSON che portano dati binari o precodificati. La Basic auth è il caso più semplice: il client invia Authorization: Basic seguito dal Base64 di username:password. Decodificarlo in Visual Basic è un controllo del prefisso e una chiamata:

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

La funzione restituisce username:password come una singola stringa, che poi spezzi sul due punti. L'altro caso quotidiano è una risposta JSON dove qualche campo è un blob precodificato, come un'immagine o un certificato. Con HttpClient e System.Text.Json (System.Text.Json è in dotazione dal .NET Core 3.0, e HttpClient da molto prima) lo schema è lineare:

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

Due note di buon ordine. Non stampare mai un'credenziale decodificata in un log o in un'interfaccia solo perché puoi, e non fare mai affidamento sulla Basic auth sopra HTTP semplice, perché altrimenti avresti semplicemente scritto la password in un alfabeto più interessante.

JWT: leggere i tre pezzi

Un JSON Web Token nella sua forma compatta è composto da tre pezzi di Base64Url separati da punti: l'intestazione, il carico utile e la firma. I primi due sono JSON semplice che puoi leggere a occhio (o con una chiamata di decodifica), mentre il terzo è una firma crittografica che va verificata con la chiave giusta, non decodificata. Un token di esempio, preso da una demo comune, è questo: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIn0.W-5gI_FdnMBdpgG4twX96rptvh13gmXQ75kKLRXVaGs. Leggerne il carico utile in Visual Basic significa spezzare sui punti, riconvertire l'alfabeto sicuro per URL in quello standard, e decodificare:

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
        ' Riconverti l'alfabeto sicuro per URL in quello standard
        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

Eseguilo contro il token di esempio e ottieni il JSON {"sub":"1234567890","name":"John Doe"}. Leggi l'intestazione allo stesso modo e ottieni {"alg":"HS256","typ":"JWT"}. L'avvertimento che conta qui: leggere un JWT non è verificarlo. Chiunque può creare un token, quindi prima di fidarti di qualunque affermazione al suo interno, convalida la firma con la chiave dell'emittente. Per quel lavoro, il pacchetto NuGet System.IdentityModel.Tokens.Jwt (la suite IdentityModel del team Microsoft Entra) gestisce per te i dettagli del Base64Url, il controllo della firma e l'analisi delle affermazioni, ed è esattamente il livello dove non vuoi improvvisare da solo.

Allegati email, avvolto a 76 caratteri

La posta è dove il Base64 si è fatto il nome. Lo SMTP è stato progettato per ASCII a 7 bit, quindi un allegato binario deve diventare testo prima di poter volare, e lo standard MIME (RFC 2045) ha scelto il Base64 con un limite di 76 caratteri a riga, un parente stretto delle ancora più vecchie righe da 64 caratteri del PEM. Se hai mai ricevuto una email grezza, hai visto il risultato: un blocco di Base64 denso, spezzato in righe corte e ordinate, sotto un'intestazione Content-Transfer-Encoding: base64. La parte bella, per un decoder, è che non devi disfare niente. Il decoder .NET salta gli a capo e gli spazi dovunque compaiano, quindi il blocco avvolto si decodifica così com'è:

Imports System
Imports System.Text
Module MimeOpener
    Sub Main()
        ' Una frase di 59 byte, avvolta in MIME a 76 caratteri con CRLF
        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

Se lavori con le classi System.Net.Mail, la decodifica è ancora più invisibile: un Attachment che aggiungi a una MailMessage porta un ContentEncoding di TransferEncoding.Base64, e la libreria di posta avvolge, invia e disfa l'intero rituale per te. Ti serve la decodifica manuale solo quando leggi MIME grezzo da uno stream, da un fixture di test, o da un file di casella di posta di vecchia generazione.

Database, configurazione e variabili d'ambiente

L'archiviazione solo testo continua a chiedere Base64: una colonna di database tipata come testo, un valore di configurazione XML, una variabile d'ambiente. Tutti vogliono caratteri semplici, quindi i binari vengono codificati prima di essere memorizzati e decodificati quando tornano. Il lato decodifica è sempre la stessa riga unica, e la parte interessante è il calcolo delle dimensioni. Una colonna NVARCHAR normale in SQL Server arriva a un massimo di 8.000 caratteri, il che significa circa 6.000 byte di binario prima che la tassa del 33 per cento ti faccia sforare; oltre, prendi le varianti MAX o, più onestamente, una vera colonna binaria. Su Windows, una singola variabile d'ambiente definita dall'utente è limitata a 32.767 caratteri (e sui sistemi dell'era XP l'intero blocco d'ambiente era limitato a quella misura), quindi l'idea di "memorizzare tutto il blob della licenza in una variabile d'ambiente" ha un soffitto rigido. Ecco uno schema di decodifica che vale la pena tenere in un angolo della testa: confrontare un'impronta memorizzata con un file, con un confronto a tempo costante in modo che una discrepanza non lasci trapelare informazioni di tempo:

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

La stessa forma funziona per qualsiasi hash memorizzato: decodifica il valore memorizzato, calcola l'hash fresco e confronta a tempo fisso. I file di configurazione seguono lo schema identico, che il valore venga da una voce XML app.config, da un file di impostazioni JSON o da una stringa di registro.

Dati di grandi dimensioni: decodificare uno stream senza caricarlo

Ogni esempio finora ha letto l'intero carico utile in memoria, il che va bene per allegati e valori di configurazione ma è sbagliato per un file da due gigabyte che qualcuno ha codificato in un file di testo. Per quella scala, .NET ha una coppia in streaming che esiste dal .NET Framework 1.1 (2003): la trasformazione crittografica FromBase64Transform avvolta in una CryptoStream. Leggi pezzi di testo codificato, la trasformazione li decodifica al volo, e scrivi i byte in uscita, quindi la memoria resta piatta per quanto grande sia il file:

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

Poiché il file codificato è semplice testo ASCII, leggerlo come stream di byte è perfettamente sicuro, e la trasformazione gestisce l'avvolgimento delle righe senza che tu faccia niente. Il file in uscita viene fuori a circa tre quarti della dimensione dell'ingresso, che è la stessa tassa del 33 per cento pagata in entrata, riscossa in uscita.

Insidie che mordono il Visual Basic in particolare

La maggior parte delle trappole di questa sezione è condivisa con altri linguaggi .NET, ma alcune portano un cappello marcatamente VB, quindi ecco tutte insieme:

• Byte rispetto a Byte(). In Visual Basic un singolo byte è Byte e un array di byte è Byte(), con le parentesi vuote a fare tutto il lavoro. Scrivere Dim b As Byte quando intendevi Byte() è l'errore classico del primo giorno, ed è esattamente il genere di cose che Option Strict On cattura al momento della compilazione. Se il tuo progetto non ce l'ha già attivata, attivala: il modello dotnet new console -lang VB lascia la decisione a te, mentre i modelli di progetto di Visual Studio la impostano.
• Il muro degli span. Le moderne API basate su span sono richiamabili da VB, ma solo nel punto di chiamata: puoi passare un array Byte() o Char() direttamente a un metodo che accetta uno span, e il compilatore lo converte per te. Ciò che non puoi fare è dare un nome a uno span nel tuo codice. Dichiarare una variabile, un campo o un parametro di tipo Span o ReadOnlySpan fa sì che il compilatore risponda con "Types with embedded references are not supported in this version of your compiler". Quindi l'idioma VB è: chiama le API span con array semplici, e non tentare mai di immagazzinare uno span in una variabile.
• BitConverter non è Base64. BitConverter.ToString(bytes) rappresenta i byte in esadecimale, separati da trattini, il che lo rende una risposta sbagliata tentante per chiunque abbia sentito "converti byte in stringa". Ti consegnerà volentieri 4D-61-6E quando l'API si aspetta TWFu. In caso di dubbio, vai su System.Convert.
• MidB è un fantasma. Il Visual Basic classico aveva funzioni di stringa a livello di byte, MidB, LeftB e RightB, pensate per set di caratteri a doppio byte. Oggi ogni stringa .NET è Unicode, e la documentazione del runtime è diretta: non sono più supportate. Se uno snippet di vecchia generazione le usa, riscrivilo con array di byte e le API di questo articolo.
• Encoding.Default segue la macchina. La storia della divergenza per localizzazione è quella del .NET Framework: sul .NET moderno, Default è sempre UTF-8, quindi gli stessi byte si decodificano allo stesso modo dappertutto. Per i dati che condividi, nomina la codifica esplicitamente, di solito Encoding.UTF8 - il consiglio vale in entrambi i casi.
• I viaggi di andata e ritorno non sono identità. Se decodifichi una stringa e poi codifichi il risultato, la nuova stringa non è garantita che combaci con quella originale: gli spazi bianchi spariscono, e il padding viene normalizzato. Un carico utile con a capo torna come una riga pulita. Va bene per i dati, è pericoloso se la tua logica confronta il testo codificato invece dei byte decodificati.
• Un input solo di spazi bianchi è un successo silenzioso. Una stringa fatta solo di spazi e a capo si decodifica in un array di byte vuoto senza alcun errore, il che significa che "l'utente ha incollato solo a capo" sembra esattamente come "l'utente ha incollato un carico utile vuoto". Se la distinzione conta, controlla la lunghezza dell'input prima di decodificare.

Migliori pratiche per la decodifica

Distillato da tutto quanto sopra, le abitudini che tengono il codice di decodifica noioso (nel senso migliore):

• Tratta il Base64 come trasporto, non come protezione. È una codifica, non una cifratura: chiunque può leggere l'originale con una chiamata di funzione, e l'RFC 4648 fa persino notare che una gestione approssimativa dell'alfabeto può aprire canali coperti. Cifra prima, poi codifica se devi nascondere contenuti.
• Per input non fidati, preferisci i metodi Try o una pre-verifica con IsValid al lasciare volare FormatException. Un booleano è più facile da trasformare in un messaggio di errore cordiale di quanto non lo sia ingoiare un'eccezione.
• Scegli il set di caratteri deliberatamente, e usa UTF-8 come predefinito a meno di non avere una ragione documentata per uno schema diverso.
• Abbina l'alfabeto alla fonte: Base64 standard per MIME, email e configurazione; Base64Url per JWT e tutto ciò che è dentro un URL.
• Metti in streaming tutto ciò che è grande attraverso FromBase64Transform e CryptoStream invece di caricarlo in una stringa.
• Confronta impronte e hash con CryptographicOperations.FixedTimeEquals, non con =, in modo che il tempo non lasci trapelare quanta parte del valore combaciava.
• Mantieni Option Strict On in modo che la famiglia di scivoloni Byte/Byte() sia un errore di compilazione invece di un mistero in produzione.

Come il Visual Basic ha ottenuto il suo decoder

La storia comincia in un'epoca in cui Visual Basic non aveva alcun Base64. Nel mondo di Visual Basic 6 e VBA (il linguaggio di macro ancora in funzione dentro Excel e Office oggi), gli sviluppatori che avevano bisogno di Base64 lo prendevano in prestito dai componenti COM già presenti sulla macchina. Il trucco famoso usava un elemento XML DOM: il parser MSXML lascia che un nodo dichiari il proprio DataType come bin.base64, quindi assegnando una stringa Base64 alla proprietà text del nodo e rileggendone il nodeTypedValue ottieni i byte grezzi, con il DOM a fare il vero calcolo Base64 (la proprietà Charset dell'oggetto ADO Stream capisce solo nomi di set di caratteri veri come "utf-8" o "iso-8859-1", non "base64", ed è per questo che il trucco usa MSXML invece). La codifica procedeva con la stessa idea al contrario, scrivendo byte in nodeTypedValue e rileggendo la stringa codificata da text:

' Il classico trucco di decodifica VB6 / VBA, per contesto
Dim node As Object
Set node = CreateObject("MSXML2.DOMDocument").createElement("b64")
node.DataType = "bin.base64"
node.text = packed            ' la stringa Base64
Dim bytes() As Byte
bytes = node.nodeTypedValue

Funzionava, era ingegnoso, ed è la ragione per cui "base64 VBA" accende ancora i motori di ricerca a tre decenni di distanza. Poi il 2002 ha cambiato tutto: Visual Basic 7.0 (la prima versione .NET del linguaggio, all'epoca chiamata Visual Basic .NET) è entrato nel nuovo Common Language Runtime, e il .NET Framework ha portato System.Convert con FromBase64String e i suoi amici in dotazione. Dal .NET Framework 1.1 del 2003, ogni programma VB aveva un decoder di prima classe senza componenti da registrare. L'onda moderna è arrivata nel 2018 con .NET Core 2.1, che ha aggiunto i metodi Try senza eccezioni e la veloce classe basata su span System.Buffers.Text.Base64, e nel 2024 con .NET 9, che ha finalmente standardizzato l'alfabeto sicuro per URL come Base64Url. A partire dal 2026, .NET 10 - rilasciato a novembre 2025 - è la release con supporto a lungo termine, e le librerie .NET 11 in anteprima stanno aggiungendo una nuova generazione di metodi Base64 di convenienza, quindi il decoder continua a migliorare mentre la riga unica originale del 2003 va avanti invariata.

Fatti curiosi dal mondo VB

• Il compilatore ufficiale di Visual Basic è a sua volta scritto in Visual Basic. Come parte del progetto open source Roslyn, il linguaggio si compila da solo.
• Il primissimo Visual Basic è uscito nel 1991, prima che l'era del web prendesse slancio. Il grande momento del Base64 è arrivato con il MIME nel 1993, e il VB stesso ha sviluppato una capacità a 32 bit due anni dopo, quando il Visual Basic 4 del 1995 rese possibili per la prima volta programmi a 32 bit. Il VB 5 del 1997 andò fino in fondo: solo 32 bit, nessun 16 bit rimasto nella scatola.
• Le funzioni a livello di byte MidB, LeftB e RightB del VB classico sono ufficialmente "non più supportate" in .NET, perché ogni stringa VB è Unicode dal primo giorno del framework. Un'intera famiglia di API, in pensione per una scelta di codifica.
• Il meccanismo Base64 del runtime non è una graziosa ricerca in tabella: l'implementazione moderna esegue percorsi di codice vettorizzati in hardware (varianti AVX-512, AVX2 e SSE) quando la macchina li supporta, quindi "lento codec di testo" non è ciò che succede sotto il cofano.
• Il trucco bin.base64 di MSXML dell'era VB6 gira ancora oggi in macro Excel di produzione, il che significa che una soluzione alternativa della fine degli anni Novanta e una chiamata a Convert del 2003 coesistono felici nella base di codice della stessa organizzazione.

Prima di andare

Questo articolo ha coperto il lato decodifica del Base64 in Visual Basic, dalla riga unica allo streaming, dai JWT alle insidie che portano un cappello VB. L'altra faccia della medaglia, trasformare in primo luogo i tuoi byte e il tuo testo in Base64, ha il suo set di decisioni su padding, a capo e tassa sulle dimensioni, ed è coperta in pieno dettaglio nell'articolo di codifica gemello sul sito sorella. Il link si trova proprio sotto questa riga, e lo strumento nella home page resta il modo più veloce per controllare un piccolo carico utile a mano.

Ultimo aggiornamento: 2026-09-08

Articolo correlato: Codifica Base64 in Visual Basic: una guida completa