Strumenti per sviluppatori · Codificatore e decodificatore Base64
Una breve storia di Base64: da uuencode e PEM all'alfabeto di oggi
· Sfondo
base64 codifica
L'alfabeto di Base64 è una testimonianza fossile dei problemi di trasporto degli anni '80. Questo post segue il percorso da uuencode attraverso la posta ottimizzata per la privacy a MIME e RFC 4648 e spiega ogni scelta di progettazione.
Perché l'alfabeto non è semplicemente 0–63 in un ordine ovvio: la domanda che riporta indietro di quattro decenni
Base64 non sembrava completamente formato come standard. L'alfabeto (A-Z, a-z, 0-9, +, /) è una testimonianza fossile di decenni di esperimenti di codifica, ognuno dei quali tentava di risolvere lo stesso problema: come rappresentare i dati binari come testo che sopravvive alle e-mail degli anni '70 e '80, USENET e agli strumenti Unix. La storia abbraccia uuencode su Unix, posta con privacy avanzata (RFC 1421) in 1993, MIME (RFC 2045) in 1996 e infine RFC 4648 in 2006 consolidando tutte le varianti.
Comprendere questa storia spiega perché alcuni caratteri sono presenti nell'alfabeto e perché RFC ha lasciato determinate scelte agli implementatori. uuencode, abbreviazione di Unix-to-Unix encode, è stato il primo strumento a risolvere il problema del trasporto 7-bit su Unix. Creato in 1980, codificava ogni 3 bytes (24 bits) in 4 caratteri da un alfabeto di 64 caratteri. L'alfabeto uuencode era da ASCII 32 (spazio) a ASCII 95 (trattino basso e altri segni di punteggiatura), scelto perché questi caratteri sono stampabili su qualsiasi terminale. Il repository mostra l'alfabeto attualmente implementato, ma non contiene prove d'archivio su chi ha selezionato quell'ordine o perché ogni personaggio ha vinto. L'intestazione risulta quindi ristretta: l'impianto attuale può essere visionato con esattezza, mentre motivi e date richiedono documenti storici primari qui non compresi.
Perché l'alfabeto sembra storico: un confine che questo archivio non documenta
Tuttavia, lo spazio come carattere di codifica è problematico: gli editor di testo e i sistemi di posta tagliano gli spazi finali, corrompendo l'output. L'alfabeto non era l'ideale, ma funzionava abbastanza bene per il trasferimento di file da Unix a Unix. Privacy-Enhanced Mail (RFC 1421, 1992) è stato uno dei primi tentativi di standardizzare la posta elettronica crittografata. Comprendeva la propria codifica Base64 (RFC 1341, per MIME, che RFC 1421 era anteriore alle specifiche ma ritardata nell'adozione).
RFC 1421 Base64 utilizzava l'alfabeto A-Z, a-z, 0-9, +, / (l'alfabeto moderno Base64) e le righe andavano a capo con i caratteri 64. Questo alfabeto evitava spazi e altri caratteri problematici; ogni carattere è stampabile in modo inequivocabile e non confuso con codici di controllo o variazioni del set di caratteri nazionali. La lunghezza della linea di caratteri 64 corrispondeva alla larghezza dei terminali cartacei degli anni '80 ed era un compromesso pratico per la leggibilità. Uuencode appartiene alla storia circostante, eppure lo strumento non legge né scrive il suo alfabeto. Trattarlo come Base64 intercambiabile sarebbe un errore di formato. Il confronto utile qui è limitato al problema condiviso di rappresentare i byte con caratteri stampabili.
Codifiche precedenti come contesto, non come prova di implementazione
RFC 1421 non è stato ampiamente adottato per la posta elettronica crittografata, ma il suo alfabeto Base64 è sopravvissuto. MIME (Estensioni multiuso di posta Internet, RFC 2045, 1996) ha adottato l'alfabeto RFC 1421 Base64 ma ha modificato il ritorno a capo della riga da 64 a 76 caratteri. Il motivo non era tecnico ma storico: i blocchi PEM (posta con privacy avanzata) erano caratteri 64 e MIME ha scelto un limite leggermente diverso per evitare confusione con PEM nell'analisi automatizzata.
MIME Base64 è diventato lo standard per gli allegati e-mail ed è oggi la variante Base64 più utilizzata. RFC 2045 ha inoltre definito altri valori di codifica del trasferimento del contenuto (7bit, 8bit, quoted-printable), fornendo ai sistemi di posta opzioni in base al tipo di contenuto. La scelta dell'alfabeto evita i caratteri che differiscono tra ASCII e EBCDIC (la codifica dei caratteri del mainframe IBM). I caratteri A-Z, a-z, 0-9, + e / sono gli stessi in entrambe le codifiche. I blocchi in stile PEM sono riconoscibili perché le etichette circondano il materiale codificato avvolto. ToolAcre può elaborare il corpo Base64 estratto dopo che le etichette sono state rimosse. Non è possibile stabilire quale specifica archivistica abbia utilizzato per prima una determinata convenzione e questo articolo non pretende che l'albero dei sorgenti risponda a questa domanda.
Armatura in stile PEM come formato osservabile moderno, senza rivendicare una storia di origine
Caratteri come parentesi aperta e parentesi chiusa differiscono tra ASCII e EBCDIC, quindi sono stati esclusi. Ciò era importante negli anni '80 e all'inizio degli anni '90, quando il trasferimento di dati da mainframe a Unix era comune. L'alfabeto evita anche la barra rovesciata, le virgolette singole e le virgolette doppie, che hanno un significato speciale nelle stringhe C e nella sintassi della shell. Una stringa Base64 può essere incorporata in un programma C o in uno script di shell senza eseguire l'escape di quasi tutti i caratteri.
RFC 3548 (2006) codifiche Base64, base32 e base16 consolidate. Ha notato che MIME, PEM e altre applicazioni utilizzavano tutte concetti simili ma con regole di riempimento e alfabeti diversi. RFC 4648 (2006, pubblicato insieme a RFC 3548) è lo standard attuale e definisce cinque famiglie di codifica con vettori di test per ciascuna. Il RFC annota anche la storia: quali documenti hanno definito quali codifiche, cosa è cambiato tra le versioni e perché sono state fatte le scelte. L'opzione di avvolgimento dei caratteri 76 del codificatore e la rimozione degli spazi bianchi del decodificatore rendono testabili i campioni a forma di MIME. Questi fatti di implementazione non dimostrano una storia completa degli standard postali. Mostrano il comportamento di compatibilità moderno che i lettori possono riprodurre direttamente nel pannello e nei test.
Wrapping in stile MIME come opzione del codificatore, senza ricostruire la cronologia degli standard
La maggior parte degli sviluppatori riscontra solo base64 e base64url in RFC 4648; la storia è documentata per coloro che necessitano di implementare le varianti più vecchie. Base64url (RFC 4648 sezione 5) sostituisce il segno più con il trattino e la barra con il carattere di sottolineatura per evitare caratteri riservati URL. Una stringa base64 contenente + e / deve essere codificata in percentuale in un URL (%2B e %2F); base64url lo evita.
JWT (JSON Web Token) utilizza base64url senza riempimento. Alcune applicazioni utilizzano base64url con riempimento. Il RFC definisce entrambe le varianti; dipende dall'applicazione quale scegliere. Questa variazione è il motivo per cui un decodificatore JWT e un decodificatore Base64 di posta elettronica possono produrre output diversi per la stessa stringa di input (uno si aspetta base64url, l'altro si aspetta base64). L'alfabeto, le regole di riempimento e il ritorno a capo delle linee sono tutti emersi da vincoli pratici di sistemi reali. È meglio trattare la portabilità come un vincolo sugli alfabeti di trasporto piuttosto che come una biografia verificata di ciascun simbolo. Le lettere e le cifre rimangono visivamente familiari nei comuni sistemi di testo, mentre la punteggiatura finale differisce in modalità URL-safe. L'esatta logica storica della selezione viene omessa senza prove primarie.
La portabilità come vincolo di progettazione, non come resoconto verificato delle scelte dei singoli personaggi
Il set di caratteri 64 è stato scelto per la rappresentabilità tra le codifiche; l'alfabeto è stato corretto da RFC 1341 e 1421 e MIME; la regola di riempimento proviene dall'allineamento 3-byte; e il ritorno a capo della riga proveniva dai limiti di trasporto della posta elettronica. Un'implementazione che ignora questa cronologia potrebbe inventare una nuova codifica o dimenticare un caso limite. I vettori di test RFC 4648 (foobar produce Zm9vYmFy) sono il modo per verificare che un'implementazione rispetti lo standard.
Esistono alternative moderne come base85 (utilizzato in alcuni contesti), ma base64 rimane dominante a causa dello slancio storico e perché è abbastanza buono. Base64 non è la codifica più compatta (base85 e base91 sono più dense), ma è semplice, universale e collaudata. Ciò che può essere affermato con fermezza è l'attuale coppia di alfabeti: lo standard termina con più e barra; URL-safe sostituisce il trattino e il carattere di sottolineatura. L'imbottitura e l'avvolgimento sono opzioni separate. I test coprono entrambe le modalità e il riempimento mancante, fornendo prove riproducibili del comportamento attuale piuttosto che una cronologia dedotta.
Ciò che il repository dimostra sugli attuali alfabeti standard e URL-safe
Il sovraccarico della dimensione percentuale del 33 è accettabile per la maggior parte degli usi. L'alfabeto è stabile attraverso le implementazioni. RFC è abbastanza chiaro che le deviazioni sono generalmente intenzionali (come l'omissione del riempimento o la gestione degli spazi bianchi) piuttosto che malintesi accidentali.
Comprendere la storia di Base64 spiega perché appare così. I caratteri più e barra sono state scelte deliberate per evitare ambiguità nelle diverse codifiche dei caratteri. La regola di riempimento proviene dal raggruppamento 3-byte. Base85 e Ascii85 utilizzano dimensioni di gruppo e alfabeti diversi e sono esterni all'implementazione. Menzionarli non rende questa pagina un convertitore per loro. Il confronto della loro densità o cronologia richiederebbe fonti e vettori di test oltre i file Base64 esaminati per questo modulo.
Conclusione: ogni carattere è stato scelto per un motivo: il modo in cui il codificatore e decodificatore Base64 implementa l'alfabeto standard risultante
Il ritorno a capo è arrivato dall'e-mail. Ogni decisione è stata presa per risolvere un problema reale con sistemi reali. Oggi, Base64 è utilizzato principalmente in contesti (JWT, API, URI di dati) in cui la cronologia non ha importanza, ma le regole dell'alfabeto e del riempimento sono ereditate da MIME e PEM fino a RFC 4648.
Leggere RFC una volta e codificare una stringa di prova nello strumento di codifica e decodifica Base64 collega lo standard attuale alle sue radici storiche. L'alfabeto standard risultante è visibile ogni volta che l'input raggiunge gli indici sessantadue o sessantatré. Utilizza un esempio che produce tali posizioni, attiva la modalità URL-safe e confronta solo la punteggiatura modificata. Quell’esperimento dimostra il formato odierno senza fare affidamento su una storia non supportata sulla sua invenzione.