Entwicklertools · Base64-Encoder und -Decoder
Warum btoa() Emojis auslöst und wie man UTF-8 in JavaScript mit Base64 kodiert
· Wie es funktioniert
base64 Unicode Kodierung
btoa() akzeptiert nur Zeichen bis zu U+00FF, also akzentuierten Text, CJK und Emoji. Dieser Beitrag zeigt, was die Funktion tatsächlich erwartet und wie TextEncoder Ihnen einen korrekten UTF-8 Base64-String liefert.
Warum Btoa Unicode nutzen kann – und stillschweigend einen Akzent falsch kodiert
Der Aufruf von btoa("😀") löst einen InvalidCharacterError aus, da das Emoji nicht in eine einzelne Codeeinheit in Bytegröße passt. Ein subtilerer Fehler ist btoa("é"): vorkomponiertes é ist U+00E9, unter 256, also akzeptiert btoa es, kodiert aber Latin-1 byte E9, nicht UTF-8 bytes C3 A9. Derselbe sichtbare Akzent, geschrieben als e, plus ein Kombinationszeichen kann auslösen, weil das Zeichen außerhalb des akzeptierten Bereichs liegt. Die Abkürzung „ein Akzent wirft“ in der Arbeitsmappe erfordert diese Einschränkung: Eine Zeichenfolge kann laut oder leise ausfallen und die falschen Bytes erzeugen.
Was btoa() wirklich kodiert: eine binäre Zeichenfolge mit Codeeinheiten 0–255 – warum die Funktion auf Latin-1 bytes und nicht auf Unicode-Text ausgelegt ist
btoa verbraucht eine „Binärzeichenfolge“: Jede JavaScript-Zeichencodeeinheit muss im Bereich von 0–255 liegen und steht für ein Byte. Es versteht keine Unicode-Textkodierung, -Sprache oder -Normalisierung. Ein Astral-Emoji wird durch zwei UTF-16-Ersatzcodeeinheiten dargestellt, die beide viel größer als 255 sind, sodass das direkte Senden der rohen JavaScript-Zeichenfolge nicht funktionieren kann. Behandeln Sie die Ausgabe als Kodierung von Bytes, nicht von abstrakten Zeichen.
Zuerst UTF-8, dann Base64 – warum Text in Bytes umgewandelt werden muss, bevor ein Base64-Alphabet angewendet wird
TextEncoder wandelt einen JavaScript-String zunächst in seine UTF-8 byte-Sequenz um. Wandeln Sie dann jedes Byte in ein Binärzeichenfolgen um und übergeben Sie diese Binärzeichenfolge an btoa oder verwenden Sie eine andere API, die Bytes direkt akzeptiert. Zur Dekodierung gibt atob die Binärzeichenfolge zurück; stellt seine Bytewerte wieder her und gibt sie an TextDecoder("utf-8"). ToolAcre verwendet einen strikten Decoder, der fehlerhaftes UTF-8 ablehnt, anstatt stillschweigend Ersatzzeichen einzufügen.
Arbeitsbeispiel: Codierung von „café 😀“ mit TextEncoder und btoa – die Bytesequenz, die binäre Zwischenzeichenfolge und die endgültige Ausgabe
Für den wörtlichen Text Café 😀 lauten die UTF-8 bytes 63 61 66 C3 A9 20 F0 9F 98 80 im Hexadezimalformat: ASCII c-a-f, zwei Bytes für é, ein Leerzeichen und vier Bytes für das Emoji. Base64 dieser zehn Bytes ist Y2Fmw6kg8J+YgA==. Die Auffüllung und das Alphabet beschreiben nur die Bytes; Sie kennzeichnen die Sprache nicht. Vergleichen Sie einen direkten btoa-Fehler („café 😀“) mit dem UTF-8-Modus von ToolAcre, dekodieren Sie dann das Ergebnis und stellen Sie sicher, dass derselbe sichtbare Akzent und dasselbe Emoji erhalten bleiben.
Der alte unescape(encodeURIComponent())-Trick und warum es ein Hack ist – was er unter der Haube tut und warum davon abgeraten wird
Eine historische Problemumgehung ist btoa(unescape(encodeURIComponent(text))). encodeURIComponent kodiert UTF-8 in Prozent und unescape packt Prozenttripel als einzelne Codeeinheiten um, aber unescape ist veraltet, schwer zu lesen und bei fehlerhaften einzelnen Ersatzzeichen umständlich. Dadurch sieht eine Konvertierung wie eine URL-Verarbeitung aus, auch wenn keine URL vorhanden ist. TextEncoder gibt die beabsichtigte Grenze klar an: Text wird einmal zu Bytes und Base64 funktioniert erst danach.
Dekodierung auf der anderen Seite – Kombination von atob mit TextDecoder, damit der Roundtrip verlustfrei ist
Rufen Sie nach atob nicht decodeURIComponent für beliebige Binärbytes auf und hoffen Sie, dass diese zu Text werden. Konvertieren Sie Zeichencodes in ein Uint8Array und übergeben Sie es über TextDecoder. Im Café-Beispiel 😀 ist das Ergebnis die ursprüngliche zehn Byte lange UTF-8-Sequenz und dann die ursprüngliche Zeichenfolge. Wenn Base64 in Bild- oder komprimierte Dateibytes dekodiert, stellt es möglicherweise überhaupt keinen gültigen UTF-8-Text dar; ToolAcre berichtet, dass Binärdaten nicht vorgetäuscht werden, sondern lesbare Prosa sind.
Was dies nicht abdeckt – Datei- und Binärblob-Kodierung, Base64URL-Varianten und Streaming großer Eingaben
Diese Erklärung betrifft Text, der als UTF-8 codiert ist. Datei und Blob Base64, Base64url für JWT-Segmente und inkrementelle Codierung von Multi-Gigabyte-Daten haben unterschiedliche Schnittstellen oder Speicheranforderungen. Base64 verschlüsselt einen Token auch nicht: Jeder, der ihn besitzt, kann die Bytes entschlüsseln. Der Decoder kann häufig fehlende Auffüllungen und Leerzeichen akzeptieren, die Interoperabilität hängt jedoch immer noch davon ab, ob es sich bei der Nutzlast um Text oder beliebige Binärdaten handelt.
Fazit: Codieren Sie Bytes, keine Strings, und überprüfen Sie den Roundtrip – wie der Base64-Encoder und -Decoder den UTF-8-Schritt für Sie erledigt, damit Akzente, CJK und Emoji überleben
Codieren Sie Bytes, keine rohen JavaScript-Strings, und überprüfen Sie dann den Roundtrip. Der Base64-Encoder und -Decoder führt die Schritte TextEncoder und TextDecoder für Sie aus, während der eingefügte Text im Browser verbleibt. RFC 4648 spezifiziert das Alphabet und die Auffüllung; UTF-8 stellt den separaten Zeichen-zu-Byte-Vertrag bereit. Die Vermischung dieser beiden Ebenen ist die Ursache sowohl für InvalidCharacterError als auch für die stille Latin-1-Korruption.