Base64 Kodier- und Dekodierwerkzeug

Base64 ist eine Methode, die 64 druckbare Zeichen verwendet, um Binärdaten darzustellen. Diese 64 Zeichen umfassen Großbuchstaben A-Z, Kleinbuchstaben a-z, Ziffern 0-9 sowie die zwei Symbole + und /. Da nur druckbare Zeichen verwendet werden, können Base64-kodierte Daten sicher in Umgebungen übertragen werden, die nur Text unterstützen, wie E-Mails, Webseiten und JSON. Die kodierten Daten sind etwa 33% größer als die Originaldaten. Base64 erschien erstmals 1987 im PEM-Protokoll zur sicheren Übertragung von Binärdaten in E-Mails. Heute ist es einer der Internetstandards und wird in vielen Szenarien weit verbreitet eingesetzt, von E-Mail-Anhängen bis JWT-Tokens, von Bild-Einbettungen bis Datenübertragungen. Fast alle Programmiersprachen haben Base64-Kodierungs- und Dekodierungsfunktionen eingebaut.

Base64 ist eine von mehreren Binär-Text-Kodierungen, die in RFC 4648 (S. Josefsson, Oktober 2006) spezifiziert sind, zusammen mit Base16 (Hex) und Base32. Der Name 'Base64' und das Alphabet wurden ursprünglich für Privacy-Enhanced Mail (RFC 989, 1987) definiert, wo PEM binäre S/MIME- und X.509-Daten in eine druckbare ASCII-Hülle einbettete, damit sie 7-Bit-sichere Transporte überstehen konnten. Dasselbe Alphabet wurde später zum De-facto-Standard für MIME (RFC 2045), JWT-Signaturen (RFC 7519), HTML-data:-URIs (RFC 2397), SSH-öffentliche Schlüssel-Blobs (RFC 4253 §6.6) und Git-LFS-Zeigerdateien (die SHA-256-Hashes als Base64 speichern). Gits eigene Packfiles sind KEIN Base64 — sie verwenden Deltakodierung mit zlib-Komprimierung, und Git-Objekt-IDs sind 40-stellige Hex-SHA-1-Zeichenketten, kein Base64. Die Kosten: Je 3 Eingabebytes werden zu 4 Ausgabezeichen, sodass die kodierte Ausgabe genau 4/3 der Größe hat (33,3 % Überhang). Bei einem 10 MB großen Binärblob beträgt die kodierte Form ca. 13,3 MB. Der Mechanismus: Die Eingabe wird in 3-Byte-(24-Bit-)Gruppen aufgeteilt; jede Gruppe wird in vier 6-Bit-Werte zerlegt; jeder 6-Bit-Wert wählt ein Zeichen aus einem 64-Zeichen-Alphabet. Das kanonische Alphabet ist A–Z (Indizes 0–25), a–z (26–51), 0–9 (52–61), '+' (62), '/' (63), mit '=' als Füllzeichen. Das klassische RFC-4648-Beispiel: 'Man' (0x4d 0x61 0x6e) wird zum 24-Bit-Wert 0x4d616e gepackt; aufgeteilt in 6-Bit-Abschnitte ergibt 0x0d 0x16 0x0e 0x0a, zugeordnet zu 'TWFu'. Wenn die Eingabelänge kein Vielfaches von 3 ist, wird die abschließende Gruppe rechts mit Nullen aufgefüllt: 1 Byte übrig → 2 signifikante 6-Bit-Abschnitte + '==' (2 Füllzeichen); 2 Bytes übrig → 3 signifikante Abschnitte + '=' (1 Füllzeichen). Die Füllzeichen tragen keine Information, aber sie machen die Kodierungslänge zu einer deterministischen Funktion der Eingabelänge und ermöglichen es Decodierern, unvollständige Eingaben abzulehnen. Im Browser hat Base64 zwei bekannte Fallstricke. Erstens operieren `btoa` und `atob` (die DOMString-Varianten) auf Latin-1-Codewerten, nicht auf Bytes — eine Zeichenkette mit U+00E9 (é) oder U+4E2D (中) löst einen InvalidCharacterError aus. Die Seite umgeht dies, indem die Eingabe vor dem Aufruf von `btoa` durch `TextEncoder().encode(str)` (immer UTF-8) und nach `atob` durch `TextDecoder().decode(bytes)` geleitet wird. UTF-8-Mehrbytezeichen expandieren: '你' sind 3 Bytes (0xe4 0xbd 0xa0) → 4 Base64-Zeichen (8 Base64-Zeichen für '你好'). Zweitens ersetzt Base64URL (RFC 4648 §5) '+' und '/' durch '-' und '_' und entfernt die Auffüllung, weil '+' und '/' URL-signifikant sind und '=' Abfragezeichenketten beendet. JWT (RFC 7519) und JWS (RFC 7515) erfordern Base64URL genau aus diesem Grund. Base64 ist Kodierung, keine Verschlüsselung — die kodierte Form hat keinerlei Geheimhaltung, und das Alphabet ist so kurz, dass jeder Beobachter das Ergebnis mühelos lesen kann. Base64 für einen Sicherheitsmechanismus zu halten, ist ein CVE-Muster: CVE-2004-2761 dokumentierte die X.509-MD5-Chosen-Prefix-Kollision, die es Angreifern erlaubte, Zertifikate mit kollidierenden MD5-Signaturen zu fälschen, während CVE-2005-4900 und andere die alte Praxis betrafen, bei der `$1$`-md5crypt-Passwort-Hashes von einer Authentifizierungsschicht erneut kodiert oder gehasht wurden, die Base64-dekodierte Bytes mit neuen Anmeldedaten verwechselte. Das wiederkehrende Muster ist dasselbe: Ein System behandelt die Kodierung so, als füge sie eine Geheimhaltungsebene hinzu, die sie nicht besitzt, und das Ergebnis ist ausnutzbar. Für echte Geheimnisse verwenden Sie AES-GCM (RFC 5288) oder ChaCha20-Poly1305 (RFC 8439). Bei Kompression-gefolgt-von-Base64 (was `gzip -b64` tut) ist zu beachten, dass die kodierte Form ca. das 1,37-fache der gzip-Größe beträgt und jede Byteänderung im komprimierten Strom die Decodierung bricht — Base64 ist daher eine schlechte Integritätsschicht; HMAC-SHA256 über die Bytes vor der Kodierung ist der richtige Ansatz.

• RFC 4648 (Oktober 2006) definiert Base64, Base32 und Base16 mit einem kanonischen Alphabet (A–Z, a–z, 0–9, +, /) und '=' als Füllzeichen. Die MIME-Variante (RFC 2045) fügt alle 76 Zeichen Zeilenumbrüche für den Transport ein; die URL-sichere Variante (Base64URL, RFC 4648 §5) ersetzt + und / durch - und _ und entfernt die Auffüllung — verwendet von JWT (RFC 7519), JWS (RFC 7515) und JWK (RFC 7517).
• Mechanismus: 3 Eingabebytes (24 Bit) → 4 Ausgabezeichen (je 6 Bit). Der Überhang beträgt 33,3 % — jeder 1 MB Binäreingabe wird zu 1,33 MB Base64. Bei ASCII kann das Verhältnis noch schlechter sein, wenn die Eingabe '=' oder andere Zeichen enthält, die von umgebenden Protokollen escaped werden.
• Auffüllregel: Eingabelänge mod 3 = 0 → keine Auffüllung; mod 3 = 1 → '==' (zwei Füllzeichen, ein Byte kodiert); mod 3 = 2 → '=' (ein Füllzeichen, zwei Bytes kodiert). '=' enthält keine Information; es teilt dem Decoder nur mit, wie viele Bytes entfernt wurden.
• UTF-8 + btoa-Fallstrick: `btoa('é')` löst InvalidCharacterError aus, weil btoa die Eingabe als Latin-1-Codewerte behandelt. Die Seite umgeht dies, indem sie vor btoa durch `TextEncoder` (UTF-8) kodiert und nach atob durch `TextDecoder` dekodiert. Ohne diesen Schritt wird alles außerhalb von U+0000..U+00FF zu '0 Bytes kodiert' statt zu einem Fehler.
• Base64URL ist für JWT, JWS und JWK erforderlich (RFC 7519/7515/7517). Es verwendet '-' und '_' statt '+' und '/' (URL-signifikante Zeichen) und entfernt die '='-Auffüllung (die Abfragezeichenketten beendet). Ein JWT-Header-Segment an einen Base64-Decoder statt an einen Base64URL-Decoder zu übergeben, liefert Müll; die Seite erkennt nicht automatisch — wählen Sie die richtige Variante für die Nutzlast.
• Leistung: Die Kodierung liegt bei ca. 400–700 MB/s in V8 auf einem modernen Laptop (eine enge Schleife mit Tabellenlookups und Bitverschiebungen). Die Dekodierung hat ähnliche Geschwindigkeit. Bei großen Blobs (10+ MB) ist die Allokation der Engpass, nicht die Berechnung — der Ausgabepuffer ist 33 % größer und `TextEncoder/TextDecoder` erstellt eine Kopie.
• Base64 ist Kodierung, keine Verschlüsselung — jeder mit der Zeichenkette kann sie lesen. CVE-2004-2761 (X.509-MD5-Chosen-Prefix-Kollision bei Zertifikatssignaturen) und viele MISC-CTF-Writeups nutzen dieses Missverständnis als ersten Schritt. Für Geheimnisse verwenden Sie AES-GCM (RFC 5288) oder ChaCha20-Poly1305 (RFC 8439). Bei data:-URIs beachten Sie die kodierte Größe: Ein 10-MB-Bild wird zu einer 13,3-MB-URL, was die meisten Browser-URL-Längenlimits und die meisten E-Mail-Größenlimits überschreitet.
• Hinweis zur Migration: Base16 (Hex) wird in Low-Level-Protokollen und Hash-Ausgaben bevorzugt, weil jedes Byte genau 2 Zeichen abbildet und die Länge vorhersagbar ist (keine Auffüllungsmathematik). Base32 wird für die manuelle Übertragung bevorzugt (keine ähnlich aussehenden Zeichen). Base64 ist die universelle Standardeinstellung für Binärtransport in Textprotokollen, wird aber schrittweise durch rohe Bytes über HTTP/2 und WebTransport ersetzt, wo es das Framing erlaubt.