Base64 kodieren und dekodieren: UTF-8, Base64url und Fehler

Text kodieren oder dekodieren

Öffnen Sie den Base64-Encoder und -Decoder und fügen Sie Text oder eine kodierte Zeichenfolge ein. Lassen Sie URL-sicheres Base64 für das Standardalphabet ausgeschaltet oder aktivieren Sie es, wenn das Zielformat Base64url verlangt. Kodieren wandelt die gesamte Eingabe in Base64 um; Dekodieren wandelt sie zurück in UTF-8-Text. Allein das Tippen startet keine Umwandlung.

Lesen Sie das Ergebnis, bevor Sie Ergebnis kopieren oder Herunterladen verwenden. Ergebnis als Eingabe verwenden ersetzt den Editorinhalt durch ein Ergebnis, das innerhalb des Eingabelimits liegt; anschließend können Sie die umgekehrte Aktion für eine Rückumwandlung wählen. Eine Änderung der Eingabe oder der Umwandlungsoptionen macht das alte Ergebnis ungültig. Zeilen umbrechen ändert nur den visuellen Umbruch, nicht die kodierten Zeichen oder die Zeilenumbrüche im Inhalt.

• Beginnen Sie mit einem bekannten Beispiel wie foo und Zm9v, bevor Sie einen Anwendungswert untersuchen.
• Wählen Sie das von Ihrer Anwendung benötigte Alphabet; gemeinsame Buchstaben und Ziffern allein lassen die Variante einer Zeichenfolge möglicherweise nicht erkennen.
• Bewahren Sie das Original auf, wenn jedes Byte erhalten bleiben muss. Textimport, Zeichenkodierung und zusätzliche Zeilenenden können ändern, was Sie kodieren.

Was Base64 mit Bytes macht

Base64 teilt jede Gruppe aus drei Bytes in vier Werte mit jeweils sechs Bits und ordnet diesen Werten Alphabetzeichen zu. Eine unvollständige letzte Gruppe erfordert eine besondere Behandlung und kann Padding verwenden. Die sichtbaren Buchstaben sind eine Darstellung der Eingabebytes; sie sind keine neue Sprache und kein geheimer Schlüssel.

Diese Beispiele mit dem Standardalphabet umfassen die leere Zeichenfolge und ASCII-Enden mit einem, zwei und drei Bytes. Leerzeichen und Zeilenumbrüche im Text, den Sie kodieren, sind tatsächliche Bytes und ändern das Ergebnis. Beim Dekodieren derselben kanonischen Kodierung erhalten Sie den ursprünglichen UTF-8-Text einschließlich dieser Zeichen zurück.

RFC 4648: Base64, Base64url, Padding und kanonische Kodierung

Standard-Base64 und Base64url

Beide Varianten verwenden Buchstaben und Ziffern. Standard-Base64 verwendet + und / als die letzten beiden Alphabetsymbole; Base64url verwendet - und _. ToolMellow gibt im Standardmodus die nötigen abschließenden = aus und lässt sie im URL-sicheren Modus weg. Das obige Emoji wird zum Beispiel im URL-sicheren Modus zu 8J-YgA.

Der Decoder akzeptiert nur das ausgewählte Alphabet. Beide Modi akzeptieren Eingaben ohne Padding oder mit korrekt platziertem optionalem Padding. Base64url verbietet Padding nicht grundsätzlich: Das umgebende Protokoll bestimmt, ob es erforderlich, erlaubt oder ausgelassen ist. Wählen Sie das benötigte Format, statt anzunehmen, dass jede URL oder jedes Token derselben Konvention folgt.

RFC 4648: Base64, Base64url, Padding und kanonische Kodierung

Unicode, Emojis und UTF-8-Dekodierung

Text wird über UTF-8 umgewandelt. Akzente, chinesischer oder arabischer Text und Emojis lassen sich daher hin und zurück umwandeln, wenn die Eingabe wohlgeformter Unicode ist. Die Länge einer JavaScript-Zeichenfolge zählt UTF-16-Codeeinheiten; die Länge in UTF-8-Bytes ist etwas anderes. Das Emoji 😀 belegt zwei UTF-16-Einheiten, aber vier UTF-8-Bytes, die acht Base64-Zeichen mit Padding erzeugen.

Das Kodieren weist ein ungepaartes Unicode-Surrogat zurück. Das Dekodieren weist ungültiges UTF-8 zurück, statt fehlerhafte Bytes stillschweigend zu ersetzen. Eine am Anfang kodierte UTF-8-BOM bleibt als U+FEFF in der dekodierten Zeichenfolge erhalten; sie kann im Editor unsichtbar sein. Gültiger Text kann außerdem Steuerzeichen oder unterschiedliche Unicode-Normalisierungsformen enthalten. Base64 normalisiert Text nicht und macht seine Ausführung nicht sicher.

RFC 3629: UTF-8-ZeichenkodierungWHATWG Encoding: TextEncoder, TextDecoder und BOM-BehandlungECMAScript: Zeichenfolgenlänge und isWellFormed

Padding, Leerraum und kanonische ungenutzte Bits

Padding besteht aus höchstens zwei abschließenden =-Zeichen, und die Länge mit Padding muss durch vier teilbar sein. Der Decoder erlaubt auch eine Eingabe ohne Padding mit einem gültigen Ende. Eine verbleibende Länge von eins kann jedoch kein vollständiges Byte darstellen. Zg== und Zg werden beide zu f dekodiert; Zg= ist fehlerhaft. Eine leere Eingabe hat ein gültiges leeres Ergebnis.

Vor dem Dekodieren entfernt ToolMellow ausschließlich TAB, LF, CR und SPACE. Seitenvorschub, vertikale Tabulatoren, geschützte Leerzeichen und anderer Unicode-Leerraum werden zurückgewiesen. Das ursprüngliche Eingabelimit wird vor dieser Entfernung geprüft. Dieses Verhalten ist damit enger als ein allgemeines Versprechen, sämtlichen Leerraum zu ignorieren.

In diesem Werkzeug müssen die ungenutzten Bits im letzten Alphabetsymbol null sein. Es prüft, ob das erneute Kodieren der dekodierten Bytes der normalisierten Eingabe ohne Padding entspricht. Zh== wird zurückgewiesen, obwohl ein toleranter Decoder dasselbe Byte wie bei der kanonischen Form Zg== erzeugen könnte. RFC 4648 erlaubt eine solche strengere Zurückweisung; die Annahme durch einen anderen Decoder beweist keine kanonische Eingabe.

RFC 4648: Base64, Base64url, Padding und kanonische KodierungWHATWG Infra: tolerante Base64-DekodierungWHATWG HTML: atob und btoa

Wie stark Base64 die Daten vergrößert und was hineinpasst

Bei n Eingabebytes beträgt die Länge von Base64 mit Padding 4 × ceil(n / 3) Zeichen. Null Bytes erzeugen null Zeichen; ein Byte erzeugt vier, zwei erzeugen vier und drei erzeugen vier. Der zusätzliche Umfang nähert sich bei großen Eingaben einem Drittel, beträgt aber nicht für jeden Wert genau 33%. Eine URL-sichere Ausgabe ohne Padding lässt das letzte oder die letzten beiden Paddingzeichen weg, sofern vorhanden.

Zählen Sie für die Größenformel UTF-8-Bytes und für das Editorlimit UTF-16-Codeeinheiten. Das Werkzeug erlaubt bis zu 1,000,000 Eingabecodeeinheiten, bevor beim Dekodieren Leerraum entfernt wird. Für die Ausgabe gilt nicht dieselbe Obergrenze: Eine Million ASCII-Bytes erzeugen 1,333,336 Zeichen mit Padding. Kopieren und Herunterladen bleiben verfügbar, aber Ergebnis als Eingabe verwenden kann kein Ergebnis über dem Eingabelimit laden.

RFC 4648: Base64, Base64url, Padding und kanonische KodierungWHATWG Encoding: TextEncoder, TextDecoder und BOM-BehandlungECMAScript: Zeichenfolgenlänge und isWellFormed

Eine Textdatei zu öffnen kodiert nicht ihre unveränderten Binärbytes

Die Dateiauswahl liest eine lokale Datei über File.text() als UTF-8-Text. Eine Datei ab 4,000,000 Bytes wird zurückgewiesen; Text mit mehr als 1,000,000 UTF-16-Einheiten wird auch nach dem Lesen zurückgewiesen. Die Anwendung lädt die Datei für diese Umwandlung nicht hoch. Die Dateiendung beweist nicht, dass ihre Bytes UTF-8-Text sind.

Das gewöhnliche Einlesen einer Datei als Text entfernt eine anfängliche UTF-8-BOM und ersetzt fehlerhafte UTF-8-Sequenzen. Das kann die ursprünglichen Bytes vor dem Kodieren verändern. Es unterscheidet sich vom Base64-Decoder, der fehlerhaftes UTF-8 zurückweist und dekodiertes U+FEFF erhält. Verwenden Sie für Bilder, PDFs, beliebige Bytes oder eine bytegenaue Dateiwiederherstellung gegebenenfalls das separate Werkzeug Base64 zu Datei; dieser Textbereich ist kein Encoder für unveränderte Binärdateien.

W3C File API: Blob als Text lesenWHATWG Encoding: TextEncoder, TextDecoder und BOM-Behandlung

Warum ist meine Base64-Eingabe ungültig?

Bestimmen Sie zuerst das erwartete Format und ob der Wert als Text dekodiert werden soll. Entfernen Sie umgebende Anwendungssyntax bewusst, statt unbekannte Zeichen zu löschen, bis es funktioniert. Dieser Decoder extrahiert nicht automatisch Nutzdaten aus Daten-URLs, Token-Segmente, JSON-Zeichenfolgen in Anführungszeichen oder HTML. Solche Hüllen haben eigene Regeln zum Parsen und Validieren.

Wenn Alphabet und Aufbau gültig sind, die dekodierten Bytes aber kein UTF-8 ergeben, können die Daten eine Binärdatei sein oder eine andere Zeichenkodierung verwenden. Das ist ein Fehler aufgrund des Textumfangs dieses Werkzeugs und kein Beweis für beschädigte Base64-Bytes. Ist der Zugriff auf die Zwischenablage nicht verfügbar, markieren und kopieren Sie das Ergebnis manuell. Ein nicht unterstützter Browser oder ein blockierter Worker kann die Umwandlung ebenfalls verhindern; verwenden Sie einen aktuellen unterstützten Browser und lesen Sie den angezeigten Fehler.

RFC 4648: Base64, Base64url, Padding und kanonische KodierungRFC 3629: UTF-8-Zeichenkodierung

Base64url, Prozentkodierung und Daten-URLs

Base64url und Prozentkodierung lösen unterschiedliche Aufgaben. Prozentkodierung stellt ausgewählte URL-Bytes mit %-Sequenzen dar; Base64url stellt eine gesamte Bytefolge mit einem eigenen Alphabet dar. Ein Pluszeichen wird speziell beim Parsen von application/x-www-form-urlencoded zu einem Leerzeichen, nicht grundsätzlich in jeder URL. Verwenden Sie für diese separate Aufgabe den URL-Encoder und -Decoder.

Eine Daten-URL hat das Schema data:, einen optionalen Medientyp und ein Komma vor ihren Nutzdaten, gegebenenfalls mit einer Base64-Markierung. Fügen Sie die gesamte Hülle in diesen Textdecoder ein, schlägt die Alphabetprüfung fehl. Extrahieren Sie die gewünschten Nutzdaten mit dem passenden Werkzeug und prüfen Sie, ob es sich um Text oder Binärdaten handelt. Base64 macht ein eingebettetes Skript, ein Dokument oder eine heruntergeladene Datei nicht vertrauenswürdig.

WHATWG URL: Parsen URL-kodierter FormulardatenRFC 2397: das Daten-URL-Schema

JWT-Segmente und HTTP Basic sind Protokolldaten

Kompaktes JWS verwendet drei durch Punkte getrennte Segmente; kompaktes JWE verwendet fünf. Das Dekodieren eines Textsegments eines JWT kann JSON sichtbar machen, prüft aber keine Signatur, entschlüsselt keine verschlüsselten Inhalte, validiert kein Ablaufdatum und begründet keine Berechtigung. Ein Signatursegment kann beliebige Bytes enthalten und muss sich nicht als UTF-8 dekodieren lassen. Folgen Sie dem tatsächlichen Token-Protokoll und verwenden Sie in Ihrer Anwendung eine gepflegte Verifikationsbibliothek.

HTTP-Basic-Zugangsdaten verwenden eine Base64-Darstellung einer Folge aus Benutzername und Passwort mit protokollspezifischen Regeln zur Zeichenkodierung. Base64 schafft keine Vertraulichkeit. Dieses UTF-8-Textwerkzeug beweist nicht, dass Zugangsdaten der Interpretation jedes Servers entsprechen. Veröffentlichen Sie keine echten Zugangsdaten als Beispiele und verwenden Sie den erforderlichen sicheren Transport sowie das vorgesehene Authentifizierungsverfahren.

RFC 7515: kompakte Serialisierung von JSON Web SignatureRFC 7516: kompakte Serialisierung von JSON Web EncryptionRFC 7617: HTTP-Basic-Authentifizierung

Base64 ist keine Verschlüsselung, kein Hashing und keine Komprimierung

Jeder, der einen Base64-Wert besitzt, kann die Darstellung ohne geheimen Schlüssel rückgängig machen. Verschlüsselung erfordert ein kryptografisches Verfahren und Schlüsselverwaltung; ein Hash erzeugt einen Digest mit anderen Zwecken und Eigenschaften. Ein Passwort in Base64 umzuwandeln ist keine geeignete Passwortspeicherung. Das separate Hash-Werkzeug erzeugt Digests und ist weder ein System zur Passwortspeicherung noch ein Ersatz für Verschlüsselung.

Base64 vergrößert Bytes außerdem, statt sie zu komprimieren. Es kann verschlüsselte, komprimierte oder signierte Bytes transportieren, erzeugt diese Schutzmechanismen aber nicht selbst. Entscheiden Sie vor dem Hinzufügen einer Kodierungsschicht, was Ihre Anwendung benötigt, und halten Sie Geheimnisse aus geteilten Beispielen, Bildschirmaufnahmen und heruntergeladenen Ergebnissen heraus.

RFC 4648: Base64, Base64url, Padding und kanonische Kodierung

Kopieren, herunterladen, zurückumwandeln und leeren

Herunterladen speichert das Ergebnis als UTF-8-Text in toolmellow-result.txt. Das ist weder eine binäre Wiederherstellung noch ein Umwandlungsbericht. Auch eine erfolgreiche leere Ausgabe aktiviert Ergebnis kopieren und Herunterladen. Für eine einfache Prüfung kodieren Sie bekannten Text, verwenden das Ergebnis als Eingabe, sofern es hineinpasst, und dekodieren es mit dem passenden Alphabet. Vergleichen Sie anschließend den ursprünglichen Text.

Leeren entfernt Eingabe, Ergebnis, Fehler, Such- und Ersetzungsinhalte sowie den Editorverlauf und behält die Auswahl für URL-sicheres Base64 und Zeilen umbrechen bei. Das Aktualisieren oder Schließen des Arbeitsbereichs verwirft seine im Arbeitsspeicher gehaltenen Arbeitsdaten; bereits heruntergeladene Dateien bleiben auf Ihrem Gerät. Leeren garantiert keine forensische Löschung aus dem Speicher des Browsers oder des Betriebssystems.

Was lokale Verarbeitung bedeutet und wo ihre Grenzen liegen

Die Umwandlung läuft in einem Browser-Worker. Die Anwendung sendet eingefügten Text, ausgewählte Dateiinhalte oder Umwandlungsergebnisse nicht an einen Umwandlungsserver. Die aktuelle Seite hält die Arbeitseingabe, statt sie in einem Kontoverlauf zu speichern. Auf der Datenschutzseite finden Sie die vollständige Erklärung zu Speicherung und vorübergehenden Übergaben.

Das Laden der Website erzeugt weiterhin Netzwerkanfragen. Die Hosting-Infrastruktur erhält gewöhnliche Verbindungs- und Anfragemetadaten, und die öffentliche Website verwendet Google Analytics für Seitenbesuche mit Cookies sowie Browser- und Geräteinformationen. Lokale Umwandlung bedeutet weder Anonymität noch ein Versprechen ohne Netzwerkverkehr oder Infrastrukturprotokolle. Heruntergeladene Dateien und ein manuell kopiertes Ergebnis können den Arbeitsbereich durch Ihre eigenen Handlungen verlassen.

Das Base64-Werkzeug mit seinem Rückverweis einbetten

Öffnen Sie den Integrationsbereich unter dem Werkzeug, wählen Sie die Seitensprache und kopieren oder laden Sie den bereitgestellten HTML-Code herunter. Fügen Sie ihn in einen HTML-Bereich ein, der externe Iframes und Skripte erlaubt. Der Code enthält das Iframe des ToolMellow-Arbeitsbereichs, sein Skript zur Größenanpassung und einen sichtbaren Rückverweis auf die passende ToolMellow-Werkzeugseite in derselben Sprache. Behalten Sie diesen Hinweis mit Link bei.

Prüfen Sie die Vorschau der Einbettung und schmale Bildschirme. Es gelten derselbe Textumfang und dieselben Eingabelimits; die Einbettung ist weder eine entfernte Umwandlungs-API noch ein Encoder für Binärdateien. Der Zugriff auf die Zwischenablage hängt von Browserberechtigungen ab, und Ihre Plattform muss die externen Ressourcen zulassen. Der bereitgestellte Rückverweis verwendet nofollow und noopener; seine Anwesenheit garantiert keine besseren Suchmaschinenplatzierungen.

Häufige Fragen

Quellen und weiterführende Informationen

• RFC 4648: Base64, Base64url, Padding und kanonische Kodierung
• RFC 3629: UTF-8-Zeichenkodierung
• WHATWG Encoding: TextEncoder, TextDecoder und BOM-Behandlung
• ECMAScript: Zeichenfolgenlänge und isWellFormed
• WHATWG Infra: tolerante Base64-Dekodierung
• WHATWG HTML: atob und btoa
• W3C File API: Blob als Text lesen
• WHATWG URL: Parsen URL-kodierter Formulardaten
• RFC 2397: das Daten-URL-Schema
• RFC 7515: kompakte Serialisierung von JSON Web Signature
• RFC 7516: kompakte Serialisierung von JSON Web Encryption
• RFC 7617: HTTP-Basic-Authentifizierung