# Convertor PRO — Tipps & Tricks

> Kniffe für Convertor PRO: verlustarme Round-Trips, Format-Erkennung, ASCII-/Latin1-Optionen und die Kombination mit anderen JPKCom-Tools.

Source: https://www.jpkc.com/db/tools/convertor/tips/

Zurück zur Übersicht: [Convertor PRO](https://www.jpkc.com/db/tools/convertor/) · Tool live öffnen: [www.jpkc.com/tools/convertor/](https://www.jpkc.com/tools/convertor/)

Das [Manual](https://www.jpkc.com/db/tools/convertor/manual/) erklärt jedes Feld, die [Beispiele](https://www.jpkc.com/db/tools/convertor/examples/) zeigen die Arbeitsabläufe. Hier geht es um das, was beides voraussetzt, aber selten dabeisteht: wo die echten Stolperfallen liegen, wann eine Konvertierung verlustbehaftet ist und wie du Convertor PRO mit anderen Werkzeugen kombinierst. Die Oberfläche ist auf Englisch — die echten Tab- und Knopf-Namen stehen deshalb im Original.

## Daten-Formate: was eine Konvertierung verliert

Der wichtigste mentale Schritt: Jede Format-Konvertierung läuft über eine **gemeinsame Daten-Zwischenstufe** (ein JavaScript-Objekt). Was dieses Objekt nicht abbilden kann, geht verloren — egal in welcher Richtung.

- **Kommentare überleben nie.** YAML-, TOML- und INI-Kommentare sind nach der Konvertierung weg. Wenn dir Kommentare wichtig sind, konvertiere früh und kommentiere danach im Zielformat — nicht umgekehrt.
- **Reihenfolge und Formatierung sind nicht garantiert.** Du bekommst eine kanonische, sauber eingerückte Ausgabe, nicht dein Original-Layout. Für einen Diff gegen die Quelle ist das ungünstig; zum Aufräumen ist es ideal.
- **Round-Trips sind selten verlustfrei.** JSON → YAML → JSON kommt meist sauber zurück, weil beide dasselbe Datenmodell teilen. Sobald aber XML (mit seiner `@attr`/`#text`-Übersetzung) oder INI (mit seiner flachen Struktur) im Spiel ist, weicht das Rückergebnis strukturell ab. Plane Konvertierungen als Einbahnstraße, nicht als hin und zurück.

## INI ist die engste Form — dorthin zuletzt

INI hat das schwächste Datenmodell der fünf Formate: nur eine Sektionsebene. Konvertierst du etwas Verschachteltes nach INI, werden tiefe Objekte mit **Punkt-Notation** (`a.b.c`) flachgeklopft und Arrays zu komma-getrennten Werten — und ein **Array auf Wurzelebene** wird komplett abgelehnt. Praktische Regel: **INI nur als Ziel, wenn die Daten von Natur aus flach sind.** Für alles Strukturreiche sind JSON, YAML oder TOML die ehrlicheren Ziele. Details in den [Grenzen im Manual](https://www.jpkc.com/db/tools/convertor/manual/#grenzen-und-sonderfaelle).

## Der Format-Erkennung vertrauen — aber nicht blind

**Paste** und **Open file** erraten das Quellformat: am führenden Zeichen, an `[section]`-Köpfen, an `key:`- oder `key =`-Mustern. Das spart Klicks. Aber INI und TOML sehen sich ähnlich, und die Heuristik kann danebenliegen. Faustregel: Nach dem Einfügen kurz prüfen, ob das **Source**-Auswahlfeld auf dem Format steht, das du erwartest — und es bei Bedarf von Hand korrigieren, bevor du **Convert** klickst. Die Dateiendung beim Öffnen ist zuverlässiger als die Inhaltserkennung.

## Encoding: ASCII-Checkbox als „nur das Exotische"-Schalter

Im **Encoding**-Tab ist die **ASCII**-Checkbox der nützlichste, am häufigsten übersehene Schalter. Sie sitzt an den Feldern *Hexadecimal NCRs*, *Decimal NCRs*, *Unicode U+hex* und *0x notation* (nicht am HTML/XML-Feld) und ist dort standardmäßig an. Mit ihr bleiben normale ASCII-Zeichen lesbar stehen und nur die „besonderen" Zeichen werden umgesetzt. Beispiel Feld *Hexadecimal NCRs*, Eingabe `Über`: Mit aktivem **Restrict to ASCII** wird nur das Nicht-ASCII-`Ü` zur Hex-NCR — Ergebnis `Über`, die ASCII-Buchstaben `ber` bleiben stehen. Schaltest du die Checkbox ab, werden auch die ASCII-Zeichen zu NCRs (`Über`) — eine Wand aus Entities, die du fast nie willst. Brauchst du wirklich *jedes* Zeichen escaped (etwa für ein striktes ASCII-Transport-Format), ist genau das der richtige Modus.

## Mixed input ist der Universal-Entschlüssler

Wenn du Text aus unbekannter Quelle hast, in dem mehrere Escape-Arten durcheinander vorkommen — ein paar `&#x…;`, ein `%C3%BC`, ein `é` —, dann tippe ihn nicht mühsam in einzelne Felder. Wirf ihn in **Mixed input** und klick **Convert**: Das Feld erkennt die verschiedenen Notationen gemeinsam und liefert den Klartext. Die Modi **Hex CP** / **Dec CP** / **UTF-8** / **UTF-16** geben dir dazu direkt die gewünschte Code-Point- oder Byte-Sicht.

## Surrogate-Paare und Emojis korrekt verstehen

Bei Zeichen jenseits der Basic Multilingual Plane (Emojis, viele Symbole, seltene Schriften) lohnt der Blick auf **UTF-16 code units**: Dort siehst du das **Surrogate-Paar**, mit dem solche Zeichen in JavaScript und UTF-16 intern dargestellt werden. Wenn ein String in JS „eine falsche Länge" hat oder ein Emoji beim Abschneiden zerbricht, ist das fast immer ein Surrogate-Problem — Convertor PRO macht es sichtbar.

## Nichts verlässt deinen Rechner

Convertor PRO ist **rein clientseitig** — kein Upload, kein Server-Roundtrip. Das ist nicht nur schnell, sondern auch der Grund, warum du **Konfigurationen mit Secrets, Tokens oder internen Hostnamen** bedenkenlos konvertieren kannst: Die Daten bleiben im Browser-Tab. (Trotzdem gilt: Ausgaben, die du kopierst oder herunterlädst, behandelst du wie das sensible Original.)

## Kombination mit anderen JPKCom-Tools

Convertor PRO klärt Encoding und Format — für das, was davor oder danach kommt, helfen die Nachbarn aus der Code-&-Text-Familie:

- **[JSON-Editor](https://www.jpkc.com/db/tools/json/)** — wenn du nach der Konvertierung tiefer mit der JSON-Struktur arbeiten willst: validieren, durchsuchen, gezielt editieren. Convertor PRO bringt dich ins JSON, der JSON-Editor arbeitet darin.
- **[Coder](https://www.jpkc.com/db/tools/coder/)** — für Encoding-Operationen jenseits der Zeichen-Umwandlung: Base64, vollständiges URL-Encoding, Hashing. Wo Convertor PRO bei Zeichen-Repräsentationen aufhört, macht Coder weiter.