Entwicklertools · Base64-Encoder und -Decoder
Wofür atob und btoa stehen und warum sie nur Latein verstehen-1
· Hintergrund
base64 Javascript Unicode
atob und btoa stammen von Netscape und die Namen bedeuten „ASCII zu Binär“ und „Binär zu ASCII“. In diesem Beitrag erfahren Sie, woher sie kamen, wie die WHATWG-Standards sie definieren und warum sie Unicode nie gelernt haben.
Ein Funktionsname, der sich wie ein Tippfehler liest – die Verwirrung, die die Namen verursachen, und die einzeilige Antwort
atob und btoa sind integrierte JavaScript-Funktionen, die in den 1990er Jahren in Netscape eingeführt wurden. Die Namen sind Abkürzungen: btoa steht für Binary to ASCII und atob steht für ASCII to Binary. Die Namen spiegeln ihr Alter und Design wider: Sie wurden erstellt, als „binär“ eine Folge von Bytewerten bedeutete (0-255) und nicht das modernere Uint8Array oder Buffer. Die oft für die Namen angegebene Mnemonik ist weniger wichtig als der beobachtbare Vertrag: Eine Funktion ordnet einen Binärstring Base64 zu und die andere kehrt ihn um. Dieses Repository dokumentiert nicht die ursprüngliche Namensentscheidung, daher vermeidet der Artikel die Darstellung von Folklore als Quelle des Browserverlaufs.
Die Funktionen erwarten eine binäre Zeichenfolge: Die Codeeinheit jedes Zeichens muss im Bereich 0-255 liegen und ein Byte darstellen. Wenn Sie ein Zeichen mit einer Codeeinheit über 255 übergeben (wie ein Emoji oder ein akzentuierter Buchstabe außerhalb des lateinischen 1), löst die Funktion einen InvalidCharacterError aus oder erzeugt stillschweigend eine falsche Ausgabe. btoa (binär zu ASCII) kodiert eine Binärzeichenfolge nach Base64.
Was die Namen vermuten lassen und was der Byte-String-Vertrag tatsächlich beweist
Die Eingabe muss eine Zeichenfolge sein, bei der jedes Zeichen ein Byte ist (Codeeinheit 0-255). btoa(hello) kodiert die ASCII-Bytes als base64 und gibt aGVsbG8= zurück. btoa mit dem Buchstaben e-acute scheint zu funktionieren, da der vorkomponierte lateinische 1-Buchstabe e-acute (U+00E9) eine Codeeinheit von 233 hat, die zwischen 0 und 255 liegt. Btoa kodiert es jedoch als einzelnes Byte, 0xE9, und nicht als die UTF-8-Bytes 0xC3 0xA9, die e-acute erzeugen sollte. Bevor typisierte Arrays zum normalen Byte-Container wurden, verwendeten JavaScript-APIs Zeichenfolgen, deren Codeeinheiten für Bytes standen. Dieses Modell bleibt sichtbar, da BTOA Codeeinheiten über 255 ablehnt. Die genaue Produktchronologie wird durch diese Dateien nicht ermittelt; Die Fehlergrenze wird durch ausführbare Tests festgelegt.
Diese stille Korruption ist gefährlicher als ein Fehler: Das Ergebnis sieht gut aus, ist aber falsch. atob (ASCII zu Binär) dekodiert Base64 zurück in eine Binärzeichenfolge. atob(aGVsbG8=) gibt „Hallo“ zurück. Die Ausgabe ist eine binäre Zeichenfolge, wobei die Codeeinheit jedes Zeichens 0-255 ist und ein Byte darstellt. Wenn Sie dies in richtigen Unicode-Text konvertieren möchten, müssen Sie die Bytes als UTF-8 interpretieren und sie mit TextDecoder dekodieren.
Das alte Binärzeichenfolgenmodell – beobachtbares Verhalten ohne unbestätigten Browser-Verlaufsanspruch
Für ASCII ist dieser zusätzliche Schritt unnötig (ASCII ist eine Teilmenge von UTF-8), aber für alle Nicht-ASCII-Bytes ist er unerlässlich. atob führt diese Interpretation nicht durch; Es gibt die Rohbytes als Binärzeichenfolge zurück.
Die WHATWG-Standards (die Lebensstandards für Web-APIs) definieren atob und btoa in der HTML-Spezifikation. Die Definition enthält einen fehlerverzeihenden Base64-Dekodierungsalgorithmus für atob: Er überspringt Leerzeichen und akzeptiert fehlende Auffüllungen, wodurch reales Base64 (einschließlich MIME-umschlossenes Base64 mit Zeilenumbrüchen) dekodierbar wird. ToolAcre normalisiert Leerzeichen, URL-sichere Zeichensetzung und fehlende Auffüllung, bevor es den Browser-Decoder aufruft. Anschließend kopiert es zurückgegebene Codeeinheiten in Uint8Array und wendet einen schwerwiegenden UTF-8-Decoder an. Diese Kombination trennt die nachsichtige Base64-Syntax von der strengen Textinterpretation.
Aktuelles Verhalten in dieser Implementierung – verzeihende Alphabetnormalisierung und strikte UTF-8-Textdekodierung
Die Funktionssignatur hat sich nicht geändert, aber die Standarddefinition ist die Autorität für die Funktion der Funktion. Warum akzeptieren atob und btoa nur Latin-1? Denn als JavaScript in den 1990er Jahren entwickelt wurde, gab es keine Möglichkeit, Bytes direkt darzustellen (kein Uint8Array oder ArrayBuffer). Die einzige Möglichkeit, Bytes an eine Funktion zu übergeben, bestand in einer Zeichenfolge, bei der jedes Zeichen ein Byte darstellt.
Dies wird als Binärzeichenfolge bezeichnet und ist nach modernen Maßstäben verwirrend. Eine JavaScript-Zeichenfolge ist Unicode-Text, keine Folge von Bytes. Das Design hat die beiden zusammengeführt: Eine Zeichenfolge, bei der jede Codeeinheit 0-255 ist, ist eine Binärzeichenfolge. Die Benennung spiegelt die Ära wider: ASCII in BTOA bedeutete wörtlich sieben Bits für ASCII-Text, aber die Implementierung akzeptiert jedes Byte (0-255). Das direkte Hinzufügen eines Unicode-Modus zu BTOA würde den seit langem bestehenden Byte-String-Vertrag ändern und die Kompatibilität gefährden. Die überprüfte Quelle erstellt stattdessen TextEncoder vor der Codierung. Dieser Artikel kann diese Zusammensetzung überprüfen; Behauptungen über Beweggründe des Normungsausschusses, die nicht im Repository erfasst sind, werden nicht berücksichtigt.
Arbeitsbeispiel: Verfolgen von „forgiving-base64“ auf einer Zeichenfolge mit Leerzeichen und fehlender Auffüllung – was atob akzeptiert, was ein strikter Decoder ablehnt
Moderne Alternativen vermeiden das binäre String-Modell. Die Encoding-API stellt TextEncoder zum Konvertieren von Text in UTF-8 Bytes und TextDecoder zum Konvertieren von UTF-8 Bytes zurück in Text bereit.
Base64-Kodierung und -Dekodierung ist jetzt in der HTML-Spezifikation sowohl für Zeichenfolgen (atob und btoa) als auch für typisierte Arrays angegeben. Das Base64-Encoder- und Decoder-Tool verwendet TextEncoder und TextDecoder rund um atob und btoa, sodass Sie Unicode-Text ohne die Einschränkungen von Latin-1 sicher codieren und decodieren können. Ein mit Leerzeichen versehener oder nicht aufgefüllter Wert ist erfolgreich, da durch die Normalisierung Leerzeichen entfernt und die erforderliche Blocklänge wiederhergestellt wird. Ein Wert, dessen bereinigte Länge den Rest eins lässt, wird vor atob abgelehnt. Diese Unterscheidung zeigt, was „verzeihen“ hier bedeutet: Wiederherstellbare Formatierungen werden akzeptiert, strukturell unmögliche Eingaben jedoch nicht.
Neuere Standards funktionieren auf Base64 für typisierte Arrays – qualitativ beschrieben, mit einem Hinweis zur Überprüfung der aktuellen Browserunterstützung
Für die Verarbeitung von Unicode mit BTOA muss der Text zunächst in UTF-8 Bytes kodiert werden. Die alte Problemumgehung war btoa(unescape(encodeURIComponent(text))), was verwirrend ist, aber funktioniert: encodeURIComponent kodiert UTF-8 Bytes in Prozent, unescape wandelt Tripletts wieder in Zeichen um und btoa kodiert die resultierende Binärzeichenfolge. Dies funktioniert, basiert jedoch auf veralteten Funktionen und ist schwer zu lesen. Moderner Code sollte TextEncoder(text).map(byte => String.fromCharCode(byte)) gefolgt von btoa verwenden oder besser direkt in Uint8Array konvertieren und die Encoding-API verwenden.
Atob gibt Ihnen nicht automatisch Text; es gibt Ihnen binär. atob(Y2Fmw6kg8J+YgA==) gibt eine binäre Zeichenfolge zurück, die die Bytes von UTF-8-codiertem Text mit CAF-Akzent und Emoji enthält. Um den Text wiederherzustellen, konvertieren Sie die Binärzeichenfolge in ein Uint8Array und übergeben Sie sie an TextDecoder(utf-8). Das Base64-Encoder- und Decoder-Tool erledigt dies automatisch: Sie fügen Text ein, es codiert ihn in UTF-8 Bytes und dann in Base64. Typisierte Array-Base64-APIs werden in allen Browsern weiterentwickelt, diese Quelle verwendet sie jedoch nicht. Je nach Bedarf ist eine aktuelle Kompatibilitätsprüfung und ein Fallback-Plan erforderlich. Die explizite Byte-Array-Konvertierung von ToolAcre bleibt überprüfbar und wird von der aktuellen Testsuite abgedeckt.
Typisierte Array-Alternativen entwickeln sich weiter – überprüfen Sie die aktuelle Browserunterstützung, bevor Sie sich darauf verlassen
Sie fügen base64 ein, es dekodiert in UTF-8 Bytes und dann in Text. Der Zwischenschritt der Binärzeichenfolge ist ausgeblendet, da es sich um ein Implementierungsdetail der 1990er-API handelt. Das Verständnis von atob und btoa ist nützlich, um Legacy-Code zu debuggen oder mit alten APIs zu arbeiten, die Ihnen Binärzeichenfolgen liefern. Der meiste neue Code sollte das binäre String-Modell vollständig vermeiden.
Wenn Sie Base64 kodieren oder dekodieren müssen, verarbeitet das Base64-Encoder- und Decoder-Tool Unicode korrekt. Wenn Sie eine API erstellen, akzeptieren Sie Uint8Array oder eine typisierte Array-Ansicht oder dokumentieren Sie klar, ob Ihr Base64 UTF-8 oder Latin-1 ist. Bei der Überprüfung von Code, der BTOA mit Nicht-ASCII-Text ohne TextEncoder verwendet, liegt ein Fehler vor: Die Ausgabe codiert die falschen Bytes. Knotenpuffer- und Nicht-Browser-Laufzeiten definieren unterschiedliche APIs und Akzeptanzregeln. Sie werden bewusst ausgeschlossen. Die Ansprüche in diesem Artikel betreffen die Browser-Grundelemente und den in apps/dev, implementierten Wrapper, nicht jede Funktion mit dem Namen atob oder btoa in jeder Umgebung.
Imbiss: zwei Funktionen aus den 1990er Jahren mit einem Byte-String-Vertrag – wie der Base64-Encoder und -Decoder den UTF-8-Schritt um sie herum durchführt, also Akzente, CJK und Emoji-Roundtrip
Die Namen atob und btoa sind eigenartige Artefakte der Computertechnik der 1990er Jahre. Moderne Benennungen wären „base64Encode“ und „base64Decode“, und die APIs würden „Uint8Array“ oder Zeichenfolgen mit expliziten Codierungsdeklarationen akzeptieren. Aus Gründen der Abwärtskompatibilität bleiben atob und btoa jedoch in Browsern bestehen. Wenn Sie verstehen, was sie bedeuten (und was sie nicht tun können), können Sie stille Beschädigungen beim Codieren von Unicode-Text vermeiden.
Das Base64-Encoder- und Decoder-Tool schließt die Lücke: Es spricht die UTF-8- und Base64-Sprachen, die moderner Code benötigt. Das robuste Muster ist kompositorisch: Text in UTF-8 Bytes kodieren, Bytes in den Binärzeichenfolgenvertrag konvertieren und dann btoa aufrufen; Kehren Sie diese Schritte um atob um. Versuchen Sie es mit einem Akzent, CJK-Zeichen und Emojis und verlangen Sie dann, dass der dekodierte Text mit jedem ursprünglichen Codepunkt übereinstimmt.