Convertor PRO — Manual

Zurück zur Übersicht: Convertor PRO · Tool live öffnen: www.jpkc.com/tools/convertor/

Dieses Manual beschreibt Convertor PRO vollständig: beide Tabs, jedes Eingabefeld, jeden Modus, die verwendeten Bibliotheken und die Grenzen jeder Konvertierung. Die Oberfläche des Tools ist auf Englisch — Feld-, Knopf- und Optionsnamen stehen deshalb in ihrer englischen Original-Schreibweise (mit deutscher Erläuterung), damit du dich im echten Interface zurechtfindest.

Convertor PRO ist in zwei Tabs gegliedert: Encoding (Zeichen- und Kodierungs-Umwandlung) und Data Formats (Konvertierung zwischen JSON, YAML, TOML, XML und INI). Beide arbeiten vollständig im Browser.

Tab 1: Encoding

Der Encoding-Tab nutzt die Konvertierungs-Funktionen von Richard Ishida (rishida.net, GPL). Das Grundprinzip ist wichtig zu verstehen: Es gibt eine zentrale Drehscheibe — die echten Zeichen — und rundherum mehrere Felder, die jeweils eine andere textuelle Darstellung dieser Zeichen sind.

Bedienprinzip: Convert füllt alles

Jedes Feld hat einen eigenen Convert-Knopf und einen Kopier-Knopf. Wenn du in ein Feld etwas eintippst und dessen Convert klickst, passiert zweierlei: Der Inhalt wird zunächst zu echten Zeichen dekodiert, und aus diesen Zeichen werden anschließend alle anderen Felder neu berechnet. Tippst du also é ins Feld Characters und klickst Convert, erscheinen in den übrigen Feldern automatisch é, %C3%A9, é und so weiter. Tippst du umgekehrt é ins Feld HTML/XML und klickst dessen Convert, erscheint é in Characters und alles übrige wird ebenfalls gefüllt.

Die Umwandlung ist damit in beide Richtungen möglich, immer über die Zeichen als gemeinsame Mitte. Bei leerer Eingabe meldet das Tool freundlich, dass es Text braucht.

ASCII- und Latin1-Optionen

Mehrere Felder haben zwei Checkboxen, ASCII und Latin1. Sie steuern, welche Zeichen überhaupt escaped werden. Mit ASCII (Standard bei NCRs, Unicode und 0x) bleiben ASCII-Zeichen (U+0000–U+007F) unverändert stehen und nur alles darüber wird in die jeweilige Notation umgesetzt. Mit Latin1 bleibt zusätzlich der Latin-1-Bereich unangetastet. Ohne beide werden alle Zeichen umgesetzt. Das ist nützlich, wenn du etwa nur die „exotischen" Zeichen einer ansonsten lesbaren Zeichenkette escapen willst.

Mixed input

Das oberste Feld, Mixed input, ist ein Sammelbecken: Hier darfst du gemischte Escapes unterschiedlicher Notationen zusammen einwerfen, und das Tool löst sie alle zu Zeichen auf. Es hat mehrere Knöpfe:

Convert — löst die erkannten Escapes zu Zeichen auf.
Hex CP, Dec CP — gibt zusätzlich die hexadezimalen bzw. dezimalen Code-Points aus.
UTF-8, UTF-16 — gibt die jeweiligen Code-Units aus.

Die Checkbox Convert \x schaltet die Behandlung einbuchstabiger \x-Escapes (Single-letter escapes) zu. Mixed input ist der Allrounder für „ich habe hier irgendeinen escapeten Salat und will den Klartext".

HTML/XML

Feld HTML/XML: Numerische und benannte HTML-/XML-Entities. Beim Dekodieren versteht das Feld benannte Entities (&,  , ©, …) ebenso wie numerische. Beim Erzeugen aus Zeichen gibt es zwei Optionen:

Escape invisibles (Standard: an) — wandelt unsichtbare Zeichen (etwa Steuerzeichen, geschützte Leerzeichen) in sichtbare Entities um, damit sie im Markup nicht spurlos verschwinden.
Bidi to markup — überführt Bidi-Steuerzeichen (für rechts-nach-links-Text) in entsprechendes Markup.

Percent encoding (URIs)

Feld Percent encoding (URIs): Die %XX-Notation für URLs. ü wird zu %C3%BC (Prozent-kodierte UTF-8-Bytes), und umgekehrt löst das Feld eine prozentkodierte Zeichenkette wieder zu Klartext auf. Der richtige Modus, wenn du Sonderzeichen in einen URL-Pfad oder Query-String packen musst.

Hexadecimal NCRs / Decimal NCRs

Zwei Felder für Numeric Character References, wie HTML sie kennt:

Hexadecimal NCRs — Form &#xHHHH; (z. B. 😀 für 😀).
Decimal NCRs — Form &#NNNN; (z. B. 😀).

Beide haben die ASCII-/Latin1-Optionen. NCRs funktionieren in jedem HTML/XML-Kontext und sind die robusteste Art, ein beliebiges Zeichen in Markup zu schreiben.

Unicode U+hex / 0x… notation

Zwei Felder für Code-Point-Schreibweisen, wie sie in Spezifikationen und Quelltext vorkommen:

Unicode U+hex — die Standard-Notation U+00E9, U+1F600.
0x… notation — die 0x-Schreibweise, wie sie viele Programmiersprachen für Hex-Literale nutzen.

Beide mit ASCII-/Latin1-Optionen.

Hex code points / Decimal code points

Die nackten Code-Point-Werte ohne Präfix:

Hex code points — hexadezimale Code-Points, leerzeichengetrennt.
Decimal code points — dieselben Werte dezimal.

Praktisch, wenn du Code-Points an ein Programm oder eine Tabelle weiterreichen willst, das kein bestimmtes Notations-Präfix erwartet.

UTF-8 code units / UTF-16 code units

Die tatsächlichen Encoding-Bytes bzw. Code-Units:

UTF-8 code units — die UTF-8-Byte-Sequenz eines Zeichens.
UTF-16 code units — die UTF-16-Code-Units, inklusive Surrogate-Paaren für Zeichen jenseits der Basic Multilingual Plane.

Hier siehst du, wie ein Zeichen auf Byte-Ebene wirklich gespeichert wird — wichtig beim Debugging von Encoding-Problemen.

JavaScript escapes / CSS escapes

Zwei Felder für die Escape-Syntax zweier konkreter Sprachen:

JavaScript escapes — \uXXXX-Escapes für JS-Strings. Die Checkbox C-style Supp. schaltet die C-artige Behandlung von Zeichen der supplementären Ebenen zu.
CSS escapes — die Backslash-Hex-Escapes, wie CSS sie in Selektoren und Content-Werten erlaubt.

Tab 2: Data Formats

Der zweite Tab konvertiert zwischen JSON, YAML, TOML, XML und INI. Das Bedienmodell ist Quelle → Ziel: Du gibst links Daten ein, wählst rechts ein Zielformat und klickst Convert.

Aufbau und Bedienelemente

Links der Source-Bereich mit einem Format-Auswahlfeld (JSON, YAML, TOML, XML, INI), rechts der Output-Bereich mit eigenem Format-Auswahlfeld. Beide Bereiche sind syntaxhervorhebende ACE-Editoren (Theme „Dracula", Zeilenumbruch an). Das Output-Feld ist schreibgeschützt.

Knöpfe im Source-Bereich:

Paste — fügt aus der Zwischenablage ein und erkennt das Format automatisch.
Open file — lädt eine lokale Datei (akzeptiert .json, .yaml, .yml, .toml, .xml, .htm, .html, .ini, .cfg, .conf); das Format wird aus der Endung abgeleitet, sonst per Inhaltserkennung.
Clear — leert Quelle und Ausgabe.

Knöpfe im Output-Bereich: Copy (in die Zwischenablage) und Save (als Datei mit passender Endung herunterladen). Unten: Convert (umwandeln) und Swap (Ausgabe wird zur neuen Eingabe, Formate tauschen).

Wie die Konvertierung funktioniert

Jede Konvertierung läuft in zwei Schritten über eine gemeinsame Zwischenstufe: Das Quellformat wird zu einem JavaScript-Objekt geparst, und dieses Objekt wird ins Zielformat serialisiert. Deshalb ist jede Richtung zwischen den fünf Formaten möglich — es gibt keine festen Paare, sondern fünf Parser und fünf Serializer um eine Objekt-Mitte herum.

Verwendete Bausteine:

JSON — natives JSON.parse / JSON.stringify (Ausgabe mit 2 Leerzeichen Einrückung).
YAML — die Bibliothek js-yaml (load / dump, Einrückung 2, ohne Anker/Referenzen).
TOML — eine schlanke, mitgelieferte TOML-1.0-Implementierung (Tabellen, Array-of-Tables, Strings, Mehrzeiler, Zahlen in Dezimal/Hex/Oktal/Binär, Booleans, Datumswerte, Arrays, Inline-Tabellen).
XML — der native DOMParser zum Lesen, ein eigener Serializer zum Schreiben.
INI — eigener Parser und Serializer.

Automatische Format-Erkennung

Beim Einfügen oder Datei-Öffnen versucht das Tool, das Quellformat selbst zu bestimmen: XML an führendem <, JSON an führender {/[ mit gültigem Parse, INI/TOML an [section]-Köpfen und Kommentar- bzw. Wertmustern, YAML an --- oder key:-Mustern. Das ist eine Heuristik — bei mehrdeutigen Eingaben (INI gegen TOML ähneln sich) kann sie danebenliegen; dann stellst du das Quellformat einfach von Hand korrekt ein.

Grenzen und Sonderfälle

Weil alles über eine generische Objekt-Zwischenstufe läuft, sind einige Eigenheiten unvermeidlich — gut zu wissen, bevor du dich über eine Ausgabe wunderst:

Kommentare gehen verloren. Kommentare aus YAML, TOML oder INI überleben die Konvertierung nicht, weil das Zwischenobjekt keine Kommentare kennt.
XML → Objekt: Attribute landen als Schlüssel mit @-Präfix, gemischter Textinhalt als #text. Wiederholte gleichnamige Elemente werden zu einem Array. Reine Text-Elemente werden, wenn möglich, automatisch zu Zahl oder Boolean typisiert.
Objekt → XML: Hat das Objekt genau einen Wurzelschlüssel, wird dieser zum Wurzelelement, sonst heißt die Wurzel root. Ungültige Element-Namen werden bereinigt (unerlaubte Zeichen werden zu _). Arrays werden als wiederholte gleichnamige Elemente ausgegeben. Es entsteht eine XML-Deklaration mit encoding="UTF-8".
INI ist flach. INI kennt nur eine Sektionsebene: Wurzel-Primitive kommen zuerst (ohne Sektionskopf), Unter-Objekte werden zu [section]-Blöcken, tiefer verschachtelte Objekte werden mit Punkt-Notation (a.b.c) flachgeklopft, Arrays werden zu komma-getrennten Werten. Ein Array auf Wurzelebene lässt sich nicht als INI ausgeben — das Tool meldet, dass INI auf oberster Ebene ein Objekt braucht.
INI-Typisierung beim Lesen: unquotierte Werte werden auto-typisiert (true/false/yes/no/on/off → Boolean, Zahlen → Number); ; und # leiten Kommentare ein.
Fehler werden gemeldet, nicht verschluckt. Ungültige Eingabe (kaputtes JSON, ungültiges XML, …) führt zu einer Fehlermeldung mit Begründung statt zu einer stillen Falsch-Ausgabe.

Mehr zu sinnvollen Reihenfolgen und verlustarmen Round-Trips steht in den Tipps & Tricks; konkrete Durchläufe zeigen die Beispiele.