Strumenti per sviluppatori · Codificatore e decodificatore Base64
Base64 vs hex vs base32: confronto di tre modi per scrivere byte come testo
· Sfondo
base64 codifica
Hex, base32 e Base64 risolvono lo stesso problema con diversi compromessi in termini di dimensioni, leggibilità e sicurezza. Questo post li confronta su densità, distinzione tra maiuscole e minuscole, sicurezza URL ed errore umano.
La chiave API è stata digitata in modo errato a causa di l, 1, I e O: un concreto errore di leggibilità che hex non avrebbe avuto
Tre modi comuni per rappresentare i byte come testo sono esadecimale, base32 e base64. Risolvono tutti lo stesso problema (esprimendo byte arbitrari in ASCII stampabile) ma con diversi compromessi in termini di dimensioni, leggibilità e resilienza agli errori. Hex è composto da 2 caratteri per byte (F3 A2 B1 ...), quindi 16 bytes diventano 32 caratteri. Base32 è 1.6 caratteri per byte (circa 5 caratteri per 3 bytes), quindi 16 bytes diventano 26 caratteri.
Base64 è 1.33 caratteri per byte (esattamente 4 caratteri per 3 bytes), quindi 16 bytes diventano 24 caratteri o meno. Se la dimensione del file conta, base64 è il più compatto. Se la trascrizione umana è importante, hex e base32 sono più sicuri. La differenza di leggibilità è fondamentale quando un valore viene digitato, copiato o pronunciato. Hex utilizza 0-9 e a-f (senza distinzione tra maiuscole e minuscole nella maggior parte dei contesti). Un canale di trascrizione cambia la decisione perché una rappresentazione ottimizzata per le macchine può essere scomoda per le persone. Base64 fa distinzione tra maiuscole e minuscole e utilizza due simboli di punteggiatura; hex utilizza un vocabolario visivo più piccolo. L'implementazione qui testa stringhe esatte, non un tasso di errore umano, quindi non viene allegata alcuna probabilità inventata.
Densità: 2×, 1.6× e 1.33×: quanti caratteri richiede ciascuna codifica per byte e perché
Base32 utilizza A-Z e 2-7, evitando 0, 1, O e I che sono facilmente confusi sulla carta. Base64 utilizza A-Z, a-z, 0-9, + e /, includendo sia maiuscole che minuscole, facendo distinzione tra maiuscole e minuscole e mescolando cifre che sembrano simili (0 contro O, 1 contro I contro l minuscola). Una chiave API in formato esadecimale potrebbe essere f3a2b1e4; gli stessi byte in base64 potrebbero essere 86KrvE== (con riempimento), o in base32 6VEV7FI= (con riempimento).
Se un utente deve digitare il valore a mano, hex o base32 è più sicuro di base64. I caratteri riservati negli URL sono importanti. Hex e base32 sono sicuri per gli URL; entrambi utilizzano solo caratteri alfanumerici (hex utilizza anche 0-9, base32 utilizza anche 2-7). Base64 utilizza più e barra che sono URL-riservati (più rappresenta uno spazio nei dati codificati nel modulo, la barra è un separatore di percorso). La densità Base64 deriva direttamente da sei bit utili per simbolo di output e riempimento in blocchi di quattro caratteri. Hex trasporta quattro bit per simbolo, creando due caratteri per byte. Base32 viene discusso come contesto di confronto solo perché questo repository non fornisce né il proprio alfabeto né un codificatore per verificare gli output.
Densità dalla larghezza di bit: Base64 esatta e aritmetica esadecimale, con Base32 trattato come contesto di confronto
Una stringa base64 in un parametro URL deve essere codificata in percentuale (il più diventa %2B, la barra diventa %2F), aggiungendo 4 caratteri extra per ogni occorrenza. Base64url (RFC 4648 sezione 5) sostituisce il segno più con il trattino e la barra con il carattere di sottolineatura, rendendolo URL sicuro senza codifica percentuale. La maggior parte delle API che utilizzano base64 negli URL utilizzano effettivamente base64url, ma la distinzione spesso non è esplicita nella documentazione.
I segreti TOTP (i codici utilizzati dalle app di autenticazione) sono generalmente distribuiti come base32. Una schermata di registrazione TOTP mostra un segreto base32 perché è più semplice da digitare e trascrivere rispetto agli stessi byte in base64 o esadecimale. I digest hash SHA vengono spesso visualizzati in formato esadecimale perché è il formato tradizionale e perché hex non fa distinzione tra maiuscole e minuscole, rendendo meno probabili gli errori di battitura. La distinzione tra maiuscole e minuscole è importante quando qualcuno legge un valore ad alta voce o lo riscrive, poiché la modifica del maiuscolo/minuscolo di una lettera ne modifica l'indice. ToolAcre preserva esattamente le maiuscole e minuscole e decodificherà i diversi byte risultanti senza sapere che un essere umano ha commesso un errore di trascrizione. La rappresentazione stessa non ha checksum.
Caratteri riservati e sicurezza URL: dove + e / mordono e come base32 e hex evitano il problema
I JWT utilizzano base64url. I checksum dei file potrebbero essere esadecimali o base64; entrambi sono comuni. La scelta è una convenzione storica, non una necessità tecnica. La resilienza agli errori è una differenza sottile ma importante. Base32 evita le cifre 0, 1, 8 e 9 (che sembrano lettere), riducendo gli errori di trascrizione. Base64 include tutte le cifre, rendendo 1 ambiguo (è una lettera I, una l minuscola o la cifra 1?).
L'esadecimale è ancora più soggetto a errori: 0 assomiglia a O, io assomiglia a 1. Un checksum che deve essere digitato o letto da una stampa è più sicuro in base32. Una chiave API incollata direttamente da un computer è sicura in qualsiasi formato; la leggibilità conta solo quando sono coinvolti gli occhi umani. Byte uguali, ma codifica diversa: la sequenza 16-byte [0xf3, 0xa2, 0xb1, ...] diventa f3a2b1... Il più e la barra standard di Base64 richiedono una gestione in grado di riconoscere il canale; La modalità URL-safe li sostituisce con trattino e carattere di sottolineatura. Hex evita questi separatori utilizzando solo cifre e lettere. Le convenzioni Base32 variano, quindi questo articolo evita di promettere proprietà di sicurezza che il repository non implementa o non testa.
Esempio realizzato: lo stesso 16 bytes in tutte e tre le codifiche: lunghezze confrontate e ispezione visiva
in esadecimale, 6VEV7FI=... in base32 e 86KrvE== in base64. Nessuna di queste stringhe è intercambiabile. Un'applicazione che riceve f3a2b1... si aspetta hex e proverà ad analizzarlo come hex. La ricezione di 86KrvE== fallirà se l'applicazione prevede hex. Il formato di codifica fa parte del contratto dei dati: mittente e destinatario devono concordare quale codifica utilizzare. L'imbottitura è un'altra differenza.
Hex non utilizza il riempimento (4 bytes sono sempre 8 caratteri esadecimali, senza eccezioni). Base32 e base64 utilizzano entrambi il riempimento uguale per allineare l'output a un multiplo di caratteri (8 per base32, 4 per base64). L'imbottitura è matematicamente necessaria; garantisce che ogni input di n byte produca un conteggio di caratteri deterministico. Le regole di riempimento variano: alcune applicazioni richiedono il riempimento, altre ne consentono l'omissione. Il confronto eseguito utilizza una sequenza di byte fissa e calcola Base64 ed esadecimale meccanicamente. La sua lunghezza Base32 può essere discussa dal raggruppamento a cinque bit, ma un valore di testo Base32 esatto viene omesso perché nessuna implementazione rivista lo ha generato. L'aritmetica della lunghezza e la verifica dell'output vengono mantenute distinte.
Dove ciascuno è convenzionale: hash in esadecimale, segreti TOTP in base32, JWT e dati: URI in Base64
Quando si incolla un valore base32 o base64 senza riempimento, i decodificatori possono accettarlo o rifiutarlo a seconda dell'implementazione. Le chiavi e i token crittografici mostrano la differenza di codifica.
Una chiave HMAC è 32 bytes, che diventa 64 caratteri esadecimali, 52 caratteri base32 (con riempimento) o 44 caratteri base64 (con riempimento). Quando si distribuisce una chiave, la codifica dovrebbe essere documentata. Se la documentazione dice che la chiave è composta da 44 caratteri base64 ma ricevi 52 caratteri, qualcosa non va. La convenzione può guidare i lettori ma non dimostra l’idoneità. I digest hash vengono comunemente visualizzati come esadecimali, mentre i segmenti JWT utilizzano Base64url. La scelta giusta dipende ancora dalle regole del canale, dal fatto che le persone copino il valore e se un altro protocollo abbia già corretto la rappresentazione.
Ciò che questo non copre: codifiche base58, base85 e checksum
La codifica base64 più corta rende leggermente più semplice l'inserimento dei token nei sistemi con limiti di caratteri (come codici QR o URL). La scelta della codifica per un valore è determinata dall'ecosistema da cui proviene. Le API Web utilizzano spesso base64url. La documentazione crittografica utilizza spesso hex. Le app di autenticazione utilizzano base32. Quando costruisci un sistema, scegli una codifica, documentala chiaramente e attieniti ad essa.
Mescolare le codifiche (ad esempio base64 o base32) introduce confusione. Durante il debug, il primo passaggio consiste nell'identificare quale codifica utilizza il valore; lo strumento di codifica e decodifica Base64 può aiutare tentando di decodificarlo in più modi e vedendo quale produce un output sensato. Nessuna codifica è universalmente migliore. Base64 è il più compatto per l'archiviazione grezza. Hex è più familiare ai crittografi e più leggibile dall'uomo per piccole sequenze. Le codifiche Base58, Base85 e checksum prevedono compromessi diversi e sono assenti dal pannello Base64 di ToolAcre. I loro alfabeti, le regole di ambiguità e i checksum dovrebbero essere valutati con fonti e implementazioni dedicate piuttosto che estrapolati dal comportamento testato di questo strumento.
Conclusione: scegli la codifica per il canale e il lettore: in che modo il codificatore e decodificatore Base64 copre il caso Base64 nel browser, insieme al calcolatore hash SHA nello stesso prodotto
Base32 è più resistente agli errori di trascrizione. La scelta dipende dal contesto: dove risiede il valore, come viene condiviso e quali sistemi lo consumeranno.
Comprendere i compromessi ti aiuta a scegliere saggiamente quando progetti un API o un sistema. Lo strumento di codifica e decodifica Base64 dimostra la codifica Base64; utilizzarlo insieme a uno strumento esadecimale o base32 ti consente di vedere gli stessi byte in tutti e tre i formati e comprenderne le differenze di dimensione e leggibilità. Nel caso Base64, codifica un campione, prendi nota del conteggio esatto di UTF-8-byte e dei caratteri di output e verifica la punteggiatura standard rispetto a URL-safe. Per il lavoro digest, utilizza il pannello separato SHA. Mantenere distinte queste operazioni impedisce che una scelta di codifica venga confusa con l'hashing o la protezione dell'integrità.