Encoding-Basics: Base64, URL, Hex

Worum geht’s

In Logs, Konfigurationen, E-Mail-Headern und API-Aufrufen stößt du ständig auf scheinbar „kryptische” Zeichenketten: aGFsbG8=, %20, 48656c6c6f. Das ist keine Verschlüsselung, sondern Kodierung — eine umkehrbare Umschreibung. Wer das erkennt und auflösen kann, liest Header, debuggt URLs und versteht JWTs. Dieser Skill räumt mit dem häufigsten Missverständnis auf: Kodierung schützt nichts.

Konzept

Kodierung wandelt Daten in eine andere Darstellung um, damit sie über einen bestimmten Kanal transportierbar sind — ohne Schlüssel, jederzeit umkehrbar. Drei verbreitete Verfahren:

• Base64: stellt Binärdaten als 64 druckbare ASCII-Zeichen dar (A–Z a–z 0–9 + /). Drei Bytes (24 Bit) werden zu vier Zeichen (je 6 Bit). = am Ende ist Padding. Nutzen: Binärdaten in Text-Kontexten (E-Mail-Anhänge, JSON, Zertifikate als PEM).
• Base64url: Variante für URLs/JWT — ersetzt +// durch -/_ und lässt Padding oft weg.
• URL-Encoding (Percent-Encoding): ersetzt in URLs unsichere Zeichen durch % plus Hex-Code, z. B. Leerzeichen → %20, & → %26.
• Hex (Base16): stellt jedes Byte als zwei Hex-Ziffern dar (H → 48). Üblich für Hashes, MAC-Adressen, Byte-Dumps.

Der Kernsatz, den du nie vergessen darfst: Kodierung ≠ Verschlüsselung. Base64 lässt sich ohne jedes Geheimnis zurückwandeln. Was Base64-kodiert in einer Config steht, ist nicht geschützt — es ist nur „unleserlich auf den ersten Blick”.

So entstehen aus drei Bytes vier Base64-Zeichen:

Beispiel-Fall

Aufgabe: In einer Konfigurationsdatei steht password: cGFzc3dvcnQxMjM=. Ist das sicher?

1. Die Endung = und der Zeichenvorrat deuten auf Base64.
2. Dekodieren ergibt passwort123 — Klartext.
3. Schluss: Das Passwort ist nicht verschlüsselt, nur kodiert. Jeder mit Lesezugriff auf die Datei kennt es.
4. Konsequenz: Solche Werte gehören in ein Secret-Management oder verschlüsselt abgelegt, nicht „base64-versteckt”.

Anwenden

Selbsttest

Praxis-Challenge