Base64-Varianten: Standard- und URL-sichere Alphabete, Padding-Regeln und Strenge der Decoder

Worum es geht

Variante	Alphabet-Zeichen 62/63	Padding	Zeilenumbruch
Standard-Base64 (RFC 4648 §4)	+ /	erforderlich, sofern die verweisende Spezifikation nichts anderes festlegt — "MUST include appropriate pad characters"	verboten, sofern die verweisende Spezifikation ihn nicht verlangt
URL-sicher / base64url (RFC 4648 §5)	- _	gleiche Regel wie beim Standard, sofern nicht überschrieben; laut RFC kann das Padding entfallen, wenn die Länge bekannt ist	verboten, sofern die verweisende Spezifikation ihn nicht verlangt
JWT / JWS BASE64URL (RFC 7515)	- _	ausdrücklich weggelassen — "with all trailing '=' characters omitted"	nicht zulässig — "without the inclusion of any line breaks"
MIME (RFC 2045)	+ /	erforderlich	erforderlich — höchstens 76 Zeichen pro Zeile; Decoder müssen Zeichen ausserhalb des Alphabets ignorieren

Warum es wichtig ist

RFC 4648 definiert zwei Alphabete, die sich in genau zwei Zeichen unterscheiden, und legt fest, dass Padding erforderlich ist, "unless the specification referring to this document explicitly states otherwise." JWTs sind genau eine solche Abweichung: RFC 7515 lässt abschliessende =-Zeichen komplett weg und verbietet Zeilenumbrüche. Ein JWT-Segment mit =-Padding oder mit Zeilenumbrüchen ist deshalb für einen strengen Decoder eine ungültige Eingabe. MIME verlangt das Gegenteil: Zeilen von höchstens 76 Zeichen. Der Befehl base64 von GNU bricht die Ausgabe standardmässig bei dieser Breite um und benötigt daher ausdrücklich -w0, um eine einzige ununterbrochene Zeile zu erzeugen (-w ist eine Option von GNU coreutils; das base64 von macOS bricht standardmässig nicht um und fordert Zeilenumbrüche mit -b an). Auch bei der Nachsicht der Decoder gibt es Unterschiede: Python-base64.b64decode verwirft Zeichen ausserhalb des Alphabets, bevor das Padding geprüft wird, sofern nicht validate=True übergeben wird. Ein base64url-String verliert dadurch sein - und _ und wird entweder zu falschen Bytes dekodiert oder scheitert am Padding, ohne dass die fehlerhaften Zeichen je genannt werden. Bei unpaddierter Eingabe löst die Funktion Incorrect padding aus — genau das passiert auch bei base64.urlsafe_b64decode mit einem JWT-Segment. Der atob() des Browsers wirft bei -, _ oder jedem anderen Zeichen ausserhalb des Standardalphabets einen InvalidCharacterError, akzeptiert aber fehlendes Padding und ignoriert ASCII-Leerraum. Go-encoding/base64 führt StdEncoding und URLEncoding als getrennte, nicht austauschbare Codecs; RawStdEncoding und RawURLEncoding sind die ausdrücklichen Formen ohne Padding.

So wird es angewendet

• Das Alphabet auf den Kontext abstimmen: URL-, Dateinamen- und JWT-Kontexte brauchen -/_; alle übrigen Fälle verwenden standardmässig +//.
• Padding bewusst entfernen oder ergänzen: JWTs dürfen keines enthalten; die meisten anderen Konsumenten erwarten es, sofern nichts anderes dokumentiert ist.
• base64 -w0 verwenden, wenn die Ausgabe in Skripten eine einzige Zeile sein muss.
• Sich nicht auf die standardmässige Nachsicht von base64.b64decode verlassen; validate=True übergeben, wenn fehlerhafte Eingaben konsequent abgelehnt werden sollen.
• Vor dem Dekodieren eines unpaddierten base64url-Werts in Python '=' * (-len(s) % 4) anhängen; in Go RawURLEncoding verwenden.

Stolpersteine

• Einen paddierten String im +//-Alphabet an einen Decoder übergeben, der base64url erwartet.
• Annehmen, dass jeder Decoder fremde Zeichen wie die Python-Voreinstellung verwirft — atob() wirft stattdessen einen Fehler.
• Annehmen, -w0 sei portabel: Es ist eine Option von GNU coreutils, und das base64 von macOS verwendet stattdessen -b.
• Vergessen, dass -w0 nötig ist, um Zeilenumbrüche in der base64-Ausgabe von Skripten zu vermeiden.