Base64 kodieren / dekodieren

Was ist Base64?#

Base64 ist eine Art, beliebige Bytes mit nur 64 druckbaren ASCII-Zeichen zu schreiben (A-Z, a-z, 0-9, +, /, mit = als Padding). Es existiert, weil weite Teile der Computerwelt für Text entworfen wurden — E-Mail-Bodies, JSON-Felder, HTTP-Header, Data-URI-Präfixe — und sie verschlucken sich an rohen Bytes, besonders an Bytes mit gesetztem oberen Bit oder eingebetteten Steuerzeichen. Base64 ist die Lingua franca, die Sie greifen, wenn Sie binärgeformte Daten brauchen, die einen reinen Text-Kanal überstehen.

Je drei Eingabe-Bytes (24 Bit) werden vier Base64-Zeichen (jedes codiert 6 Bit). Deshalb ist Base64-Ausgabe immer ein Vielfaches von vier Zeichen lang und warum sie etwa 33 % größer ist als die ursprünglichen Bytes — die Redundanz ist der Preis der Druckbarkeit. Wenn die Eingabelänge kein Vielfaches von drei ist, erscheinen am Ende ein oder zwei =-Padding-Zeichen.

Diese Seite kodiert und dekodiert Base64 sicher mit UTF-8. Eine Falle, in die Leute ständig tappen: einen String direkt an btoa() zu übergeben, wirft InvalidCharacterError, sobald er ein Nicht-ASCII-Zeichen enthält (é, 中文, ein Emoji). Die Lösung ist, den Text zuerst in UTF-8-Bytes zu kodieren, dann in Base64 — genau das tut dieses Werkzeug, sodass café korrekt round-trippt, statt eine Exception zu werfen.

Verwendung#

1. Wählen Sie die Richtung mit dem Umschalter Kodieren / Dekodieren oben links auf der Werkzeugleiste.
2. Tippen Sie in die Eingabe-Fläche links oder fügen Sie ein.
   • Im Modus Kodieren wird die Eingabe als UTF-8-Text behandelt.
   • Im Modus Dekodieren sollte die Eingabe ein Base64-String sein. Whitespace wird toleriert.
3. Setzen Sie den Haken bei URL-sicher, wenn Sie das base64url-Alphabet brauchen (- und _ statt + und /, Padding entfernt). Das ist, was JWTs und viele signierte URL-Schemata erwarten.
4. Das Ergebnis erscheint live in der Ausgabe-Fläche rechts. Klicken Sie auf Kopieren, um es zu übernehmen.
5. Verwenden Sie Beispiel, um ein Demonstationspaar einzufügen, und Leeren, um beide Flächen zurückzusetzen.

Eckpunkte#

• UTF-8-sicher in beide Richtungen. Die Kodierung leitet den Text zuerst durch TextEncoder, sodass Multibyte-Zeichen nie explodieren; die Dekodierung leitet die Bytes durch TextDecoder, sodass der Ursprungstext exakt wiederhergestellt wird.
• Standard- und URL-sicheres Alphabet. Ein Kontrollkästchen schaltet zwischen klassischem Base64 (+/=) und base64url (-_ ohne Padding), mit korrektem Re-Padding bei der Dekodierung.
• Rein clientseitig. Die Umwandlung läuft nur in Ihrem Browser ab — es gibt kein Backend und keine Netzwerkanfrage. Ein sensibles Token hier einzufügen, sendet es nirgendwohin.
• Live-Statuszeile. Die Leiste unter den Flächen meldet Kodier-/Dekodierfehler (zum Beispiel eine %-förmige oder abgeschnittene Eingabe), statt stillschweigend Müll zu erzeugen.

Konkretes Beispiel#

Mit Kodieren und dem Standardmodus (nicht URL-sicher) wird der ASCII-Text Hello, World! zu:

SGVsbG8sIFdvcmxkIQ==

Die zwei abschließenden = zeigen, dass die 13-Byte-Eingabe kein Vielfaches von drei war — das ist erwartbar, kein Fehler.

Die UTF-8-Behandlung zählt, sobald Sie ASCII verlassen. Das Kodieren von café (wobei é zwei UTF-8-Bytes sind, c3 a9) ergibt:

Y2Fmw6k=

Hätten Sie btoa("café") direkt in einer Konsole aufgerufen, hätte es geworfen. Dieses Werkzeug wirft nicht, weil es zuerst UTF-8-Bytes kodiert.

Der URL-sichere Modus schreibt das Alphabet um, sodass die Ausgabe niemals Zeichen trägt, die eine URL mislesen würde: + wird zu -, / wird zu _ und das abschließende =-Padding wird entfernt (bei der Dekodierung automatisch wieder hinzugefügt). Nehmen Sie die Standardausgabe von oben, SGVsbG8sIFdvcmxkIQ== — im URL-sicheren Modus werden die zwei Padding-= entfernt, was SGVsbG8sIFdvcmxkIQ ergibt. Die +// → -/_-Vertauschung ändert nur etwas, wenn diese Zeichen tatsächlich in der Ausgabe erscheinen, was dazu neigt bei binären Payloads wie Hash-Digests oder Zufallstokens aufzutreten — genau die Art von Daten, die Sie in einen URL-Pfad oder Query-Parameter einsetzen, ohne weiteres Escaping.

FAQ#

Mein dekodierter Text erscheint als Mojibake. Was ist passiert?#

Fast immer war das Base64, das Sie dekodiert haben, die Kodierung von Bytes in einem anderen Zeichensatz (oft Latin-1 oder Windows-1252), nicht UTF-8. Dieses Werkzeug dekodiert die Bytes als UTF-8, sodass ein Latin-1-kodiertes é (0xe9, ein einzelnes Byte) kein gültiges UTF-8 ist und falsch erscheint. Finden Sie heraus, wie die Gegenseite den Ursprungstext kodiert hat, oder kodieren Sie ihn zuerst als UTF-8.

Standard-Base64 oder base64url — was will ich?#

Standard (+/=) ist der Standard für alles, was nicht in eine URL geht: E-Mail-Anhänge, data:-URIs, JSON-Felder, die Binäres tragen. Schalten Sie URL-sicher ein, wenn die Ausgabe in einem URL-Pfad, einem Query-String oder einem JWT-Segment sitzen wird, wo +, / und = entweder das Parsing brechen oder vom Transport verfälscht werden. Das Dekodieren beider Formen wird automatisch akzeptiert.

Warum ist die kodierte Ausgabe länger als meine Eingabe?#

Das ist inhärent, kein Bug. Base64 packt 6 Bit pro Zeichen statt 8, deshalb ist die Ausgabe etwa 4/3 der Größe der Eingabe — etwa 33 % Overhead. Bei sehr kleinen Eingaben kann sie relativ zum Original noch größer wirken, weil die feste Struktur dominiert.

Kann das einen Base64-String entschlüsseln oder knacken?#

Nein — Base64 ist eine Kodierung, keine Verschlüsselung. Es ist vollständig umkehrbar und trägt keinen Schlüssel. Jeder mit dem String kann ihn dekodieren. Wenn Sie tatsächlich Geheimheit brauchen, verschlüsseln Sie zuerst (zum Beispiel mit einem authentifizierten Verschlüsselungs-Schema) und base64-kodieren Sie dann den Ciphertext für den Transport.