Questi tre nomi descrivono schemi correlati da binario a testo, ma soddisfano vincoli diversi. Base64 e Base64URL utilizzano gruppi a sei bit. Lo standard Base32 utilizza gruppi di cinque bit e un alfabeto più piccolo. La scelta giusta è quella che la vostra applicazione di trasporto, stoccaggio e ricezione può preservare esattamente.
Confronta gli alfabeti prima delle lunghezze
Lo standard Base64 utilizza lettere maiuscole e minuscole, cifre, più e barre. Base64URL sostituisce il trattino e il carattere di sottolineatura per gli ultimi due caratteri. Entrambi fanno distinzione tra maiuscole e minuscole. Lo standard RFC Base32 utilizza lettere maiuscole dalla A alla Z e le cifre da 2 a 7. Un decodificatore può accettare le lettere minuscole per comodità, ma un protocollo dovrebbe indicare se ciò è consentito e definire il suo output canonico.
Un canale senza distinzione tra maiuscole e minuscole può distruggere un valore Base64 preservandone uno Base32 correttamente specificato. Un token URL ha vincoli diversi rispetto a un codice letto ad alta voce tramite un telefono. Non scegliere semplicemente in base a quanto appare corto un campione.
Comprendi il compromesso dimensionale
Ignorando il gruppo parziale finale, Base64 necessita di circa 1,33 caratteri per byte e Base32 necessita di 1,6. Il riempimento standard Base32 emette gruppi di otto caratteri per cinque byte. Per un byte contenente la lettera f, i vettori comuni sono Zg== in Base64 e MY====== in Base32. Piccoli input esagerano l'overhead di riempimento, quindi confronta le lunghezze realistiche del carico utile.
Payload bytes: 66 (ASCII f)
Base64: Zg==
Base64URL: Zg== (or Zg when the protocol omits padding)
RFC Base32: MY======Non mescolare le varianti Base32
Crockford Base32 è progettato attorno a identificatori leggibili dall'uomo e utilizza un alfabeto e regole di ambiguità diversi da RFC Base32. Anche Base32hex differisce. Un valore prodotto da una variante non può essere consegnato ciecamente a un altro decodificatore. Assegna un nome alla variante, all'alfabeto, alla policy di riempimento e a qualsiasi comportamento del checksum nella documentazione.
Inoltre la codifica non fornisce l'autenticazione. Un valore digitato in modo errato potrebbe essere ancora sintatticamente valido e decodificare in byte diversi. Se gli utenti trascrivono un codice, considera un checksum o una fase di verifica definita dal protocollo invece di dare per scontato che l'alfabeto rilevi ogni errore.
Scrivi il contratto completo
Specificare l'ordine dei byte di input ove rilevante, il comportamento di input vuoto, la conservazione dello zero iniziale, la lunghezza massima, l'accettazione degli spazi bianchi e la gestione dei caratteri non validi. Includere vettori di test con byte di valore elevato e gruppi parziali. Utilizza il codificatore e il decodificatore scelti in modo indipendente rispetto a tali vettori, non solo l'uno rispetto all'altro; altrimenti potrebbe sembrare che i bug corrispondenti passino un viaggio di andata e ritorno. Sono presenti le forme standard e i vettori di riferimento RFC 4648.