Codifica e decodifica Base64
Codifica testo o file in Base64 e decodifica stringhe in byte nel browser. Esempi di padding, alfabeto RFC 4648 e variante URL-safe.
Tutti i calcoli vengono eseguiti nel browser. Nulla di ciò che inserisci viene inviato a un server.
I risultati si aggiornano mentre digiti. Ctrl/Cmd+Invio copia il risultato principale.
Risultato
—
Vista bit
Mostra il procedimento
Codifica e decodifica Base64 converte byte arbitrari in una stringa ASCII usando l'alfabeto RFC 4648 e inverte quella stringa fino ai byte originali. La modalità testo accetta una codifica caratteri come UTF-8; la modalità file legge un upload tramite FileReader del browser e può emettere un URI data: per l'incorporamento. La codifica non è crittografia. Chiunque riceva la stringa può decodificarla.
Tutta la codifica e la decodifica avviene nel browser. Nulla di ciò che incolli viene inviato a un server.
Codificare testo o un file in Base64
La codifica prende byte grezzi e scrive una stringa di A a Z, a a z, 0 a 9, più, barra e padding =. Incolla testo o scegli un file, seleziona la codifica caratteri quando la sorgente è testo e leggi l'output.
La modalità file conviene per piccole immagini e documenti che devono viaggiare dentro JSON, XML o email senza un canale binario.
L'output è sicuro per il trasporto attraverso sistemi che corrompono binario arbitrario, come gateway mail più vecchi o copia-incolla in XML. È più lungo dell'input per progettazione. Input vuoto non valido non produce stringa; lo strumento attende byte prima di emettere caratteri.
Decodificare una stringa Base64 in dati
La decodifica inverte la ricerca nell'alfabeto, ricostruisce il flusso di bit originale e restituisce testo o un file scaricabile. I caratteri di padding = alla fine sono significativi: segnalano quanti byte erano nel gruppo finale incompleto. Caratteri fuori dall'alfabeto causano un errore chiaro invece di una decodifica parziale silenziosa.
Gli spazi bianchi sono spesso ignorati così le stringhe copiate da certificati PEM o corpi MIME funzionano ancora. Una stringa che sembra Base64 ma usa l'alfabeto URL-safe richiede la modalità di decodifica URL-safe, altrimenti trattino e underscore vengono rifiutati come illegali nell'alfabeto standard.
Capire come funziona la codifica Base64
Base64 elabora l'input in blocchi di tre byte (24 bit). Quei 24 bit sono divisi in quattro gruppi da 6 bit. Ogni valore a 6 bit è un indice da 0 a 63 nell'alfabeto a 64 caratteri. Tre byte di input diventano quindi quattro caratteri di output.
Bytes: [ byte1 ][ byte2 ][ byte3 ]
Bits: aaaaaaaa bbbbbbbb cccccccc
Groups: aaaaaa aabbbb bbbbcc cccccc
Chars: Char1 Char2 Char3 Char4Quando restano meno di tre byte, l'encoder emette comunque quattro caratteri ma aggiunge padding così il decoder conosce la lunghezza originale. Il raggruppamento dei bit è l'intero algoritmo; non c'è checksum e non c'è chiave.
Codificare la parola Dog passo passo
La parola Dog sono tre byte ASCII, quindi riempie un gruppo Base64 e si codifica senza caratteri di padding. L'output di riferimento è RG9n. Percorrendo i byte fino ai bit, raggruppandoli in indici a 6 bit e leggendo l'alfabeto RFC 4648 si capisce perché compaiono quei quattro caratteri e come ogni blocco da tre byte segue lo stesso percorso.
1. Scrivere i byte. D = 0x44 = 01000100 o = 0x6F = 01101111 g = 0x67 = 01100111
2. Concatenare 24 bit. 01000100 01101111 01100111
3. Dividere in gruppi da 6 bit. 010001 000110 111101 100111
4. Convertire ogni gruppo in indice decimale. 17, 6, 61, 39
5. Consultare l'alfabeto. Indice 17 = R, 6 = G, 61 = 9, 39 = n
Risultato: RG9n. Decodificare RG9n restituisce i tre byte originali e il testo Dog con UTF-8 o ASCII.
Capire il padding con il segno uguale
Il padding compare quando il conteggio byte non è multiplo di tre. Un byte rimasto produce due caratteri dell'alfabeto e due segni =. Due byte rimasti producono tre caratteri e un =. I riferimenti Do → RG8= e Dogs → RG9ncw== mostrano entrambi i casi di resto accanto alla parola da tre byte senza padding Dog.
| Input | Bytes | Codificato | Padding |
|---|---|---|---|
| Dog | 3 | RG9n | nessuno |
| Do | 2 | RG8= | un = |
| Dogs | 4 | RG9ncw== | due = |
Do sono due byte: 01000100 01101111. Dopo il raggruppamento a 6 bit ci sono bit sufficienti solo per tre caratteri significativi (RG8), e un padding = riempie la quarta posizione. Dogs sono quattro byte: un gruppo completo da tre byte che codifica come RG9n, poi un resto da un byte che codifica come cw==. Rimuovere il padding a mano senza regolare la lunghezza in bit rompe la decodifica; lasciare i caratteri = al loro posto quando incolli.
Leggere l'alfabeto Base64
RFC 4648 definisce 64 caratteri più il segno di padding =. Gli indici da 0 a 25 sono A a Z, da 26 a 51 sono a a z, da 52 a 61 sono 0 a 9, l'indice 62 è + e l'indice 63 è /.
L'indice 0 è A, non 0, cosa che inganna chi si aspetta che le cifre guidino l'alfabeto.
| Intervallo indice | Caratteri |
|---|---|
| 0 a 25 | A a Z |
| 26 a 51 | a a z |
| 52 a 61 | 0 a 9 |
| 62 | + |
| 63 | / |
| padding | = |
Il pannello alfabeto della calcolatrice elenca la stessa tabella usata dall'encoder, così un carattere sospetto può essere controllato rispetto al set standard. La stringa completa è ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/.
Usare la variante Base64 URL-safe
L'alfabeto URL-safe (base64url) sostituisce + con - e / con _. In alcuni protocolli il padding può essere omesso. I JSON Web Token usano questa variante così i segmenti del token possono stare in URL e intestazioni HTTP senza percent-encoding dei caratteri più e barra.
Le stringhe standard e URL-safe non sono intercambiabili. Decodificare un payload JWT con l'alfabeto standard fallisce sugli trattini. Lo strumento offre una modalità URL-safe esplicita sia per codifica che decodifica. Il percent-encoding di un URL è un problema diverso; usa la pagina Codifica e decodifica URL quando l'obiettivo è l'escape RFC 3986 piuttosto che Base64.
Tenere conto dell'aumento di dimensione
Ogni tre byte diventano quattro caratteri, quindi la lunghezza codificata è circa 4/3 dell'input, un aumento del 33 percento prima delle interruzioni di riga. Il padding può aggiungere uno o due caratteri extra sull'ultimo gruppo. Gli URI dati e gli allegati email sentono subito questo costo: un'immagine da 300 KB diventa circa 400 KB di testo.
encoded_length ≈ 4 × ceil(byte_length / 3)L'andare a capo ogni 76 caratteri, comune in MIME, aggiunge byte di newline sopra. Preferisci allegati binari o formati compressi quando conta la dimensione; usa Base64 quando il canale davvero non può trasportare byte grezzi.
Scegliere una codifica caratteri
Base64 codifica byte, non caratteri astratti. Le stesse lettere producono byte diversi con UTF-8, UTF-16, Shift JIS o Big5. Decodificare poi interpretare con charset sbagliato produce mojibake anche quando lo strato Base64 era perfetto, quindi il charset della modalità testo deve corrispondere al produttore in codifica e al consumatore in decodifica.
| Charset | Uso tipico |
|---|---|
| UTF-8 | Predefinito per testo moderno e API |
| Windows-1252 | Testo europeo occidentale legacy |
| UTF-16 LE / BE | Alcuni payload Windows e Java |
| Shift JIS | Testo giapponese più vecchio |
| Big5 | Testo cinese tradizionale più vecchio |
Per la parola Dog, ASCII e UTF-8 producono gli stessi tre byte, quindi RG9n è identico. Il testo non ASCII diverge. Scegli il charset che corrisponde al produttore prima di codificare, e lo stesso charset dopo la decodifica, altrimenti il round trip sembrerà un bug Base64 quando l'errore è a monte.
Domande frequenti
Base64 è crittografia?
No. Base64 è una codifica che chiunque può invertire con l'alfabeto pubblico. Non nasconde nulla. Usa un algoritmo crittografico reale quando serve riservatezza; usa Base64 quando un canale ha bisogno di byte sicuri per ASCII.
Perché l'output Base64 termina con segni uguale?
I caratteri = sono padding. Segnalano che l'ultimo gruppo di input aveva uno o due byte invece di tre. Do codifica in RG8= e Dogs in RG9ncw==. Mantieni il padding in decodifica a meno che il protocollo documenti che è stato rimosso.
Cosa codifica Dog?
Dog codifica in RG9n senza padding, perché tre byte riempiono esattamente un gruppo Base64. Il raggruppamento bit passo passo è mostrato nell'esempio svolto su questa pagina.
Qual è la differenza tra Base64 standard e URL-safe?
Base64 URL-safe usa - e _ invece di + e /. JWT e alcuni embedding nei nomi file usano l'alfabeto URL-safe. Decodificare con l'alfabeto sbagliato fallisce su quei caratteri sostituiti.
Quanto è più grande Base64 rispetto all'originale?
Circa un terzo in più. Tre byte diventano quattro caratteri, quindi il rapporto è 4/3 prima di padding e interruzioni di riga. Un payload da 3.000 byte diventa 4.000 caratteri Base64.
Base64 può codificare un file, non solo testo?
Sì. La modalità file legge l'upload nel browser e codifica i suoi byte grezzi. Il percorso inverso decodifica in un blob scaricabile. File grandi aumentano l'uso di memoria nella scheda; mantieni upload modesti.
Perché il testo decodificato sembra sbagliato dopo una decodifica corretta?
Lo strato Base64 ha ripristinato i byte, ma la codifica caratteri usata per interpretare quei byte non corrisponde al produttore. Prova prima UTF-8, poi il charset che il sistema sorgente usa davvero.
Questo strumento carica segreti incollati?
No. Codifica e decodifica avvengono in locale. Chiavi API, token e frammenti di certificato incollati nella casella non vengono inviati a un server. Questa promessa corrisponde alla regola di progettazione per tutte le pagine di codifica su Quick Calculators.
Base64 è uguale alla codifica URL?
No. Base64 mappa binario in un alfabeto a 64 caratteri per il trasporto. La codifica URL (percent-encoding) fa escape dei caratteri riservati dentro gli URI secondo RFC 3986. Risolvono problemi diversi e non sono sostituti l'uno dell'altro.
Quale RFC definisce l'alfabeto?
RFC 4648 definisce gli alfabeti Base64 standard e URL-safe e le regole di padding usate qui. Documenti più vecchi come RFC 2045 descrivono Base64 nel contesto MIME con meccanismi simili.
Riepilogo
Codifica e decodifica Base64 mappa byte nell'alfabeto RFC 4648 in gruppi da 6 bit e inverte il processo localmente nel browser. Dog diventa RG9n, Do diventa RG8= e Dogs diventa RG9ncw==, illustrando il padding per resti da uno e due byte.
L'alfabeto URL-safe scambia +// con -/_, l'output cresce di circa un terzo e la scelta del charset decide quali byte la modalità testo alimenta all'encoder. Nulla di incollato viene caricato.