Base64-Encoder und -Decoder

Base64 existiert, weil ein Großteil der um Text gebauten Infrastruktur — E-Mail, JSON, XML, URLs — beliebige binäre Bytes nicht zuverlässig transportieren kann, die Steuerzeichen, Null-Bytes, oder Byte-Sequenzen enthalten könnten, die eine Zeichenkette vorzeitig beenden oder einen Parser direkt zerstören. Base64 ordnet jede Gruppe von drei Bytes beliebiger Binärdaten vier Zeichen aus einem festen Satz von 64 zu, die jedes textbasierte System sicher behandelt — Buchstaben, Ziffern und zwei Symbole — daher kann das kodierte Ergebnis in JSON eingebettet, als E-Mail-Anhang gesendet, oder in ein Dokument eingefügt werden, ohne dass etwas nachgelagert es für etwas anderes als reinen Text hält.

Der Mehraufwand dieser Sicherheit ist fest und unvermeidlich: vier Ausgabezeichen pro drei Eingabebytes, eine Expansion von etwa 33%, unabhängig von den zugrunde liegenden Daten. Das ist der Preis für einen garantiert sicheren Durchgang durch reine Textkanäle, kein Fehler einer bestimmten Implementierung.

Die eingebaute `btoa`-Funktion des Browsers, auf die viele schnelle Base64-Implementierungen direkt zurückgreifen, wirft einen Fehler, sobald sie ein Zeichen über dem Codepoint U+00FF antrifft — was im Wesentlichen alle Emojis, Chinesisch, Japanisch, Koreanisch, Kyrillisch, Griechisch und Arabisch einschließt, plus ziemlich viele akzentuierte lateinische Zeichen, die in Deutsch, Französisch, Spanisch und anderen Sprachen verwendet werden. Das ist kein obskurer Randfall, der seltene Eingaben betrifft; es betrifft einen sehr großen Anteil echten Textes, und es ist der Grund, warum so viele selbst gebaute Base64-Tools in Tests mit reinem englischen Text perfekt funktionieren und dann beim ersten Mal scheitern, wenn ein Nutzer etwas mit einem Emoji oder einem nicht-lateinischen Namen einfügt.

Die Lösung ist, den Text zuerst als UTF-8-Bytes zu kodieren, dann diese Bytes in Base64 zu kodieren — was korrekt gebaute Encoder tun und was dieses Tool tut — statt zu versuchen, Unicode-Codepoints direkt in eine Kodierung zu drücken, die für Byte-Sequenzen unter 256 entworfen wurde.

Der Zeichensatz des Standard-Base64 enthält `+` und `/`, beide mit Bedeutung in einer URL — `+` wird manchmal als Leerzeichen interpretiert, und `/` ist ein Pfadtrenner — daher kann eine direkt in eine Query-Zeichenkette oder einen Dateinamen eingefügte Standard-Base64-Zeichenkette von dem, was diese URL parst, still beschädigt oder abgeschnitten werden. Base64URL ersetzt diese beiden Zeichen durch `-` und `_`, von denen keines eine besondere Bedeutung in einer URL trägt, und entfernt typischerweise auch die abschließenden `=`-Padding-Zeichen, die rein zur Längenmarkierung existieren und unnötig sind, sobald der Decoder bereits weiß, sie zu erwarten.

JSON Web Tokens verwenden Base64URL genau aus diesem Grund: Ein JWT ist dafür gedacht, in einem HTTP-Authorization-Header und manchmal einer URL zu reisen, und die reservierten Zeichen von Standard-Base64 würden das unzuverlässig machen.

Das lohnt sich klar zu sagen, weil diese Annahme oft auftaucht: Base64 bietet null Vertraulichkeit. Kein geheimer Schlüssel ist an irgendeinem Punkt des Prozesses beteiligt, daher kann jeder, der eine Base64-Zeichenkette erhält, sie sofort mit nichts weiter als einem Standard-Bibliotheksaufruf oder einem Tool genau wie diesem zurück zu den Originaldaten dekodieren. Ein Passwort oder einen API-Schlüssel vor dem Speichern oder Übertragen in Base64 zu kodieren bietet überhaupt keinen Schutz — es verbirgt nur den Wert bei beiläufigem Hinsehen, was eine sehr andere Eigenschaft als echte Sicherheit ist.