Entwicklertools · Base64-Encoder und -Decoder
Base64-Padding erklärt: Was die =-Zeichen bedeuten und wann sie erforderlich sind
· Wie es funktioniert
base64 Kodierung Entwickler-Workflow
Das = am Ende einer Base64-Zeichenfolge ist keine Dekoration: Es zeichnet auf, wie viele Bytes die letzte Gruppe zu kurz war. In diesem Beitrag wird die Arithmetik erklärt, warum einige Zeichenfolgen keine haben und warum Decoder sich über fehlende Auffüllung nicht einig sind.
Die Ausnahme „falsches Auffüllen“ von einem Token, das gut aussah – eine fehlgeschlagene Dekodierung und die ein oder zwei fehlenden Zeichen dahinter
Wenn ein Base64-Decoder eine falsche Auffüllung meldet, sieht die Zeichenfolge vollständig aus, weist jedoch einen Strukturfehler auf. Die Gleichheitszeichen sind nicht kosmetischer Natur: Jedes kodiert, um wie viele Bytes die letzte Gruppe gekürzt wurde, sodass der Decoder genau wissen kann, wann die echten Daten endeten. Das Verständnis dieser =-Zeichen – und warum strenge Decoder Zeichenfolgen ohne sie ablehnen – verwandelt einen mysteriösen Fehler in vorhersehbare Arithmetik. Ein JWT-Segment kann ein =, keins oder zwei haben. Eine API-Antwort könnte ohne Auffüllen sauber enden.
Hierbei handelt es sich um absichtliche Entscheidungen, nicht um Implementierungsvarianten. Der Dekodierungsprozess erfordert kein mechanisches Auffüllen. Es gibt Auffüllungen, um die Ausgabe eindeutig zu machen: Wenn nur eine Base64-Zeichenfolge ohne Metadaten zur Länge vorhanden ist, liest der Decoder Auffüllungen und weiß genau, wo die Daten endeten. Base64 kodiert Gruppen von drei Bytes in vier Zeichen. Drei Bytes sind 24-Bits, die sich perfekt in vier 6-Bit-Indizes zusammenfassen lassen; Jeder wählt eines von 64 Base64-Symbolen aus. Wenn die Eingabe kein Vielfaches von drei ist, sieht sich der Encoder mit Resten konfrontiert: Ein oder zwei Bytes können nicht gleichmäßig durch drei geteilt werden.
Gruppen von drei Bytes, Blöcke von vier Zeichen – warum die Eingabelänge modulo 3 entscheidet, ob null, eins oder zwei =-Zeichen erscheinen
Der Encoder füllt diese Gruppen auf, indem er Bits in die ersten Indizes verschiebt, sodass die Endwerte Null bleiben. Um diese Absicht zu kennzeichnen, werden =-Zeichen angehängt: Null für vollständige Gruppen, eins für Zwei-Byte-Enden, zwei für Ein-Byte-Enden. Die Arithmetik ist deterministisch: Wenn Sie die Eingabelänge in Bytes kennen, können Sie die Auffüllung sofort berechnen. Ein Byte erzeugt zwei Base64-Zeichen plus zwei =. Zwei Bytes ergeben drei Zeichen plus ein =. Drei Bytes ergeben vier ohne Auffüllung.
Jede Eingabe, die kein Vielfaches von drei Bytes ist, wird aufgefüllt; Alle, die ein Vielfaches sind, werden dies nicht tun. Das ist keine Wahl – es ist Arithmetik. Eine Zeichenfolge ohne Auffüllung muss drei Bytes darstellen. Eine Zeichenfolge, bei der eins gleich ist, muss zwei darstellen. Padding kodiert die Eingabelänge modulo drei. Untersuchen Sie die Transformation von drei Eingaben: einzelnes a, Paar ab, dreifaches abc. ASCII a ist Byte 0x61; Base64 kodiert es als 0x61 00 00 und gruppiert es in Sechs-Bit-Gruppen neu.
Was die Füllbits enthalten und warum ein strikter Decoder sie überprüft – die Bits, die Null sein müssen und was kanonische Kodierung bedeutet
Die Indizes 24, 4, 0, 0 werden Y, E, A, A zugeordnet. Da zwei Gruppen aufgefüllt wurden, hängt der Encoder zwei =-Zeichen an und erzeugt YQ==. Für ab werden die Bytes 0x61 0x62 zu 0x61 0x62 00. Bits gruppieren sich zu den Indizes 24, 22, 8, 0, Ausgang YWI=. Für abc werden die Bytes zu den Indizes 24, 22, 9, 35 neu gruppiert und YWJj ohne Auffüllung ausgegeben. Das Auffüllen ist nicht willkürlich: Es fällt aus dem Bit-Layout. Wenn Sie eine Base64-Zeichenfolge dekodieren, liest der Decoder jedes Zeichen, sucht nach seinem Sechs-Bit-Index und packt Bits in Bytes.
Für YQ== werden die Zeichen Y, E, A, A in Bits entpackt. Die Neugruppierung in Acht-Bit-Bytes ergibt ein Byte, 0x61. Der Decoder verwirft Füllbits (nachgestellte Nullen) und meldet ein Byte. Ein strikter Decoder prüft, ob die Füllbits tatsächlich Null sind; Wenn nicht, war die Eingabe nicht kanonisch, was bedeutet, dass jemand, der mit einem anderen Bit-Layout kodiert und dekodiert, mehrdeutig ist. Bei Systemen, bei denen auf Polsterung gänzlich verzichtet wird, werden bewusste Kompromisse eingegangen. JWT-Segmente verwenden Base64url ohne Auffüllung und verlassen sich darauf, dass Verbraucher die erwartete Ausgabelänge kennen oder daraus ableiten.
Arbeitsbeispiel: Kodierung von „a“, „ab“ und „abc“ von Hand – drei Eingaben, drei Füllergebnisse, Stück für Stück angezeigt
RFC 4648 lässt das Fehlen von Auffüllungen zu, weist Decoder jedoch an, diese zu akzeptieren, falls vorhanden. Codebibliotheken unterscheiden sich: Einige stellen fehlende Auffüllungen wieder her und fahren fort; andere werden scheitern. Wenn Sie auf Token stoßen, deren Decodierung fehlschlägt, lässt sich das Problem häufig durch Anhängen der richtigen Anzahl von =-Zeichen beheben. Erforderlich = Vorzeichen sind immer Null, Eins oder Zwei, abhängig von der Stringlänge Modulo Vier. Wenn die Länge einer Base64-Zeichenfolge kein Vielfaches von vier ist, fehlt definitiv die Auffüllung oder ist beschädigt.
Eine Länge von 5 kann nicht gültig sein. Base64: Jedes vollständige Zeichen kodiert sechs Bits, also kodieren vier Zeichen 24 Bits (drei Bytes) und fünf kodieren 30 Bits, was kein Vielfaches von acht ist und nicht zu Bytes werden kann. Der Decoder muss dies entweder ablehnen oder eine Auffüllung hinzufügen. Wenn die Länge 2 modulo 4 ist, fügen Sie zwei = hinzu. Wenn 3 modulo 4 ist, fügen Sie ein = hinzu. Wenn 0 modulo 4 ist, fügen Sie keine hinzu. Einem String der Länge 3 fehlt das =, das er benötigt; Fügen Sie eins hinzu und es wird vor der Dekodierung gültig.
Warum einige Systeme die Auffüllung vollständig weglassen – JWT Segmente und URL-sichere Token, die = weglassen, und wie man es aus der Länge wiederherstellt
Die Verkettung zweier aufgefüllter Base64-Strings ist fehlerhaft, wenn die Auffüllung an Ort und Stelle bleibt. Zwei direkt verbundene separate Kodierungen erzeugen vereinzelte Füllzeichen, die das Dekodierungsalphabet unterbrechen. Aus diesem Grund entfernen einige Systeme die Auffüllung vor der Verkettung: Ein Token, das aus drei durch Punkte verbundenen Base64url-Segmenten besteht, hat keine Auffüllung innerhalb der Segmente, was die Verkettung einfacher macht. Wenn Sie einen Base64-Wert aus Teilen erstellen, überprüfen Sie, ob jedes Teil gepolstert ist, und entfernen oder fügen Sie vor allen Vorgängen konsistent Polsterung hinzu.
Der Base64-Encoder und -Decoder wendet RFC 4648 an, das standardmäßig eine Auffüllung erfordert. Wenn Sie Text eingeben und eine Base64-Ausgabe anfordern, erzeugt das Tool ein aufgefülltes Ergebnis: die kanonische Form. Wenn Sie Base64 ohne Auffüllung sehen und es dekodieren möchten, prüfen Sie, ob Ihr Decoder fehlende Auffüllungen akzeptiert. Das Tool akzeptiert sowohl aufgefüllte als auch nicht aufgefüllte Eingaben und stellt die ursprünglichen Bytes korrekt wieder her. Beim Debuggen erfahren Sie durch Zählen der Länge Modulo 4, ob die Auffüllung entfernt wurde, und die Formel gibt an, welche Auffüllung vorhanden sein sollte.
Häufige Fehler: Trimmen von =, als wäre es ein Leerzeichen, oder Verketten zweier aufgefüllter Zeichenfolgen – wie jede die Dekodierung verfälscht
Für Base32 und Base16 (hexadezimal) sind unterschiedliche Füllregeln in den RFC-Abschnitten 4648 6 und 7 definiert. Base32 verwendet =, aber die letzte Gruppe kann je nach Eingabelänge Modulo 5 aus 2, 4, 5, 7 oder 8 Zeichen bestehen. Hexadezimal erfordert keine Auffüllung; Es ordnet immer ein Byte zwei Zeichen ohne Rest zu. MIME Base64-Wrapping berührt Padding: Eine mit 76-Spalten umschlossene Zeichenfolge hat immer noch Padding ganz am Ende, nur einige Zeilen später.
Um das Padding für Base64 zu verstehen, geht es darum, das Bit-Layout und die Eingabelänge Modulo Drei zu verstehen. Sobald Sie mit dem Rechnen vertraut sind, wird das Auffüllen zu einer direkten Konsequenz und nicht zu einer Regel, die Sie sich merken müssen. Polsterung ist ableitbar, nicht magisch.
Was dies nicht abdeckt – Base32- und Base16-Auffüllregeln und MIME-Konventionen für die Zeilenlänge
Bei einer Base64-Zeichenfolge beliebiger Länge können Sie die kanonische aufgefüllte Form wiederherstellen, indem Sie die Zeichenanzahl durch vier dividieren, den Rest bilden und die entsprechende Anzahl von =-Zeichen anhängen. Aus diesem Grund ist „missing =“ korrigierbar und strikte Decoder können nachsichtig sein: Auffüllen enthält Informationen (in welchen Zweig von drei Fällen Ihre Eingabe fiel), aber diese Informationen können allein aus der Länge berechnet werden.
Der Base64-Encoder und -Decoder zeigt sofort die aufgefüllte Ausgabe an, sodass Sie decodierte Bytes mit dem Originaltext vergleichen und überprüfen können, ob der Roundtrip funktioniert hat. Base64 und verwandte Kodierungen erweitern das Prinzip der Umgruppierung von Bits in verschiedene Zeichenbreiten. RFC 4648 spezifiziert alle drei, und das Verständnis eines davon macht andere konzeptionell einfacher. Die wichtigste Erkenntnis ist, dass es sich bei der Codierung um reine Bitmanipulation handelt: Wählen Sie die Größe Ihres Alphabets, gruppieren Sie Ihre Bits entsprechend und schlagen Sie jede Gruppe in einer Tabelle nach.
Fazit: Auffüllen ist ableitbar, daher ist ein fehlendes = korrigierbar – wie der Base64-Encoder und -Decoder Ihnen die aufgefüllte kanonische Form jedes von Ihnen codierten Textes anzeigt
Die Dekodierung erfolgt umgekehrt: jedes Zeichen nachschlagen, Bits extrahieren, sie neu gruppieren, Bytes schreiben. Diese deterministische Zwei-Wege-Zuordnung ist der Grund, warum Base64 auf allen Plattformen und Sprachen zuverlässig funktioniert. Fehler bei der Codierung und Decodierung sind häufig auf Missverständnisse beim Auffüllen oder bei Alphabetunterschieden zurückzuführen. Wenn die Dekodierung aufgrund von Auffüllfehlern fehlschlägt, prüfen Sie, ob der Decoder kanonisches Base64 (streng aufgefüllt) erwartet oder Varianten akzeptiert. Wenn es mit Zeichenfehlern fehlschlägt, prüfen Sie, ob die Eingabe eine Base64-URL ist und der Decoder Standard-Base64 erwartet.
Der Base64-Encoder und -Decoder akzeptiert beide Alphabete und validiert die Auffüllung konsistent, sodass jedes handberechnete Beispiel sofort überprüft werden kann. Das Testen der Kodierung durch Rückdekodierung ist der sicherste Weg, Fehler zu erkennen, bevor sie Produktionsprobleme verursachen.