Encoding vs. Encryption

Base64: Beliebt, um Bilder direkt in HTML einzubetten (Data URI). Oder um API-Keys im HTTP-Header zu senden (Authorization: Basic <base64>). Achtung: Base64 macht Daten ca. 33% größer.

URL-Encoding (Percent Encoding): Du willst ein Leerzeichen in einer URL senden (google.com/search?q=hallo welt). Leerzeichen sind in URLs verboten. Lösung: %20. (hallo%20welt). Emojis werden zu %F0%9F%98%80 (UTF-8 Bytes hexadezimal).

1. Character Encodings (The Nightmare)

ASCII, Latin-1, UTF-8. Wie werden Buchstaben als Bits gespeichert?

• ASCII: 7 Bit. Kann nur Englisch.
• Latin-1: 8 Bit. Kann Deutsch (Ü, Ä).
• UTF-8: Fabelhaft. Variabel lang (1-4 Bytes). Kann alle Sprachen der Welt + Emojis. Ist abwärtskompatibel zu ASCII. Bug: "Mojibake". Wenn du UTF-8 Text als Latin-1 liest, siehst du ü statt ü.

2. Base64 Varianten

Base64 nutzt A-Z, a-z, 0-9, + und /. Problem: + und / sind in URLs Sonderzeichen. Lösung: Base64Url. Ersetzt + durch - und / durch _. Padding = fliegt oft raus. Wichtig für JWTs (Tokens).

3. Hex Encoding

Jedes Byte wird als 2 Hex-Ziffern dargestellt (00 bis FF). Verdoppelt die Größe (1 Byte -> 2 Zeichen). Genutzt für Hashes, MAC-Adressen, Farben (#FFFFFF). Lesbarer als Base64, aber platzfressender.

1. Huffman-Coding (Lossless Compression)

Während Base64 Daten aufbläht, nutzen andere Encodings Mathematik, um Daten zu schrumpfen (ohne Qualitätsverlust). WinZIP oder PNGs nutzen oft Varianten des Huffman-Encodings. Wie? Ein englischer Text besteht oft aus dem Buchstaben 'E' (20%) und selten aus einem 'X' (0.1%). Anstatt jeden Buchstaben stumm in 8 Bit (1 Byte) zu gießen, gibt Huffman dem 'E' den extrem kurzen Bit-Code 10. Das 'X' kriegt dafür den langen Code 01101011. Durch diese variable Längen-Kodierung auf Bit-Ebene spart der Algorithmus massiv Festplattenplatz, generiert aber ein Ergebnis, das auf den ersten Blick wie verschlüsselter Kauderwelsch aussieht.

2. URL-Encoding in Depth (Percent-Encoding)

Der RFC 3986 Standard trennt Buchstaben brutal in Reserved und Unreserved. ?, &, = sind aktiv im HTTP-Routing verankert. Willst du nach dem Text "Max & Moritz" in einer Datenbank-API suchen (/search?q=Max & Moritz), stirbt der Backend-Router. Er denkt, das & ist das Ende des Query-Parameters. Client-APIs rufen daher zuvor encodeURIComponent() auf. Der String wird binär als UTF-8 interpretiert und zu Max%20%26%20Moritz. Die Gefahr: Double Encoding. Wenn die Middleware den String versehentlich zweimal encodiert, wird das % von %20 selbst wieder URL-encodiert zu %25 (Max%2520Moritz). Plötzlich sucht die DB literally nach dem Wort "Max%20" – und du findest nachts keinen Bug.

3. Das Base64-Padding (=)

Man sieht oft Base64 Strings, die mit = oder == enden. Base64 zerkleinert 3 Bytes (24 Bits) des Originals in 4 saubere 6-Bit Base64-Buchstaben. Was, wenn der Original-String aber (wie das Wort "Hi", 2 Bytes) logisch nicht restlos durch 3 teilbar ist? Die Bits ragen ins Leere. Der Base64-Encoder nutzt das Gleichheitszeichen = als Platzhalter (Padding-Anker), um den 4er-Block optisch aufzufüllen ("Hey PC, ignoriere diese leeren End-Bits beim Decoden"). Viele moderne Frameworks (wie JWT Token) werfen das = aus Optimierungs- und Regex-Gründen heimlich weg.