Che cos'è la Base64?
La Base64 riscrive i byte usando sessantaquattro caratteri leggibili, così i dati sopravvivono a un canale costruito per il testo: il corpo di un'email, una stringa JSON, un attributo XML, un URL. Ogni tre byte diventano quattro caratteri, ed è da lì che viene il nome — l'alfabeto contiene sessantaquattro simboli e ciascuno porta esattamente sei bit.
È una codifica di trasporto, non una misura di sicurezza e non un passaggio di compressione. L'output è circa un terzo più grande dell'input, e chiunque abbia la stringa può riportarla subito indietro. Se si vuole sapere se i dati sono stati alterati, serve un hash (Generatore di hash); se si vogliono mantenere segreti, serve la crittografia. La Base64 non fa nessuna delle due cose.
L'unico numero da ricordare: tre byte di input diventano quattro caratteri di output. Tutto il resto di questa pagina ne deriva. Quattro caratteri portano ventiquattro bit, e ventiquattro bit corrispondono esattamente a tre byte, quindi nessun dato viene mai perso o inventato — tranne alla fine, dove l'input potrebbe non riempire l'ultimo gruppo di tre.
I cinque alfabeti che questa pagina può usare
Le prime due righe sono standard e le ultime tre sono convenzioni nate intorno a Unix. Tutte e cinque portano gli stessi sei bit per carattere e differiscono solo per quali sessantaquattro caratteri li portano, quindi gli stessi byte diventano cinque stringhe diverse. Nessun elemento all'interno di una stringa dice quale alfabeto l'ha prodotta, ed è per questo che il selettore dell'alfabeto parte dallo standard e che la casella sicura per URL è una scorciatoia per la seconda riga.
Come la pagina sceglie un candidato: il selettore è il predefinito per entrambe le direzioni. In decodifica, il pannello a destra legge anche la stringa stessa — - e _ possono venire solo dall'alfabeto sicuro per URL, + o / solo da quello standard, e una / o un . vicino all'inizio indicano i due alfabeti Unix. Ogni alfabeto che può leggere l'input corrente è elencato lì, con il motivo per cui è o non è un candidato.
A capo: 76 e 64 caratteri
La MIME ha richiesto una Base64 che stia in un'email senza che nessuna riga diventi eccessivamente lunga, e ha stabilito 76 caratteri per riga separati da CRLF. I file PEM, che racchiudono certificati e chiavi, usano 64. Le interruzioni di riga non fanno parte dei dati: un decodificatore le elimina e riunisce le righe prima di fare qualunque altra cosa, quindi una stringa con a capo e una senza decodificano esattamente negli stessi byte. Ogni riga tranne l'ultima contiene un numero intero di gruppi di quattro caratteri, ed è ciò che rende sicuro riunirle.
Questa pagina lascia l'output su una sola riga a meno che non si scelga una larghezza, e il decodificatore accetta input con o senza interruzioni di riga. Le interruzioni scritte da questa pagina sono semplici line feed, che è ciò che una casella di testo può contenere; i corpi delle email MIME tradizionalmente usano un carriage return prima di ogni line feed, e tutti i decodificatori in uso accettano entrambi.
Il riempimento, e perché può essere eliminato
Quando l'input non è un multiplo di tre byte, l'ultimo gruppo di quattro caratteri è incompleto, e uno o due caratteri = lo completano. Non portano alcun dato: dicono solo quanti dei quattro caratteri sono reali. Un decodificatore può ricavarlo dalla lunghezza, ed è per questo che la Base64 sicura per URL tradizionalmente omette il riempimento — un = è scomodo in un URL o in un nome di file, e alcuni sistemi lo codificano in percentuale.
La casella nella riga delle opzioni mantiene il riempimento quando è selezionato l'alfabeto sicuro per URL. Nient'altro cambia; i caratteri che portano dati sono identici in entrambi i casi.
Equivoci comuni
- "La Base64 nasconde i dati." No. È una sostituzione senza chiave, e il punto è proprio che qualunque lettore può annullarla. Mettere una password o un token in Base64 non cambia nulla su chi può leggerla.
- "La Base64 comprime." Il contrario: ogni tre byte di input diventano quattro caratteri di output, quindi il testo è un terzo più grande dei dati che trasporta.
- "Le interruzioni di riga fanno parte del valore." Sono presentazione. Aggiungerle o toglierle non cambia mai i byte che vengono restituiti.
- "Sicuro per URL significa una codifica diversa." È la stessa codifica con due caratteri scambiati:
+ diventa - e / diventa _, quindi la stringa può stare in un percorso URL o in un valore di query senza escape. - "Una stringa che si decodifica deve essere Base64 valida." Qualsiasi stringa di caratteri dell'alfabeto è una Base64 valida, perché ogni combinazione di valori a sei bit è una sequenza valida di byte. Una stringa risulta sbagliata solo al passo successivo, quando quei byte vengono verificati contro il formato che avrebbero dovuto avere.
- "Il riempimento indica quale alfabeto è stato usato." No, e nella maggior parte dei casi non lo fanno nemmeno i caratteri: lo standard e l'alfabeto sicuro per URL concordano su sessantadue dei loro sessantaquattro simboli, quindi una stringa breve spesso si legge allo stesso modo in entrambi.
Domande ricorrenti
Perché una stringa Base64 a volte finisce con un = e a volte con due? Uno significa che l'ultimo gruppo porta tre caratteri reali, cioè due byte di input; due significa che ne porta due, cioè un byte di input. Nessun = significa che la lunghezza dell'input era un multiplo di tre.
La Base64 può rappresentare file binari arbitrari? Sì, ed è il suo uso principale. Questa pagina tratta l'input come testo UTF-8; lo strumento dedicato File in Base64 legge i byte grezzi quando si vuole codificare qualcosa che non è testo.
Quale alfabeto usare in un'API? Quello che documenta il sistema ricevente. Se dice sicuro per URL, si usi quello; se non dice nulla e il valore viaggia in un URL, la scelta sicura è l'alfabeto sicuro per URL senza riempimento.
L'output distingue maiuscole e minuscole? Completamente. a e A sono valori diversi, ed è per questo che la Base64 sopporta un carattere digitato male molto meno bene della Base32 o della Base32 di Crockford.
