Strumenti per sviluppatori · Codificatore e decodificatore Base64
Decodifica Base64 in UTF-8 senza mojibake: atob più TextDecoder
· Come funziona
base64 codifica unicode
atob() restituisce byte mascherati da caratteri, motivo per cui il testo accentato appare interrotto dopo la decodifica. Questo post mostra la pipeline corretta da Base64 ai byte al testo UTF-8 e come riconoscere il modello di errore.
La risposta API che decodifica in 'Café': un sintomo concreto del mojibake e i due byte dietro i due caratteri errati
Una stringa Base64 Q2Fmw6k= decodifica in byte (67, 97, 102, 195, 169), che sono UTF-8 testo Café. Incolla nel decodificatore ingenuo (solo atob e conversione di stringhe) e l'output è spesso Café, ogni accento sostituito da due caratteri sbagliati. Questo mojibake si verifica perché atob restituisce una stringa di byte (unità di codice 0–255), non UTF-8 testo. I byte 195 e 169 codificano la é accentata in UTF-8.
Trattandoli come se fossero caratteri latini separati-1 si ottiene il modello mojibake. La pipeline corretta è atob (byte come stringa), quindi TextDecoder (interpreta i byte come UTF-8) e il testo originale ritorna. La funzione atob non è interrotta; è progettato per dati binari. Il suo nome deriva da ASCII-to-binary e la stringa binaria che produce è una sequenza di unità di codice 0–255, ciascuna rappresentante un byte.
Ciò che atob() restituisce effettivamente: una stringa di unità di codice 0–255 che rappresentano byte, non testo decodificato
Se lo inserisci Q2Fmw6k= (Base64 standard), restituisce una stringa in cui ogni carattere è un byte: unità di codice 67, quindi 97, quindi 102, quindi 195, quindi 169. Se visualizzi la stringa direttamente o la interpreti come testo Latin-1, vedrai un output confuso. Il passaggio mancante è la conversione delle unità di codice nell'array di byte e quindi la decodifica dell'array come UTF-8.
Il ciclo charCodeAt recupera i valori byte: per ogni carattere nell'output atob, chiama charCodeAt per ottenere l'unità di codice (numero 0–255), archivia in Uint8Array. Una volta esistente l'array di byte, passa a TextDecoder con charset utf-8. TextDecoder legge la sequenza di byte e la interpreta come testo UTF-8, combinando sequenze di byte come (195, 169) in singoli caratteri come é. I byte (67, 97, 102, 195, 169) diventano una stringa di quattro caratteri Café. Il ciclo è volutamente noioso: leggi ogni unità di codice restituita con charCodeAt e assegnala alla posizione Uint8Array corrispondente. Nessuna decisione sul set di caratteri avviene lì. L'unica interpretazione arriva quando TextDecoder riceve l'array e applica UTF-8 con la gestione degli errori irreversibili.
Trasformare quella stringa in un Uint8Array: il ciclo charCodeAt e perché è una copia di byte, non una conversione
Questo processo in due fasi (recupero dei byte, quindi interpretazione UTF-8) è ciò che il codificatore e decodificatore Base64 esegue internamente. Il motivo mojibake è un segno rivelatore di questo errore. Se Café appare come Café, stai vedendo l'interpretazione latina-1 dei byte UTF-8. UTF-8 byte per é sono 0xC3 0xA9 (decimale 195, 169). In latino-1, l'unità di codice 195 è Ã e l'unità di codice 169 è ©.
Quando la sequenza di byte UTF-8 viene letta come se ogni byte fosse un carattere latino1 separato, ogni sequenza multibyte UTF-8 produce caratteri sostitutivi errati. Se Café appare come Caf seguito dal carattere sostitutivo o come Caf? o Caf più U+FFFD, stai riscontrando un errore diverso: il decoder non ha riconosciuto la sequenza di byte come valida UTF-8. Un esempio concreto: Base64 SGVsbG8sIOS4lueVjCEg8J-Zgg== decodifica come segue.
TextDecoder e la decisione del set di caratteri: decodifica come UTF-8 e perché il set di caratteri è un fatto separato che devi sapere
atob produce una stringa binaria con byte (72, 101, 108, 108, 111, 44, 32, 228, 184, 180, 149, 140, 33, 32, 240, 159, 152, 130). I primi sei byte sono ASCII: diventano Hello,. I byte 228, 184, 180 sono sequenze UTF-8 di tre byte che rappresentano il carattere CJK. I byte 149, 140 fanno parte della sequenza successiva. La sequenza completa include una sequenza di emoji a quattro byte (240, 159, 152, 130) per il carattere finale.
Se elaborati correttamente tramite TextDecoder, tutti i byte si combinano per produrre testo originale in caratteri misti. Le sequenze di byte UTF-8 hanno lunghezze prevedibili: il byte che inizia con 0xxxxxxx è a byte singolo ASCII; il byte che inizia con 110xxxxxx prevede il byte successivo che inizia con 10xxxxxx (due byte in totale); il byte che inizia con 1110xxxx prevede due byte successivi (tre byte in totale); il byte che inizia con 11110xxx prevede tre byte successivi (quattro byte in totale). Per un campione misto di CJK ed emoji, la visualizzazione per byte è particolarmente diagnostica perché l'intuizione di ASCII non aiuta più. A ciascun simbolo visibile appartengono diversi byte e l'eliminazione di un byte sposta la sequenza rimanente in UTF-8 non valido. Una decodificazione rigorosa trasforma questo cambiamento in un fallimento dichiarato invece che in un danno apparentemente plausibile.
Esempio realizzato: decodifica di una stringa Base64 contenente CJK e un'emoji: byte, punti di codice e la stringa finale rispetto all'originale
La sequenza che inizia con 1111110x non è valida in UTF-8 (riservata per il futuro, non utilizzata). Il byte che inizia con 10xxxxxx non dovrebbe mai apparire come byte iniziale; è continuazione. Se il flusso di byte viola le regole, non è valido UTF-8. TextDecoder con set di caratteri utf-8 interpreta l'array in base a queste regole e riesce con sequenze valide. Per non valido, segnala errore.
Il codificatore e decodificatore Base64 utilizza TextDecoder con il flag di modalità rigorosa vero. Ciò significa che UTF-8 non valido genera un errore anziché inserire automaticamente caratteri sostitutivi (U+FFFD). Se la stringa Base64 viene decodificata in byte che non sono validi UTF-8, la modalità rigorosa genererà un'eccezione invece di continuare con testo confuso. Questa è una scelta progettuale: i payload binari (immagini, chiavi, dati compressi) non sono testo e non devono essere decodificati come testo.
Riconoscere lo schema Ã, †e �: come distinguere un problema Base64 da un problema di codifica dei caratteri
Se si tenta di decodificare JPEG come Base64, il flusso di byte non rappresenterà UTF-8 valido e la decodifica rigorosa lo rifiuterà. Lo strumento offre una visualizzazione esadecimale per tali payload: puoi vedere i byte grezzi senza fingere che siano testo. Riconoscere gli errori di decodifica UTF-8 implica esaminare i byte nel contesto. Sono numeri dispari dove è prevista la sequenza multibyte?
Il primo byte della potenziale sequenza non è valido (inizia con 10xxxxxx)? Mancano i byte di continuazione? Il pulsante di output dei byte fornisce il fork più pulito nell'indagine. Se viene visualizzato esadecimale ma la decodifica del testo non riesce, l'analisi Base64 è riuscita e il payload è binario, danneggiato o codificato con un set di caratteri diverso. La modifica della punteggiatura Base64 non può riparare una mancata corrispondenza del set di caratteri dopo che sono già emersi i byte corretti.
Cosa non copre: payload UTF-16, output binario come immagini e gestione dei byte non validi
I modelli sono coerenti. Un singolo byte 0xFF non è mai valido in UTF-8; non può essere ASCII byte (solo 0–127 sono ASCII) e non può essere byte iniziali (i byte iniziali sono 0xC0–0xFD, 0xFF è riservato). I surrogati solitari (concetto UTF-16) non possono apparire in UTF-8; se vedi la sequenza di byte 0xED 0xA0 0x80 (che codifica il surrogato U+D800 nello stile UTF-8), non è valido UTF-8.
Una soluzione alternativa storica è btoa(unescape(encodeURIComponent(text))). encodeURIComponent trasforma café in %C3%A9 (codifica percentuale UTF-8 byte), unescape repack come unità di codice, btoa codifica le unità di codice. Funziona per la maggior parte dei testi, ma è fragile nei confronti dei surrogati solitari e difficile da leggere. La pipeline moderna (TextEncoder in byte, quindi base64) è più chiara e standard. TextEncoder è integrato in tutti i browser moderni e Node.js, facendo la scelta giusta. UTF-16, le codifiche legacy a byte singolo e i contenuti di file arbitrari richiedono un decodificatore selezionato per tali byte o un visualizzatore in grado di riconoscere il codice binario. ToolAcre non indovina intenzionalmente tra loro. Indovinare potrebbe trasformare una sequenza non valida in un testo fuorviante, mentre un dump esadecimale preserva ogni byte per un'interpretazione successiva e informata.
Conclusione: Base64 ti dà byte, UTF-8 ti dà testo: come il codificatore e decodificatore Base64 esegue entrambi i passaggi in modo che il testo decodificato corrisponda esattamente all'input
Quando si dispone di una stringa Base64 e si desidera testo UTF-8, i passaggi completi sono: decodificare Base64 in byte (utilizzando atob o la libreria di decodifica base64), creare Uint8Array da byte, passare l'array a TextDecoder con set di caratteri utf-8, leggere il risultato come stringa.
Se l'input è costituito da dati binari anziché da testo, ignora TextDecoder ed esamina direttamente i byte. Il codificatore e decodificatore Base64 fornisce una visualizzazione di byte esadecimali, preservando i valori che la rigorosa decodifica UTF-8 rifiuterebbe. Questo fork è diagnostico: i byte riusciti più il testo non riuscito indicano che l'analisi Base64 ha funzionato, mentre il carico utile è binario, danneggiato o codificato con un set di caratteri che questo strumento non indovina.