Strumenti per sviluppatori · Codificatore e decodificatore Base64
Spiegazione dell'imbottitura Base64: cosa significano i segni = e quando sono richiesti
· Come funziona
base64 codifica flusso di lavoro dello sviluppatore
Il = alla fine di una stringa Base64 non è una decorazione: registra quanti byte era corto l'ultimo gruppo. Questo post spiega l'aritmetica, perché alcune stringhe non ne hanno e perché i decodificatori non sono d'accordo sulla mancanza del riempimento.
L'eccezione di "imbottitura errata" da un token che sembrava a posto: una decodifica non riuscita e uno o due caratteri mancanti dietro di essa
Quando un decodificatore Base64 segnala un riempimento errato, la stringa sembra completa ma contiene un errore strutturale. I segni di uguale non sono cosmetici: ciascuno codifica di quanti byte era corto il gruppo finale, consentendo al decodificatore di sapere esattamente quando finivano i dati reali. Comprendere questi segni = e perché i decodificatori rigorosi rifiutano le stringhe senza di essi trasforma un errore misterioso in un'aritmetica prevedibile. Un segmento JWT potrebbe avere uno =, nessuno o due. Una risposta API potrebbe terminare in modo pulito senza riempimento.
Queste rappresentano scelte intenzionali, non varianti di implementazione. Il processo di decodifica non richiede il riempimento meccanico. Il riempimento esiste per rendere l'output non ambiguo: data solo una stringa Base64 senza metadati sulla lunghezza, il decodificatore legge il riempimento e sa esattamente dove finiscono i dati. Base64 codifica gruppi di tre byte in quattro caratteri. Tre byte sono 24 bits, raggruppandosi perfettamente in quattro indici 6 bit; ognuno sceglie uno dei simboli 64 Base64. Quando l'input non è un multiplo di tre, il codificatore affronta gli avanzi: uno o due byte non possono essere divisi equamente per tre.
Gruppi di tre byte, blocchi di quattro caratteri: perché la lunghezza dell'input modulo 3 decide se devono apparire zero, uno o due = segni
Il codificatore riempie questi gruppi spostando i bit nei primi indici, lasciando i finali zero. Per contrassegnare questo intenzionale, aggiunge i segni =: zero per gruppi completi, uno per finali a due byte, due per finali a un byte. L'aritmetica è deterministica: conoscere la lunghezza dell'input in byte consente di calcolare immediatamente il riempimento. Un byte produce due caratteri Base64 più due =. Due byte producono tre caratteri più uno =. Tre byte ne producono quattro senza riempimento.
Qualsiasi input non multiplo di tre byte avrà il riempimento; tutto ciò che è un multiplo non lo farà. Questa non è una scelta: è aritmetica. Una stringa senza riempimento deve rappresentare tre byte. Una stringa con uno uguale deve rappresentare due. Il riempimento codifica la lunghezza dell'input modulo tre. Esaminare la trasformazione di tre input: singolo a, coppia ab, triplo abc. ASCII a è il byte 0x61; Base64 lo codifica come 0x61 00 00, raggruppandosi in gruppi a sei bit.
Cosa contengono i bit di riempimento e perché un decodificatore rigoroso li controlla: i bit che devono essere zero e cosa significa la codifica canonica
Gli indici 24, 4, 0, 0 vengono mappati su Y, E, A, A. Poiché due gruppi erano riempiti, il codificatore aggiunge due segni =, producendo YQ==. Per ab, i byte 0x61 0x62 diventano 0x61 0x62 00. Bits raggruppati negli indici 24, 22, 8, 0, output YWI=. Per abc, i byte si raggruppano negli indici 24, 22, 9, 35, output YWJj senza riempimento. Il riempimento non è arbitrario: esce dal layout dei bit. Quando decodifichi una stringa Base64, il decodificatore legge ogni carattere, cerca il suo indice a sei bit e comprime i bit in byte.
Per YQ==, i caratteri Y, E, A, A vengono decompressi in bit. Il raggruppamento in byte da otto bit fornisce un byte, 0x61. Il decodificatore scarta i bit di riempimento (zeri finali) e riporta un byte. Un decodificatore rigoroso controlla che i bit di riempimento siano effettivamente zero; in caso contrario, l'input non era canonico, il che significa che qualcuno ha codificato utilizzando un layout di bit diverso e la decodifica è ambigua. I sistemi che omettono completamente l'imbottitura comportano compromessi deliberati. I segmenti JWT utilizzano Base64url senza riempimento, facendo affidamento sul fatto che i consumatori conoscano la lunghezza di output prevista o la deducano.
Esempio realizzato: codifica manuale di 'a', 'ab' e 'abc': tre input, tre risultati di riempimento, mostrati bit per bit
RFC 4648 consente il riempimento assente ma indica ai decodificatori di accettarlo se presente. Le librerie di codici differiscono: alcune ripristineranno il riempimento mancante e procederanno; altri falliranno. Quando incontri token che non riescono a decodificare, l'aggiunta del numero corretto di segni = spesso risolve il problema. Obbligatorio = i segni sono sempre zero, uno o due, a seconda della lunghezza della stringa modulo quattro. Se la lunghezza di una stringa Base64 non è un multiplo di quattro, il riempimento è sicuramente mancante o danneggiato.
Una lunghezza di 5 non può essere Base64 valida: ogni carattere completo codifica sei bit, quindi quattro caratteri codificano 24 bits (tre byte) e cinque codificano 30 bits, che non è un multiplo di otto e non può diventare byte. Il decodificatore deve rifiutarlo o aggiungere riempimento. Se la lunghezza è 2 modulo 4, aggiungi due =. Se 3 modulo 4, aggiungi uno =. Se 0 modulo 4, non aggiungere nessuno. Una stringa di lunghezza 3 manca del suo = di cui ha bisogno; aggiungine uno e diventa valido prima della decodifica.
Perché alcuni sistemi eliminano completamente il riempimento: segmenti JWT e token URL-safe che omettono = e come ripristinarlo dalla lunghezza
Concatenazione di due stringhe Base64 imbottite rotte se l'imbottitura viene lasciata al suo posto. Due codifiche separate unite direttamente producono caratteri di riempimento vaganti che interrompono l'alfabeto di decodifica. Questo è il motivo per cui alcuni sistemi rimuovono il riempimento prima della concatenazione: un token composto da tre segmenti Base64url uniti da punti non ha riempimento all'interno dei segmenti, rendendo la concatenazione semplice. Se crei un valore Base64 da parti, verifica se ciascuna parte è imbottita e rimuovi o aggiungi imbottitura in modo coerente prima di qualsiasi operazione.
Il codificatore e decodificatore Base64 applica RFC 4648, che richiede il riempimento per impostazione predefinita. Quando inserisci testo e richiedi l'output base64, lo strumento produce un risultato riempito: la forma canonica. Se vedi Base64 senza riempimento e desideri decodificarlo, controlla se il tuo decodificatore accetta il riempimento mancante. Lo strumento accetta input sia riempiti che non riempiti e recupera correttamente i byte originali. Per il debug, il conteggio della lunghezza modulo quattro indica se il riempimento è stato rimosso e la formula indica quale riempimento dovrebbe essere presente.
Errori comuni: taglio = come se fosse uno spazio bianco o concatenazione di due stringhe imbottite: come ciascuna di esse corrompe la decodifica
Base32 e Base16 (esadecimale) hanno regole di riempimento diverse definite nelle sezioni RFC 4648 6 e 7. Base32 utilizza = ma il gruppo finale può essere costituito da caratteri 2, 4, 5, 7 o 8 a seconda della lunghezza dell'input modulo cinque. L'esadecimale non richiede riempimento; mappa sempre un byte su due caratteri senza resto. MIME L'avvolgimento in Base64 tocca l'imbottitura: una stringa 76-colonna ha ancora l'imbottitura alla fine, solo diverse righe dopo.
Comprendere il riempimento per Base64 riguarda la comprensione del layout dei bit e della lunghezza dell'input modulo tre; una volta vista l'aritmetica, il riempimento diventa una conseguenza diretta, non una regola da memorizzare. L'imbottitura è derivabile, non magica.
Cosa non copre: regole di riempimento base32 e base16 e convenzioni sulla lunghezza della riga MIME
Data una stringa Base64 di qualsiasi lunghezza, è possibile ripristinare la forma canonica imbottita dividendo il conteggio dei caratteri per quattro, prendendo il resto e aggiungendo il numero corrispondente di segni =. Questo è il motivo per cui mancante = è risolvibile e perché i decodificatori rigorosi possono essere indulgenti: il riempimento trasporta informazioni (in quale ramo di tre casi è caduto il tuo input), ma tali informazioni possono essere calcolate solo dalla lunghezza.
Il codificatore e decodificatore Base64 mostra immediatamente l'output imbottito in modo da poter confrontare i byte decodificati con il testo originale e verificare che il viaggio di andata e ritorno abbia funzionato. Base64 e le codifiche correlate estendono il principio di raggruppamento dei bit in diverse larghezze di carattere. RFC 4648 li specifica tutti e tre e comprenderne uno rende gli altri concettualmente semplici. L'intuizione chiave è che la codifica è pura manipolazione di bit: scegli la dimensione dell'alfabeto, raggruppa i bit di conseguenza, cerca ciascun gruppo in una tabella.
Conclusione: il riempimento è derivabile, quindi un = mancante è risolvibile: come il codificatore e decodificatore Base64 mostra la forma canonica imbottita di qualsiasi testo che codifichi
La decodifica è inversa: cerca ogni carattere, estrai i bit, raggruppali, scrivi i byte. Questa mappatura deterministica a due vie è il motivo per cui Base64 funziona in modo affidabile su tutte le piattaforme e linguaggi. Errori nella codifica e decodifica spesso sono dovuti a incomprensioni o differenze alfabetiche. Se la decodifica fallisce con errori di riempimento, controlla se il decodificatore prevede Base64 canonico (rigorosamente riempito) o accetta varianti. Se fallisce con errori di carattere, controlla se l'input è base64url e il decodificatore si aspetta Base64 standard.
Il codificatore e decodificatore Base64 accetta entrambi gli alfabeti e convalida il riempimento in modo coerente, quindi qualsiasi esempio calcolato manualmente può essere verificato immediatamente. Testare la codifica decodificandola è il modo più sicuro per individuare gli errori prima che causino problemi di produzione.