# Coder — Manual > Vollständige Funktionsbeschreibung des Coder: alle sieben Encode-/Decode-Reiter, was sie genau tun, Eingabe und Ausgabe, Sonderfälle und die Grenzen. Source: https://www.jpkc.com/db/tools/coder/manual/ Zurück zur Übersicht: [Coder](https://www.jpkc.com/db/tools/coder/) · Tool live öffnen: [www.jpkc.com/tools/coder/](https://www.jpkc.com/tools/coder/) Dieses Manual beschreibt jeden der sieben Reiter des **Coder** im Detail: was er tut, was rein- und rauskommt, welche Sonderfälle es gibt und wo die Grenzen liegen. Die Oberfläche ist auf Englisch — die Reiter- und Button-Namen werden hier deshalb in ihrer englischen Original-Schreibweise genannt (mit deutscher Erläuterung), damit du dich im echten Interface zurechtfindest. ## Oberflaeche und Bedienung Das Tool ist eine einzige Karte mit einer Reiter-Leiste oben: **HTML**, **HTML+**, **URL**, **Base64**, **JSON**, **JWT** und **Data URI**. Jeder Reiter hat ein eigenes Eingabefeld und seine eigenen Buttons. - Die Reiter **HTML** und **HTML+** nutzen einen **CodeMirror**-Editor mit Zeilennummern, Zeilenumbruch und Syntax-Highlighting (Modus `htmlmixed`) — angenehm für längere Markup-Schnipsel. - Die Reiter **URL**, **Base64** und **JSON** haben ein einfaches Textfeld mit einer **Eingabe-History** (die zuletzt verarbeiteten Eingaben werden lokal vorgehalten und lassen sich erneut auswählen). - Fast jeder Reiter hat einen **Encode**- und einen **Decode**-Button (beim JSON-Reiter heißen sie **Escape** und **Unescape**), dazu einen **Copy**-Button, der das aktuelle Feld in die Zwischenablage legt. - Das Ergebnis wird **in dasselbe Feld** zurückgeschrieben — Encode und Decode arbeiten also auf demselben Textbereich. Wer das Original behalten will, kopiert es vorher heraus. - Rückmeldungen (Erfolg, leere Eingabe, ungültiger Input) erscheinen als kurze Toast-Benachrichtigungen. ## Architektur: alles clientseitig Wichtig für Verständnis und Datenschutz: Der Server liefert nur die HTML-Seite und die Editor-Bibliothek aus. Das **Encoden und Decoden passiert vollständig in deinem Browser** per JavaScript. Es gibt keine serverseitige Verarbeitung, keinen API-Call und keinen Upload deiner Eingaben — auch nicht beim JWT-Reiter oder bei der Data-URI-Erzeugung. Deine Tokens, Dateien und Strings bleiben lokal. ## HTML — einfache Entities Der Reiter **HTML** wandelt die drei strukturkritischen Zeichen in HTML-Entities um: - **Encode:** `&` → `&`, `<` → `<`, `>` → `>` (in dieser Reihenfolge, damit das `&` der erzeugten Entities nicht erneut kodiert wird). - **Decode:** macht genau diese drei Entities wieder rückgängig. Das ist das Minimum, um einen Code-Schnipsel als **Text** anzuzeigen, ohne dass der Browser ihn als Markup interpretiert. Sonderfall/Grenze: Der Decode-Schritt erkennt **nur** die Entities, die der Encode-Schritt erzeugt (`&`, `<`, `>`). Beliebige andere Entities — etwa `©`, ` ` oder numerische wie `€` — werden hier **nicht** zurückübersetzt; dafür ist der Reiter HTML+ bzw. eine andere Methode nötig. ## HTML+ — erweiterte Entities Der Reiter **HTML+** macht dasselbe wie HTML, deckt aber zusätzlich die beiden Zeichen ab, die in **Attributwerten** stören: - **Encode:** `&` → `&`, `<` → `<`, `>` → `>`, `"` → `"`, `'` → `'`. - **Decode:** macht diese fünf Entities wieder rückgängig. Faustregel: Steht dein Text zwischen Tags, reicht **HTML**. Landet er in einem Attribut (`title="…"`, `alt="…"`), nimm **HTML+**, damit Anführungszeichen das Attribut nicht zerbrechen. Auch hier gilt: Decode erkennt nur diese fünf Entities, keine sonstigen. ## URL — URL-Encoding Der Reiter **URL** kodiert einen String für die sichere Verwendung in URLs und dekodiert ihn wieder. - **Encode:** baut auf `encodeURIComponent` auf und kodiert zusätzlich die Zeichen `~ ! ( ) '` als Prozent-Sequenzen (`%7E %21 %28 %29 %27`). **Leerzeichen werden zu `+`** — also im Stil von `application/x-www-form-urlencoded` (Formular-/Query-Encoding), nicht als `%20`. - **Decode:** wandelt zuerst `+` zurück in ein Leerzeichen und ruft dann `decodeURIComponent` auf. Sonderfall/Grenze: Das `+`-für-Leerzeichen-Verhalten ist bewusst formular-orientiert. Wenn du einen String für einen **Pfad-Bestandteil** brauchst, in dem ein `+` wörtlich gemeint ist, beachte diesen Unterschied. Ungültige Prozent-Sequenzen beim Decode (z. B. ein einzelnes `%`) führen zu einer Fehlermeldung statt zu einer kaputten Ausgabe. ## Base64 — Text Der Reiter **Base64** kodiert Text nach Base64 und dekodiert Base64 zurück zu Text. - **Encode:** wandelt den Text **UTF-8-sicher** um (via `TextEncoder` + `btoa`), sodass auch Umlaute, Akzente und Emojis korrekt durchlaufen. - **Decode:** kehrt das um (via `atob` + `TextDecoder`). Ist die Eingabe **kein** gültiges Base64, gibt das Tool eine Fehlermeldung aus, statt eine fehlerhafte Zeichenfolge zu produzieren. Sonderfall/Grenze: Dieser Reiter erwartet **Standard-Base64** (Alphabet `A–Z a–z 0–9 + /` mit `=`-Padding). Die abweichende **Base64URL**-Variante (`-` und `_` statt `+` und `/`), wie sie in JWTs vorkommt, gehört nicht hierher — dafür ist der JWT-Reiter zuständig, der intern korrekt Base64URL dekodiert. ## JSON — String escapen und unescapen Der Reiter **JSON** behandelt **JSON-String-Literale**, nicht ganze JSON-Dokumente. - **Escape:** wandelt Sonderzeichen in ihre JSON-Escape-Sequenzen: `\` → `\\`, `"` → `\"`, Zeilenumbruch → `\n`, Wagenrücklauf → `\r`, Tabulator → `\t`. - **Unescape:** macht genau diese Sequenzen wieder rückgängig. Typischer Einsatz: Du willst einen mehrzeiligen Text als String-Wert in eine JSON- oder Code-Datei einsetzen. Sonderfall/Grenze: Der Reiter deckt das **gängige Set** ab (`\\ \" \n \r \t`). Unicode-Escapes der Form `\uXXXX` sowie `\b` und `\f` werden **nicht** behandelt. Für das Formatieren, Validieren oder Umstrukturieren ganzer JSON-Dokumente nutze den [JSON Editor](https://www.jpkc.com/db/tools/json/). ## JWT — dekodieren und anzeigen Der Reiter **JWT** zerlegt ein JSON Web Token und zeigt seinen Inhalt. Du fügst das Token ein und klickst **Decode**. Ablauf: 1. Das Token wird an den Punkten in **drei Teile** zerlegt. Hat es nicht genau drei Teile, kommt die Meldung „Invalid JWT format". 2. **Header** und **Payload** werden **Base64URL-dekodiert** und als JSON geparst, dann **eingerückt formatiert** angezeigt (eigene Karte für Header, eigene für Payload, jeweils mit eigenem Copy-Button). 3. Die **Signatur** wird als **roher String** angezeigt — unverändert, so wie sie im Token steht. 4. Enthält die Payload ein `exp`-Feld (Ablaufzeitpunkt), zeigt das Tool ein Badge an: **abgelaufen** (mit „vor …") oder **gültig** (mit „läuft … ab"), als menschenlesbare Relativzeit. Ein `iat`-Feld (ausgestellt) ergibt zusätzlich ein „Issued …"-Badge. **Entscheidend — was das Tool NICHT tut:** Es **verifiziert die Signatur nicht** und prüft auch nicht, ob das Token echt oder manipuliert ist. Es **erzeugt** ebenfalls keine Tokens und nimmt **kein Secret und keinen Schlüssel** entgegen. Der Coder ist ein reiner **Decoder/Inspektor**: Er zeigt dir, was *behauptet* wird, nicht, ob es *stimmt*. Die Ablauf-Badges beruhen allein auf den Feldern `exp`/`iat` in der (unverifizierten) Payload. Mehr dazu in den [Tipps](https://www.jpkc.com/db/tools/coder/tips/). Sonderfall/Grenze: Lässt sich ein Teil nicht Base64URL-dekodieren oder ist der dekodierte Inhalt kein gültiges JSON, meldet das Tool „Failed to decode JWT". ## Data URI — Datei zu Data-URI Der Reiter **Data URI** wandelt eine beliebige Datei in eine Base64-kodierte `data:`-URI um, die du direkt in CSS (`background-image`) oder HTML (`src`) einbetten kannst. Ablauf: 1. Über **Select a file** wählst du eine Datei aus. 2. Der Browser liest sie lokal ein (`FileReader.readAsDataURL`); eine **Fortschrittsanzeige** zeigt den Lese-Status. 3. Im Ausgabefeld steht anschließend die fertige Data-URI der Form `data:;base64,<…>`. Das Feld ist **schreibgeschützt**; der **Copy**-Button legt die URI in die Zwischenablage. 4. Unter dem Feld werden **Datei-Infos** angezeigt: Name, MIME-Typ, Größe und Änderungsdatum. Sonderfall/Grenze: - Der **MIME-Typ** stammt aus der Browser-Erkennung (`file.type`). Liefert der Browser keinen Typ, steht dort `n/a` — die Data-URI kann dann einen leeren oder generischen Typ tragen. - Die Konvertierung läuft **vollständig clientseitig**; die Datei wird **nicht** hochgeladen. - Base64 vergrößert die Daten um rund ein Drittel. Für große Dateien (Videos, große Bilder) werden Data-URIs entsprechend lang und sind für die Einbettung oft unpraktisch — Data-URIs lohnen vor allem für kleine Assets wie Icons. ## Grenzen — kompakt - **HTML/HTML+ Decode** erkennt nur die selbst erzeugten Entities, keine beliebigen oder numerischen. - **URL Encode** nutzt `+` für Leerzeichen (Formular-Stil), nicht `%20`. - **Base64** erwartet das Standard-Alphabet; Base64URL ist dem JWT-Reiter vorbehalten. - **JSON** escapt nur `\\ \" \n \r \t` — keine `\uXXXX`, kein `\b`/`\f`; es behandelt String-Literale, keine ganzen Dokumente. - **JWT** dekodiert nur — keine Signaturprüfung, keine Token-Erzeugung, keine Schlüsseleingabe. - **Data URI** hängt am vom Browser gemeldeten MIME-Typ; große Dateien ergeben unhandlich lange URIs. Für das große Bild und die Zielgruppen siehe die [Übersichtsseite](https://www.jpkc.com/db/tools/coder/), für konkrete Abläufe die [Beispiele](https://www.jpkc.com/db/tools/coder/examples/). Ausprobieren kannst du alles direkt im [Tool](https://www.jpkc.com/tools/coder/).