Strumenti per sviluppatori · Codificatore e decodificatore Base64
Perché btoa() genera emoji e come codificare Base64 UTF-8 in JavaScript
· Come funziona
base64 unicode codifica
btoa() accetta solo caratteri fino a U+00FF, quindi testo accentato, CJK ed emoji lanciano. Questo post mostra cosa si aspetta effettivamente la funzione e come TextEncoder ti ottiene una stringa UTF-8 Base64 corretta.
Perché btoa può utilizzare Unicode e codificare silenziosamente un accento in modo errato
La chiamata a btoa("😀") genera InvalidCharacterError perché l'emoji non può rientrare in una singola unità di codice di dimensioni byte. Un errore più sottile è btoa("é"): é precomposto è U+00E9, sotto 256, quindi btoa lo accetta ma codifica Latin-1 byte E9, non UTF-8 byte C3 A9. Lo stesso accento visibile scritto come e più un segno combinato può creare un'eccezione perché il segno è al di fuori dell'intervallo accettato. La abbreviazione della cartella di lavoro "un accento lancia" necessita di questa qualifica: una stringa può fallire rumorosamente o silenziosamente producendo byte sbagliati.
Cosa codifica realmente btoa(): una stringa binaria di unità di codice 0–255 — perché la funzione è stata progettata attorno al testo Latin-1 bytes anziché al testo Unicode
btoa consuma una "stringa binaria": ciascuna unità di codice carattere JavaScript deve essere compresa nell'intervallo 0–255 e rappresenta un byte. Non comprende la codifica del testo Unicode, la lingua o la normalizzazione. Un'emoji astrale è rappresentata da due unità di codice surrogato UTF-16, entrambe molto più grandi di 255, quindi inviare direttamente la stringa grezza JavaScript non può funzionare. Tratta l'output come una codifica di byte, non di caratteri astratti.
UTF-8 prima, Base64 secondo: perché il testo deve diventare byte prima che venga applicato qualsiasi alfabeto Base64
TextEncoder trasforma prima una stringa JavaScript nella sua sequenza di byte UTF-8. Quindi trasforma ogni byte in un carattere di stringa binaria e passa quella stringa binaria a btoa oppure usa un altro API che accetta direttamente i byte. Per la decodifica, atob restituisce la stringa binaria; recuperare i suoi valori in byte e trasmetterli a TextDecoder("utf-8"). ToolAcre utilizza un decodificatore rigoroso che rifiuta UTF-8 malformato invece di inserire silenziosamente caratteri sostitutivi.
Esempio realizzato: codificare 'café 😀' con TextEncoder e btoa: la sequenza di byte, la stringa binaria intermedia e l'output finale
Per il caffè testuale letterale 😀, i byte UTF-8 sono 63 61 66 C3 A9 20 F0 9F 98 80 in esadecimale: ASCII c-a-f, due byte per é, uno spazio e quattro byte per l'emoji. Base64 di questi dieci byte è Y2Fmw6kg8J+YgA==. Il riempimento e l'alfabeto descrivono solo i byte; non etichettano la lingua. Confronta un errore diretto di btoa ("café 😀") con la modalità UTF-8 di ToolAcre, quindi decodifica il risultato e verifica che sopravvivano lo stesso accento visibile e le stesse emoji.
Il vecchio trucco unescape(encodeURIComponent()) e perché è un hack: cosa fa dietro le quinte e perché è sconsigliato
Una soluzione storica è btoa(unescape(encodeURIComponent(text))). encodeURIComponent percent-encodes UTF-8 e unescape reimpacchetta triplette percentuali come singole unità di codice, ma unescape è deprecato, difficile da leggere e scomodo con surrogati solitari malformati. Fa sembrare una conversione come se fosse in elaborazione URL anche quando non esiste URL. TextEncoder indica chiaramente il limite previsto: il testo diventa byte una volta e Base64 funziona solo dopo.
Decodifica dall'altra parte: associando atob con TextDecoder in modo che il viaggio di andata e ritorno sia senza perdite
Dopo atob, non chiamare decodeURIComponent su byte binari arbitrari e sperare che diventino testo. Converti i codici carattere in un Uint8Array e passalo tramite TextDecoder. Nell'esempio del café 😀 il risultato è la sequenza originale UTF-8 di dieci byte, quindi la stringa originale. Se Base64 decodifica in byte di immagine o file compresso, potrebbe non rappresentare affatto testo UTF-8 valido; ToolAcre riporta che invece di fingere che i dati binari siano leggibili in prosa.
Ciò che questo non copre: codifica di file e BLOB binari, varianti base64url e streaming di input di grandi dimensioni
Questa spiegazione riguarda il testo codificato come UTF-8. File e BLOB Base64, Base64url per segmenti JWT e la codifica incrementale di dati multi-gigabyte hanno interfacce o esigenze di memoria diverse. Base64 inoltre non crittografa un token: chiunque lo possieda può decodificare i byte. Il decodificatore può accettare il riempimento comune e gli spazi bianchi mancanti, ma l'interoperabilità dipende ancora dalla conoscenza se il carico utile è testo o dati binari arbitrari.
Conclusione: codifica byte, non stringhe, e controlla il viaggio di andata e ritorno: come il codificatore e decodificatore Base64 esegue il passo UTF-8 per te in modo che accenti, CJK ed emoji sopravvivano
Codifica byte, non stringhe JavaScript grezze, quindi controlla il viaggio di andata e ritorno. Il codificatore e decodificatore Base64 esegue i passaggi TextEncoder e TextDecoder per te mantenendo il testo incollato nel browser. RFC 4648 specifica l'alfabeto e il riempimento; UTF-8 fornisce il contratto separato da carattere a byte. Mescolare questi due livelli è la radice sia di InvalidCharacterError che della silenziosa corruzione Latin-1.