JPKCom DB

Coder — Manual

Vollständige Funktionsbeschreibung des Coder: alle sieben Encode-/Decode-Reiter, was sie genau tun, Eingabe und Ausgabe, Sonderfälle und die Grenzen.

Zurück zur Übersicht: Coder · Tool live öffnen: 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: & → &amp;, < → &lt;, > → &gt; (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 (&amp;, &lt;, &gt;). Beliebige andere Entities — etwa &copy;, &nbsp; oder numerische wie &#8364; — 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: & → &amp;, < → &lt;, > → &gt;, " → &quot;, ' → &#39;.
  • 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.

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.

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:<mimetype>;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, für konkrete Abläufe die Beispiele. Ausprobieren kannst du alles direkt im Tool.