Dekodieren aus dem Base64-Format

Übersicht

Base64 ist ein umkehrbarer Formwechsel, und dieses Tool ist die Hälfte der Rückreise: Es nimmt den druckbaren Text, den ein Koder erzeugt hat, und verwandelt ihn zurück in die Originaldaten. Fügen Sie eine Zeichenkette ein, wählen Sie die Einstellungen, die zu ihrer Herkunft passen, und das dekodierte Ergebnis ist bereit zum Lesen oder zum Kopieren. Wenn die Nutzlast Binärdaten wie ein Bild oder ein Archiv ist, lebt ihr Base64-Text in einer einfachen Datei: Das Dateiformular auf dieser Seite übernimmt diese Datei und gibt die Original-Binärdaten als Download zurück. Der passende Koder wohnt auf der Schwestersite, einen Link entfernt.

Erweiterte Optionen

• Zeichensatz: Base64 transportiert Bytes, keine Buchstaben, daher liest sich das dekodierte Ergebnis nur korrekt, wenn Sie wissen, in welchem Zeichensatz es vor der Kodierung gespeichert war. Wählen Sie den, der zu Ihrer Quelle passt: UTF-8 für modernen Text, Windows-1252 oder eine ISO-8859-Variante für ältere Dokumente oder AUTO-DETECT, damit das Tool entscheidet (es zeigt direkt neben der Liste, wofür es sich entschieden hat, und geht von UTF-8 aus, wenn es nicht unterscheiden kann). Wenn die Ausgabe wie ein durchgemischtes Alphabet aussieht, ist dies der erste Regler, den Sie drehen sollten. Dateien sind ausgenommen: Binärdaten werden so, wie sie sind, dekodiert, ohne Konvertierung.
• Jede Zeile separat dekodieren: Standardmäßig ist die gesamte Eingabe eine durchgehende Nutzlast: Zeilenumbrüche und Leerzeichen werden vor der Dekodierung entfernt, sodass eine Zeichenkette, die über Zeilen umgebrochen wurde und direkt aus einer E-Mail kopiert wurde, einfach funktioniert, und die URL-sicheren Zeichen - und _ werden anstelle von + und / akzeptiert. Aktivieren Sie dieses Kontrollkästchen, wenn die Eingabe eine Liste unabhängiger Einträge ist: Jede Zeile wird dann für sich dekodiert, und Sie erhalten die Ergebnisse je eines pro Zeile. Das Dateiformular bietet dieselbe Option.
• Live-Modus: Schalten Sie dies ein, und die Dekodierung erfolgt in Ihrem Browser, während Sie tippen, sie läuft bei jedem Tastendruck neu ab, ohne dass etwas an unsere Server gesendet wird. Sie beachtet die zeilenweise Option und funktioniert nur mit UTF-8, daher bleibt die Zeichensatzliste gesperrt, während der Modus aktiv ist, und die Dekodieren-Schaltfläche bleibt deaktiviert, bis Sie zurückschalten.

Sicher und geschützt

Alles läuft über eine verschlüsselte HTTPS-Verbindung, und nichts von dem, was Sie einreichen, wird aufbewahrt: Hochgeladene Dateien werden gelöscht, sobald sie verarbeitet sind, und das herunterladbare Ergebnis verschwindet sofort nach Ihrem ersten Download-Versuch oder nach 15 Minuten Inaktivität, je nachdem, was zuerst passiert. Der Inhalt dessen, was Sie senden, wird niemals gespeichert; die einzige Verarbeitung über die Konvertierung hinaus ist ein Sicherheits-Scan hochgeladener Dateien, der dazu dient, bösartige oder unangemessene Inhalte zu blockieren. Wenn der Live-Modus aktiv ist, verlässt Ihr Text den Browser niemals. Alle Details finden Sie in unserer Datenschutzrichtlinie, die unten in der Fußzeile verlinkt ist.

Vollkommen kostenlos

Alles auf dieser Seite ist kostenlos zu nutzen - die vollständige Zeichensatzliste, die Datei-Uploads und der Live-Modus inklusive. Kein Benutzerkonto, keine Software zum Installieren, keine Zahlungsschranke: Für eine Aufgabe dieser Größe sollte es genau so sein.

Base64 erklärt

Manche Daten können schlicht nicht durch einen reinen Textkanal reisen: ein Foto, ein Archiv, ein Hash, ein Stück Binärdaten, das eine 7-Bit-E-Mail-Verbindung zum Erliegen bringen würde. Base64 ist der Übersetzer für solche Momente. Es schreibt jede Folge von Bytes in einfachen, druckbaren Text um, damit die Daten in einem E-Mail-Textkörper, einem JSON-Dokument, einer XML-Datei oder einer URL sitzen und genau so ankommen, wie sie losgegangen sind. Die Übersetzung ist vollständig umkehrbar: Jedes Byte kommt zurück, in derselben Reihenfolge, und nichts geht unterwegs verloren.

Das gesamte Format passt in einen Satz: drei Bytes rein, vier Zeichen raus. Der Preis ist ein Ergebnis, das etwa ein Drittel größer ist als das Original. Die Belohnung ist eine Zeichenkette, die wie Text aussieht, sich wie Text verhält und Kanäle übersteht, die rohe Bytes zerstören würden. Und es lohnt sich, früh klarzustellen, was Base64 nicht ist: Es ist keine Verschlüsselung und keine Komprimierung. Es ist ein umkehrbarer Formwechsel, und das ist sein einziger Job.

Warum 64, und warum diese Zeichen

Ein Byte hält 8 Bits, aber alte Textkanäle, vor allem E-Mail, transportierten nur 7-Bit-ASCII sicher. Der Trick besteht darin, ein Alphabet druckbarer Zeichen zu wählen, das eine solche Reise übersteht, und es so groß zu bemessen, dass die Rechnung sauber aufgeht. Bei 64 Zeichen trägt jedes kodierte Zeichen genau 6 Bits, und 24 ist sowohl durch 8 (das Byte) als auch durch 6 (das Zeichen) teilbar: drei Eingabe-Bytes werden zu vier Ausgabe-Zeichen ohne Rest. Der Name ist einfach die Basis dieser Zeichen-Mathematik, wie die Zehnerbasis für unsere Ziffern.

Das Standardalphabet sind die 62 alphanumerischen Zeichen, A bis Z, a bis z und 0 bis 9, mit + und / als den letzten beiden. Die Spezifikation fügt ein 65. Zeichen hinzu, =, das gar nicht zum Alphabet gehört: Es erscheint ausschließlich am Ende, als Auffüllung. Diese Wahl war bewusst. Die gesamte Menge ist druckbar; sie ist allen Textsystemen gemein; und die MIME-Spezifikation stellt fest, dass sie in jeder Version von ISO 646, einschließlich US-ASCII, und in jeder Version von EBCDIC identisch geschrieben ist. Gerade diese letzte Eigenschaft hält die Daten unversehrt, während sie die alte, nicht 8-Bit-saubere Technik des Internets durchqueren.

Kodierung, Schritt für Schritt

Der Koder ist ein vierstufiges Fließband. Er liest die Eingabe drei Bytes auf einmal und verbindet jedes Triplett zu einer einzelnen 24-Bit-Zeichenkette. Diese Zeichenkette wird in vier Blöcke zu je 6 Bits geschnitten. Jeder Block ist eine Zahl von 0 bis 63, und jede Zahl wird in der obigen Tabelle nachgeschlagen. Vier Zahlen rein, vier Zeichen raus.

Sehen Sie zu, wie es am Wort foo passiert, das als die Byte-Werte 102, 111 und 111 (hex 66, 6F, 6F) ankommt. Aneinandergelegt sind die 24 Bits 01100110 01101111 01101111. In Sechser geschnitten ergibt das 011001, 100110, 111101 und 101111, also 25, 38, 61 und 47. Die Tabelle sagt, dass das Z, m, 9 und v sind, also wird foo zu Zm9v kodiert, und jeder Base64-Dekoder auf der Welt wird es zurück in die ursprünglichen drei Bytes verwandeln.

Der Rest der Eingabe wird auf dieselbe Weise verarbeitet, Triplett für Triplett, bis nichts mehr übrig ist. Nur die letzte Gruppe, wenn sie weniger als drei Bytes enthält, braucht einen besonderen Zug.

Auffüllung: das = am Ende

Die Eingabe ist immer eine ganzzahlige Anzahl von Bytes, aber drei teilt sie nicht immer gleichmäßig. Wenn am Ende ein oder zwei Bytes übrig bleiben, muss der Koder trotzdem eine vollständige Gruppe von vier Zeichen abschließen. Er füllt die fehlenden Bits mit Nullen auf, erledigt die Nachschlagen wie üblich und ersetzt die Zeichen, die die Auffüll-Bits erzeugt hätten, durch =-Zeichen. Genau drei Endungen sind möglich:

Also wird fo, zwei Bytes, zu Zm8=, und das einsame f wird zu Zg==, während foo gar keine Auffüllung braucht. Der Dekoder weiß genau, was er mit den Auffüllzeichen zu tun hat: Jedes = bedeutet acht weitere Null-Bits, die weggeschmissen werden. Die Auffüllzeichen sitzen ausschließlich am ganz Ende, und es sind höchstens zwei. Die MIME-Spezifikation nutzt dies sogar als Funktion: Da = nirgends sonst vorkommen kann, kündigt eine aufgefüllte Nutzlast ihr eigenes Ende an, und der Empfänger kann erkennen, dass die Daten beim Transport nicht abgeschnitten wurden. Und für den kleinsten Fall: Die leere Eingabe wird zu der leeren Ausgabe kodiert. Selbst Nichts unternimmt eine perfekte Hin- und Rückreise.

Dekodierung: das Fließband in umgekehrter Richtung

Die Dekodierung ist dieselbe Maschine, die rückwärts läuft, und sie ist genauso mechanisch. Nehmen Sie vier Zeichen, schlagen Sie die echten nach (ein Auffüllzeichen steht für sechs Nullen), schreiben Sie die 24 Bits auf und geben Sie die ersten 16 Bits zurück, wenn ein Auffüllzeichen vorhanden ist, oder alle 24, wenn keines da ist. Vier Zeichen rein, drei Bytes raus; zwei Bytes raus mit einem Auffüllzeichen; ein Byte raus mit zwei. Die Null-Bits, die der Koder hinzugefügt hat, sind das Einzige, was weggeschmissen wird, und jedes andere Bit ist genau das, was reingekommen ist. Das ist es, was umkehrbar hier wirklich bedeutet: Das Format selbst ist verlustfrei, und die einzigen Dinge, die Ihren Daten etwas antun können, sind ein Kanal, der die Zeichenkette beschädigt, oder ein Dekoder, der still aufgibt.

Deshalb ist der Standard in einer Sache streng: Zeichen, die nicht im Alphabet sind. RFC 4648 sagt, dass ein Dekoder eine Nutzlast ablehnen muss, die ein Zeichen außerhalb der 64 enthält, es sei denn, die umgebende Spezifikation erlaubt es ausdrücklich. Der Grund ist praktisch, nicht pedantisch. Ein Dekoder, der fremde Zeichen still schluckt, kann getäuscht werden: Die Schmuggelzeichen werden zu einem versteckten Seitenkanal, und genau dieser Trick wurde verwendet, um Daten vor Filtern zu verstecken und an Fehlern von Dekodern zu rütteln. Die berühmte Ausnahme ist MIME selbst, das älter ist als der Standard und das Gegenteil sagt: Ignoriere jedes Zeichen außerhalb des Alphabets, und so schaffen es die Zeilenumbrüche durch einen E-Mail-Anhang. Wenn Sie Eingaben selbst prüfen, ist die moderne Regel die richtige: Wenn Ihre Zeichenkette ein @, ein Leerzeichen oder irgendetwas anderes enthält, das nicht in der Tabelle steht, ist es kein sauberes Base64.

Zeilenumbrüche und die 76-Zeichen-Regel

Sie werden oft auf in Zeilen umgebrochenes Base64 stoßen, und der Brauch kommt aus der E-Mail. Die alte SMTP-Technik hatte Zeilenlängenbegrenzungen, daher bricht MIME die Nutzlast nach 76 Zeichen pro Zeile mit CRLF-Bruch um, und das ältere PEM-Format, das Zertifikate und Schlüssel trägt, bricht nach 64 Zeichen um. Die Regel von RFC 4648 für neuen Code ist das Gegenteil: Fügen Sie überhaupt keine Zeilenumbrüche ein, es sei denn, das Format, das Sie implementieren, verlangt es. In der Praxis ist dem Dekoder das egal. Ein Zeilenumbruch ist einfach ein Zeichen außerhalb des Alphabets, daher dekodieren eine MIME-umgebundene Nutzlast, ein PEM-Block und eine lange ununterbrochene Zeichenkette alle zu denselben Bytes. Wenn Sie Base64 von irgendwoher einfügen, entfernen Sie zuerst die Zeilenumbrüche, und damit ist die Sache erledigt.

Das Umbrechen hat einen kleinen Preis, und er zeigt sich in der Größenrechnung. Ohne Zeilenumbrüche ist Base64 genau vier Drittel des Originals, etwa 33 Prozent größer. Umgebrochen nach 76 Zeichen mit CRLF-Brüchen ist es etwa 37 Prozent größer, deshalb kommt eine Datei, die 100 KB groß sein sollte, oft als rund 137 KB Text an. Die Rechnung geht immer auf.

Base64URL: der URL-sichere Zwilling

Das Standardalphabet hat zwei Zeichen, die sich nicht gut mit URLs vertragen. Ein + in einem Query-String wird traditionell als Leerzeichen gelesen, und / ist ein Pfadseparator, daher braucht eine rohe Base64-Zeichenkette in einer URL für beide das Percent-Encoding, plus die =-Auffüllzeichen. Abschnitt 5 von RFC 4648 definiert die Lösung: das URL- und Dateinamen-sichere Alphabet, in dem + zu - und / zu _ wird. Die Auffüllzeichen verschwinden in der Regel ebenfalls, denn ein fehlendes Auffüllzeichen lässt sich aus der Länge herleiten. Der RFC stellt unmissverständlich klar, dass man dies nicht als reines Base64 bezeichnen sollte: Es ist eine andere Kodierung, meist geschrieben base64url.

In der Praxis unterscheiden sich die beiden nur um einen Tausch - und in der gefährlichen Richtung. Füttert man eine base64url-Zeichenkette einem Standard-Dekoder, geht etwas schief, denn - und _ sind nicht im Standardalphabet: Ein nachsichtiger Dekoder wirft sie weg und gibt eine kürzere, falsche Byte-Sequenz zurück, oder, wenn der Rest zu kurz ist, um allein zu stehen, einen Fehler, während ein strikter die gesamte Nutzlast ablehnt. Der richtige Tanz besteht darin, - wieder in + und _ wieder in / zu tauschen, die fehlenden Auffüllzeichen nachzufüllen und erst dann zu dekodieren. Dies ist der Dialekt, den Sie in JSON Web Tokens (JWT), OAuth-State-Strings und den IDs einer bestimmten sehr großen Videosite antreffen.

Ein schneller Praxisleitfaden

Bevor Sie zu einem Tool greifen, können Sie einen Großteil der Zeichenkette selbst lesen. Ein paar Prüfungen verraten Ihnen, ob eine Nutzlast überhaupt Base64 ist und was sie verbirgt:

• Schauen Sie sich die Zeichen an. Standard-Base64 verwendet nur A bis Z, a bis z, 0 bis 9, + und /; der URL-sichere Zwilling verwendet - und _ anstelle dieser beiden. Jedes andere Symbol oder ein versehentliches Leerzeichen bedeutet, dass es kein sauberes Base64 ist.
• Prüfen Sie die Auffüllzeichen. Die =-Zeichen, wenn vorhanden, sitzen nur am ganz Ende, und es sind höchstens zwei. Ein Auffüllzeichen in der Mitte der Zeichenkette ist ein Warnsignal.
• Zählen Sie die Länge. Mit Auffüllzeichen ist die Länge immer ein Vielfaches von 4. Ohne Auffüllzeichen lässt die Division der Länge durch 4 einen Rest von 0, 2 oder 3. Ein Rest von 1 ist unmöglich, denn ein einzelnes Zeichen trägt nur 6 Bits und ein Byte braucht 8.
• Schätzen Sie die Größe. Jede Gruppe von 4 Zeichen enthält 3 Bytes, abzüglich eines Bytes pro =-Zeichen. Also sind Zm9vYmFy, acht Zeichen ohne Auffüllzeichen, 6 Bytes groß, und Zm9vYg==, acht Zeichen mit zwei Auffüllzeichen, 4.

Noch ein letzter Praxis-Trick, und der nützlichste. Der Koder muss die Auffüll-Bits auf null setzen, aber ein nachsichtiger Dekoder prüft sie nicht. Die Nutzlast Zg== dekodiert zu dem einzelnen Byte f, und genau so tut es Zh==: Die niedrigen Bits des letzten Zeichens sind in beiden Fällen Auffüllung, daher ergeben beide dasselbe Byte. Der Standard nennt die Null-Bit-Version die kanonische Form, und sie erlaubt strikten Dekodern, die andere abzulehnen. Zwei Zeichenketten, eine Nutzlast. Wenn sich zwei Systeme bei einem Base64-Wert nicht einigen, sind die Auffüll-Bits ein guter Ort, um die Suche zu beginnen.

Was Base64 nicht ist

• Keine Verschlüsselung. Es gibt keinen Schlüssel und kein Geheimnis; jeder kann eine Base64-Zeichenkette in einer Sekunde wieder in Bytes zurückverwandeln. Der RFC erwähnt sogar echte Vorfälle, in denen Leute Protokollwechsel berichteten, die ein "kodiertes" Passwort enthielten, weil sie überzeugt waren, die Kodierung würde es verbergen. Wenn die Daten sensibel sind, schützen Sie sie vor der Kodierung mit echter Kryptographie, nicht danach.
• Keine Komprimierung. Es geht in die andere Richtung: Das Ergebnis ist etwa 33 Prozent größer als die Eingabe, und noch größer, sobald Zeilenumbrüche hinzukommen. Base64 kauft Ihnen Text-Sicherheit, und verlangt dafür einen Preis in Größe.
• Kein Zeichensatz. Base64 transportiert Bytes, keine Buchstaben. Es weiß nicht und kümmert sich nicht darum, ob diese Bytes UTF-8-Text, eine veraltete Ein-Byte-Kodierung oder ein JPEG sind. Die Frage "Welcher Zeichensatz ist das?" gehört vor die Kodierung und hinter die Dekodierung, niemals dazwischen.
• Nicht eine einzige Kodierung. Der Name deckt eine Familie ab: das Standardalphabet, den URL-sicheren Zwilling, Nutzlasten, die auf 76 oder 64 Zeichen umgebrochen sind, Varianten, die die Auffüllzeichen weglassen, und eine Handvoll Außenseiter (IMAP beispielsweise verwendet ein Komma anstelle des / im Alphabet, wenn es internationale Postfachnamen kodiert). Wenn sich zwei Systeme bei einer Nutzlast nicht einigen, ist meist ein Dialektunterschied der Übeltäter.

Die Kleingedruckten

Die Primärquellen sind kurz und lesbar. RFC 4648, Die Base16-, Base32- und Base64-Datenkodierungen (2006), ist der aktuelle Standard: beide Alphabete, die Auffüll- und Zeilenumbruch-Regeln, die Strengeanforderungen und eine Reihe offizieller Testvektoren, wie foo zu Zm9v wird, gegen die sich Implementierungen selbst prüfen. Hinter ihm steht RFC 2045, die MIME-Spezifikation von 1996, aus der die 76-Zeichen-Zeilenregel und die Nachsicht bei versehentlichen Zeichen stammen, und RFC 1421, die ausrangierte Privacy Enhanced Mail-Spezifikation, die die Familie mit 64-Zeichen-Zeilen begann. Ein früherer Vereinheitlichungsversuch, RFC 3548, wurde von RFC 4648 ersetzt.

Das ist die ganze Geschichte: 64 Zeichen, drei Bytes rein und vier Zeichen raus, =, das das Ende abschließt, und der perfekte Hin- und Rückweg. Jedes Tool, jede Bibliothek und jeder Online-Konverter, den Sie je treffen werden, ist nur ein Tor dazu. Sobald Sie auf eine Base64-Zeichenkette blicken und die dahinter stehenden Bytes sehen können, überrascht Sie nichts mehr an diesem Format. Und wenn Sie bereit sind, den Dekoder selbst zu schreiben, übergeben Ihnen die Programmiersprachen-Artikel direkt unter diesem Abschnitt dieselben 64 Zeichen als lauffähigen Code: einen vollständigen Leitfaden pro Sprache.