1. Einleitung
Die Basis-Kodierung von Daten wird in vielen Situationen verwendet, um Daten in Umgebungen zu speichern oder zu übertragen, die auf US-ASCII [1]-Daten beschränkt sind, möglicherweise aus historischen Gründen. Die Basis-Kodierung kann auch von neuen Anwendungen ohne historische Beschränkungen verwendet werden, einfach weil sie das Bearbeiten von Objekten mit einem Texteditor ermöglicht.
In der Vergangenheit hatten verschiedene Anwendungen unterschiedliche Anforderungen, sodass die Basis-Kodierung manchmal leicht unterschiedlich implementiert wurde. Heute verwenden Protokollspezifikationen die Basis-Kodierung, insbesondere „base64“, gelegentlich allgemein, ohne genaue Beschreibung oder Referenz. Multipurpose Internet Mail Extensions (MIME) [4] wird oft als Referenz für base64 herangezogen, ohne die Auswirkungen von Zeilenumbrüchen oder zeichenfremden Alphabeten zu berücksichtigen. Der Zweck dieser Spezifikation ist es, ein gemeinsames Alphabet und Kodierungsüberlegungen festzulegen. Dies sollte die Mehrdeutigkeit in anderen Dokumenten verringern und zu besserer Interoperabilität führen.
Warum Basis-Kodierung notwendig ist
Kernproblem
Viele historische Systeme und Protokolle können nur Textdaten (US-ASCII) verarbeiten und keine Binärdaten direkt übertragen:
Problemfälle:
❌ E-Mail-Systeme (SMTP) — nur 7-Bit-ASCII
❌ URL-Parameter — einige Zeichen haben besondere Bedeutung
❌ JSON/XML — Binärdaten nicht direkt einbettbar
❌ Texteditor — kann Binärdateien nicht bearbeiten
Lösung durch Basis-Kodierung
Binärdaten → Basis-Kodierung → Textdaten
(nicht druckbar) (Konvertierung) (druckbar, übertragbar)
Beispiel:
Rohdaten: [0x48, 0x65, 0x6C, 0x6C, 0x6F] (binär)
Base64: "SGVsbG8=" (Text)
Historischer Hintergrund und Interoperabilitätsprobleme
Probleme durch Implementierungsunterschiede
Vor der Standardisierung von Base64 gab es Unterschiede zwischen den Implementierungen:
| Implementierung | Zeilenlängenlimit | Auffüllregel | Alphabet |
|---|---|---|---|
| MIME | 76 Zeichen | Erforderlich | Standard |
| PEM | 64 Zeichen | Erforderlich | Standard |
| Einige URL-Kodierungen | Kein Limit | Optional | URL-sicher |
Diese Unterschiede führten zu:
- ❌ Fehlern beim Datenaustausch zwischen Systemen
- ❌ Dekodierungsfehlern
- ❌ Sicherheitslücken
Wert von RFC 4648
Diese Spezifikation löst diese Probleme durch:
- Einheitliches Alphabet — definiert klar die Standardalphabete Base64, Base32, Base16
- Klare Regeln — legt fest, wie Zeilenumbrüche, Auffüllung, illegale Zeichen behandelt werden
- Varianten bereitstellen — definiert die URL-sichere Base64-Variante
- Interoperabilität — stellt Kompatibilität zwischen verschiedenen Implementierungen sicher
Anwendungsszenarien
Typische Anwendungen von Base64
1. E-Mail-Anhänge (MIME)
Content-Transfer-Encoding: base64
2. Data-URI
data:image/png;base64,iVBORw0KGgo...
3. JWT-Token
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
4. HTTP-Basic-Authentifizierung
Authorization: Basic dXNlcjpwYXNz
5. Einbetten von Binärdaten in XML/JSON
{"avatar": "SGVsbG8gV29ybGQ="}
Warum nicht einfach Binär übertragen?
Gründe:
1. Protokollbeschränkungen — SMTP, HTTP-Header nur ASCII
2. Textsicherheit — vermeidet Probleme durch Steuerzeichen
3. Bearbeitbarkeit — mit Texteditor ansehbar und änderbar
4. Kompatibilität — plattform- und systemübergreifende Übertragung zuverlässiger
Ziele dieser Spezifikation
RFC 4648 verfolgt folgende Ziele:
✅ Mehrdeutigkeit beseitigen — klare, eindeutige Kodierungsdefinition
✅ Interoperabilität verbessern — Kompatibilität zwischen Implementierungen sicherstellen
✅ Auswahl bieten — passende Kodierungsvarianten für verschiedene Szenarien
✅ Sicherheitsüberlegungen — klare, sicherheitsrelevante Implementierungsanforderungen festlegen
Nächste Schritte
Die folgenden Abschnitte behandeln im Detail:
- Abschnitt 2: Konventionen zur Verwendung von RFC-2119-Schlüsselwörtern
- Abschnitt 3: Implementierungsunterschiede und empfohlenes Verhalten
- Abschnitte 4–8: Detaillierte Spezifikationen der einzelnen Basis-Kodierungen
- Abschnitte 9–10: Beispiele und Testvektoren
- Abschnitt 12: Sicherheitsüberlegungen