Entwicklertools · Base64-Encoder und -Decoder
Base64 vs. base64url: Warum ein Standarddecoder ablehnt – und _
· Wie es funktioniert
base64 Kodierung Entwickler-Workflow
base64url tauscht + und / gegen - und _ aus, sodass die Ausgabe in URLs und Dateinamen ohne Escapezeichen übertragen werden kann. In diesem Beitrag werden die beiden Alphabete erläutert, wie man zwischen ihnen umwandelt und warum die Auffüllung normalerweise ebenfalls weggelassen wird.
Das Token, das alles außer Ihrem Code dekodiert – ein Fehler aufgrund eines ungültigen Zeichens, der durch ein einzelnes - oder _ verursacht wird
Ein JWT-Segment kann im Standard-Base64-Decoder nicht dekodiert werden, da ein ungültiger Zeichenfehler beim Benennungsstrich vorliegt. Aber optisch erscheint kein Strich. Schauen Sie noch einmal hin – das tut es. Die base64url-Version verwendet -, wobei Standard-Base64 + verwendet, und _, wo /. verwendet wird. Viele Decoder akzeptieren nur ein Alphabet, und zur URL-Sicherheit codierte Token werden von Code abgelehnt, der den RFC-4648-Standard-Base64 erwartet.
Die beiden Alphabete sind gleichwertig; Die Konvertierung zwischen ihnen ist eine mechanische Zeichenersetzung. Das Problem entsteht, weil + und / in URLs Bedeutungen haben. Ein Pluszeichen steht für Leerzeichen in den Formulardaten application/x-www-form-urlencoded. Der Schrägstrich ist ein Pfadtrennzeichen in der URL. Wenn Sie Base64 direkt in URL-Abfrageparameter einbetten, ohne dass die Prozentcodierung + und der Decoder /, diese falsch interpretieren.
Warum + und / in URLs und Dateinamen ein Problem darstellen – die reservierte Bedeutung von / in Pfaden und von + als Leerzeichen in Formulardaten
A + könnte als Leerzeichen gelesen werden, bevor es den Decoder erreicht. Ein / könnte den Parameterwert an der falschen Stelle teilen. Der RFC-Abschnitt 4648 5 definiert das Base64-URL-Alphabet, um Mehrdeutigkeiten zu vermeiden: Verwenden Sie - anstelle von + und _ anstelle von /,, damit die Ausgabe in URLs und Dateinamen sicher ist. Die beiden Alphabete sind bis auf zwei Zeichen identisch.
Standard Base64 verwendet Zeichen an den Positionen 62 und 63: A–Z (0–25), a–z (26–51), 0–9 (52–61), + (62), / (63). base64url verwendet A–Z (0–25), a–z (26–51), 0–9 (52–61), - (62), _ (63). Alles andere – Bit-Neugruppierung, Auffüllregeln, Zuordnung von Bits zu Indizes – ist gleich. Eine Indexfolge für Standard-Base64 erzeugt eine Indexfolge für base64url; Nur die Zeichen an den Positionen 62 und 63 unterscheiden sich.
Das base64url-Alphabet aus RFC 4648 Abschnitt 5 – die beiden ersetzten Zeichen und warum sich sonst nichts ändert
Wenn die Eingabe keine Indizes 62 oder 63 enthält (kein + oder / im Standard, kein - oder _ in base64url), erzeugen beide Alphabete eine identische Ausgabe. Das Konvertieren von Standard-Base64 in base64url ist ein einfaches Suchen und Ersetzen: Tauschen Sie + gegen - und / gegen _ aus. Die Decodierung der Base64URL-Zeichenfolge im Standard-Base64 erfordert die Umkehrung: Tauschen Sie - für + und _ für /.
Die Konvertierung ist symmetrisch und immer gültig. Wenn Sie auf ein Token stoßen, dessen Decodierung aufgrund eines Fehlers bei der Benennung ungültiger Zeichen (oder _) fehlschlägt, prüfen Sie, ob der Decoder base64url akzeptiert. Wenn nicht, wenden Sie die Zeichenersetzung an. Wenn die Eingabe ansonsten wohlgeformt ist, sollte die Dekodierung erfolgreich sein. Betrachten Sie den JWT-Header {"alg": "HS256", "typ": "JWT"}, der als Base64-URL codiert ist. Standardmäßige UTF-8-Bytes durchlaufen eine Bit-Neugruppierung: Drei Bytes werden zu vier Indizes, die im Base64-URL-Alphabet nachgeschlagen werden. ToolAcre macht das Auffüllen als Encoder-Auswahl verfügbar, anstatt es an den Alphabet-Umschalter zu binden. Diese Trennung ist ein nützlicher Beweis: URL-sichere Ausgaben können aufgefüllt oder nicht aufgefüllt werden, während der Decoder beide Formen normalisiert, bevor er das Browser-Primitiv aufruft. Alphabet und Auffüllung sind verwandte Konventionen, kein einzelner Schalter.
Das Auffüllen in base64url ist per Konvention optional – warum JWTs = weglassen und wie ein Decoder es aus der Länge wiederherstellen kann
Wenn der Index 62 ist, ist das Ausgabezeichen -; Bei 63 ist die Ausgabe _. Identische Bytes im Standardalphabet würden + am Index 62 und / am Index 63 ergeben. Das Konvertieren des base64url-Ergebnisses in den Standard erfolgt zeichenweise: Suchen Sie nach - und ersetzen Sie es durch +, suchen Sie nach _ und ersetzen Sie es durch /,, und dekodieren Sie es dann wie gewohnt.
Die von Ihnen wiederhergestellten Bytes sind identisch, da die Indizes identisch waren. nur die Symbole unterscheiden sich. Das Auffüllen in base64url ist per Konvention optional, auch wenn der Standard dies zulässt. JWTs sind als drei durch Punkte verbundene base64url-Segmente strukturiert; Jedes Segment verwendet bei Bedarf eine Auffüllung, aber viele Implementierungen verzichten darauf und verlassen sich darauf, dass die konsumierende Anwendung die erwartete Bytelänge kennt.
Arbeitsbeispiel: Konvertieren eines JWT-Headersegments in Standard-Base64 – Ersetzen von Zeichen, Hinzufügen von Auffüllungen, Dekodierung in JSON
Ein Decoder kann fehlende Auffüllung wiederherstellen, indem er die Zeichenfolgenlänge durch vier dividiert, den Rest berechnet und 0, 1 oder 2 Gleichheitszeichen anhängt. Wenn die Zeichenfolgenlänge kein Vielfaches von vier ist, ist die fehlende Auffüllung offensichtlich. Wenn die Länge ein Vielfaches von vier ist, wurde die Zeichenfolge entweder aufgefüllt und dann aufgefüllt, oder sie hat bereits ein Vielfaches von vier Bytes eingegeben (und endet mit drei Bytes im letzten Block, sodass kein Auffüllen erforderlich ist).
Bei der Verkettung von Base64URL-Segmenten muss auf die Auffüllung geachtet werden. Wenn drei Segmente jeweils mit = enden, erzeugt die Verkettung direkt Zeichenfolgen wie AAAA=BBBB=CCCC=, wobei der Abstand in der Mitte jetzt aus Streuzeichen und nicht aus Abschlussmarkierungen besteht. Aus diesem Grund verzichten JWTs auf das Auffüllen in jedem Segment: Die Drei-Segment-Struktur ist explizit, sodass die Dekodierung für jeden Teil unabhängig erfolgt und das Auffüllen in der Mitte der verketteten Zeichenfolge unnötig ist und die Analyse unterbrechen würde.
Häufige Fehler – Alphabete in einer Zeichenfolge mischen oder Standard-Base64 mit Prozentkodierung anstelle von base64url verwenden
Wenn Sie eine Nutzlast mit mehreren Segmenten erstellen, entscheiden Sie sich zu Beginn für eine Auffüllkonvention: Entweder in jedes Segment einschließen und niemals direkt verketten, oder weglassen und die Länge nur beim Dekodieren wiederherstellen. Der RFC-Standard 4648 ist für beide Alphabete maßgeblich. Abschnitt 4 spezifiziert Standard Base64; Abschnitt 5 gibt base64url an. Jeder konforme Decoder sollte klar angeben, welches Alphabet er akzeptiert.
Code, der base64url akzeptiert, aber nicht Standard-Base64 (oder umgekehrt), implementiert nur eine Teilmenge. Das base64url-Alphabet dient der Kompatibilität mit URL- und Dateinamenbeschränkungen. Es handelt sich nicht um eine Verbesserung oder einen Ersatz, sondern nur um eine Variante für einen bestimmten Kontext. Wenn Sie eine API oder ein Token-Format erstellen, wählen Sie ein Alphabet aus und dokumentieren Sie, welches. Ein häufiger Fehler ist die prozentuale Codierung des Standard-Base64 anstelle der Verwendung von base64url. Die Implementierung erklärt auch die Artikelgrenze. Es normalisiert Bindestriche und Unterstriche vor der Dekodierung, überprüft jedoch keine Tokensignatur und interpretiert keine Ansprüche. Das Konvertieren eines JWT-Segments in Bytes kann JSON offenbaren; Es kann nicht festgestellt werden, wer diesen JSON herausgegeben hat oder ob ihn jemand geändert hat.
Was dies nicht abdeckt – die Überprüfung von JWT-Signaturen, Base32 und den anderen RFC-4648-Codierungen
%2B ist Prozentcode für +; %2F ist Prozentcode für /.. Prozentkodierung wandelt TWFu unverändert in TWFu um (keine Sonderzeichen), TE9S+g== jedoch in TE9S%2Bg%3D%3D (zu viele Zeichen zum Verarbeiten). Die richtige Lösung ist die Verwendung von base64url, das bereits eine URL-sichere Ausgabe erzeugt. Die prozentuale Kodierung mit Base64 ist überflüssig und verschwenderisch. Verwenden Sie für den Kontext das richtige Alphabet. Der Base64-Encoder und -Decoder akzeptiert beide Alphabete automatisch.
Wenn Sie eine Zeichenfolge einfügen, die „-“ enthält, wird sie als „base64url“ behandelt. Wenn eine Zeichenfolge eingefügt wird, die + enthält, wird sie als Standard-Base64 behandelt. Das Tool akzeptiert auch URLs und behandelt sie als URL-sichere Eingabe. Eine praktische Prüfung hat daher zwei unabhängige Ergebnisse: den Byte-Roundtrip und die gewählte Darstellung passt zu ihrem Kanal. Das Bestehen des ersten besagt, dass die Transformation reversibel ist. Die Übergabe der zweiten besagt, dass Satzzeichen und Auffüllungen nicht durch die URL, den Dateinamen, das Cookie oder das Protokoll, das sie trägt, neu geschrieben werden.
Fazit: Zwei Alphabete, ein Bit-Layout – wie der Base64-Encoder und -Decoder das Standardalphabet im Browser verarbeitet und wo auf seiner Toolseite angegeben ist, was er akzeptiert
Beim Dekodieren des JWT-Segments oder URL-sicheren Tokens können Sie es direkt ohne Konvertierung einfügen, und das Tool identifiziert das Alphabet anhand des Kontexts. Das Debuggen einer fehlgeschlagenen Dekodierung wird ganz einfach: Fügen Sie das Token ein, prüfen Sie, ob das Tool es akzeptiert, und wenn nicht, tauschen Sie die Zeichen manuell aus und versuchen Sie es erneut.
Die Ersetzung selbst ist eine Codezeile, aber eine fehlgeschlagene Dekodierung kann auch auf eine unmögliche Länge, falsch platzierte Auffüllungen, Beschädigungen oder Nicht-Base64-Eingaben zurückzuführen sein. Das Tool normalisiert beide Alphabete automatisch, sodass die Akzeptanz nur bestätigt, dass Bytes wiederhergestellt werden können. Eine dekodierte JWT-Nutzlast ist immer noch ein unsignierter Anspruch, bis ein separater Verifizierer seine Signatur und den erwarteten Algorithmus überprüft.