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 — es gibt keinen Server-Aufruf, keine API, keinen Upload und keine Speicherung deiner Eingaben.

Tab 1: Encoding

Das Grundprinzip ist wichtig zu verstehen: Es gibt eine zentrale Drehscheibe — die echten Zeichen (Feld Characters) — und rundherum zwölf weitere Felder, die jeweils eine andere textuelle Darstellung dieser Zeichen sind, dazu das Sammelfeld Mixed input. Die Umrechnung arbeitet auf ganzen Unicode-Code-Points: Ein Emoji wie 😀 ist eine Einheit, auch wenn JavaScript es intern als zwei UTF-16-Code-Units speichert.

Bedienprinzip: Convert füllt alles

Jedes Feld hat einen eigenen Convert-Knopf und einen Kopier-Knopf. Du musst den Knopf aber nicht drücken: Sobald du in einem Feld tippst, wird der Inhalt 200 Millisekunden nach dem letzten Tastendruck zu echten Zeichen dekodiert, und aus diesen Zeichen werden alle anderen Felder neu berechnet. Convert löst dasselbe sofort aus. Tippst du also é ins Feld Characters, erscheinen in den übrigen Feldern é, %C3%A9, U+00E9, C3 A9 und so weiter. Tippst du umgekehrt é ins Feld Hexadecimal NCRs, 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 — und sie ist verlustfrei: Jede Notation kommt beim Zurückwandeln Zeichen für Zeichen als dein Ausgangstext heraus, auch bei Leerzeichen, Ziffern direkt nach einer Notation oder Text, der zufällig selbst wie U+… aussieht. Ausgenommen sind zwei Fälle: Die Option Bidi to markup im Feld HTML/XML ist eine Einbahnstraße — das erzeugte Markup wird beim Dekodieren nicht wieder zu Steuerzeichen. Und das Nullzeichen U+0000 können CSS escapes, HTML/XML mit Escape invisibles und die NCR-Felder, wenn weder Keep ASCII noch Keep Latin-1 an ist, nicht darstellen. In HTML/XML steht eine Referenz wie  nach HTML-Regeln für U+FFFD, und CSS escapes schreibt NUL gleich als \FFFD .

Weitere Details:

Convert bei leerem Feld meldet „Please enter text to convert.", der Kopier-Knopf bei leerem Feld „Nothing to copy."
Änderst du eine Option (Checkbox oder Auswahlfeld), werden alle Felder aus dem Inhalt von Characters neu berechnet. Ausnahme ist Decode \n, \t, \xHH: Diese Checkbox dekodiert den Inhalt von Mixed input neu — und bewirkt nichts, solange das Feld leer ist.
Hinweiszeile: Nur Percent encoding (URIs), Hex code points, Decimal code points, UTF-8 code units und UTF-16 code units melden Probleme beim Dekodieren in einer Zeile unter dem Feld — „Not understood: …" mit den ersten fünf unverständlichen Token oder „Invalid UTF-8 byte sequence — shown as U+FFFD (�)." bei kaputten UTF-8-Bytes. Die übrigen Felder haben keine Hinweiszeile: Ungültige Werte bleiben dort entweder als Text stehen (U+110000, eine unbekannte Entity wie &foo;) oder werden ohne Meldung zu U+FFFD (�) (&#x110000;). Ebenso bei Mixed input: Unbekanntes bleibt dort als Text stehen, und ungültige Prozent- oder UTF-8-Bytefolgen erscheinen ohne Meldung als U+FFFD (�).
Auf schmalen Bildschirmen (unter 992 Pixel Breite) stehen die Felder untereinander statt paarweise nebeneinander.

Optionen Keep ASCII und Keep Latin-1

Vier Felder — Hexadecimal NCRs, Decimal NCRs, Unicode U+hex und 0x... notation — haben zwei Checkboxen, Keep ASCII und Keep Latin-1. Sie steuern, welche Zeichen überhaupt in die Notation umgesetzt werden:

Keep ASCII (Standard: an) — ASCII-Zeichen (U+0000–U+007F) bleiben stehen, nur alles darüber wird umgesetzt.
Keep Latin-1 — zusätzlich bleibt der Latin-1-Bereich (bis U+00FF, also auch ä, ö, ü, ß, é) stehen. Latin-1 schließt ASCII ein; ist die Checkbox an, spielt Keep ASCII keine Rolle.
Ohne beide werden alle Zeichen umgesetzt.

Eine Ausnahme sorgt dafür, dass das Ergebnis eindeutig lesbar bleibt: Würde ein behaltenes Zeichen mit der Notation davor verschmelzen — eine Hex-Ziffer (0–9, A–F, a–f) oder ein Leerzeichen direkt nach U+00DC oder 0xDC —, schreibt das Tool auch dieses Zeichen als Notation. Aus Über wird mit Keep ASCII im Feld Unicode U+hex deshalb U+00DC U+0062 U+0065r, im Feld Hexadecimal NCRs dagegen Über, weil das Semikolon die Referenz sauber abschließt. Dasselbe gilt für behaltenen Text, der selbst wie eine Notation beginnt.

Die Felder Hex code points und Decimal code points haben diese Optionen nicht — in einer reinen Zahlenliste wäre ein stehengebliebener Buchstabe nicht eindeutig.

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 in einem einzigen Durchgang zu Zeichen auf. Bereits Dekodiertes wird nicht noch einmal gelesen: &amp; wird zu &, nicht zu &. Erkannt werden:

U+00E9 und 0xE9 (1 bis 6 Hex-Ziffern),
numerische Referenzen é und é sowie benannte Entities mit Semikolon (ü, —, …),
JavaScript-Escapes \u00E9, \u{1F600} und \U0001F600,
Prozent-Folgen wie %C3%BC (als UTF-8 gelesen).

Die Checkbox Decode \n, \t, \xHH (Standard: aus) entscheidet, wie ein Backslash gelesen wird:

an — statt CSS-Escapes werden \xHH und die Kurz-Escapes \b, \f, \n, \r, \t, \v, \0, \', \" und \\ wie in JavaScript dekodiert; \E9 bleibt dann stehen.
aus — ein Backslash mit 1 bis 6 Hex-Ziffern gilt als CSS-Escape (\E9 → é), alles andere bleibt stehen. Ausnahme: Ein \b, \f oder \0, auf das weder eine weitere Hex-Ziffer noch Leerraum folgt, wird wie in JavaScript als Rückschritt, Seitenvorschub bzw. NUL gelesen. So überlebt etwa ein Windows-Pfad wie C:\temp unverändert, der mit eingeschalteter Option ein Tabulatorzeichen enthielte — aber nur, solange kein Pfadteil nach dem Backslash mit 0–9 oder a–f beginnt: In C:\data\file wird \da als CSS-Escape zu Ú und \f zum Seitenvorschub.

Die Knöpfe des Feldes:

Convert — löst die erkannten Notationen auf (das passiert auch live beim Tippen).
Hex CP, Dec CP, UTF-8, UTF-16 — lösen zusätzlich nackte Zahlenfolgen im übrigen Text auf: hexadezimale Code-Points (1 bis 6 Ziffern), dezimale Code-Points (1 bis 7 Ziffern), UTF-8-Bytes (je zwei Hex-Ziffern) oder UTF-16-Code-Units (je vier Hex-Ziffern), getrennt durch Leerzeichen oder Komma. Aus Code: 48 65 6C 6C 6F wird mit Hex CP Code: Hello, aus C3 BC 20 E2 82 AC mit UTF-8 ü €. Zahlen, die an Buchstaben oder Ziffern hängen, bleiben unberührt — aus café wird also nicht versehentlich U+0CAF.

Das Ergebnis landet in Characters und von dort in allen anderen Feldern. Mixed input ist der Allrounder für „ich habe hier irgendeinen escapten Salat und will den Klartext".

HTML/XML

Feld HTML/XML: Text, wie er in HTML- oder XML-Markup stehen darf. Beim Erzeugen aus Zeichen werden &, <, > und " immer zu &, <, > und "; alles andere bleibt lesbar stehen. Dazu zwei Optionen:

Escape invisibles (Standard: an) — schreibt unsichtbare oder leicht verwechselbare Zeichen als &#x…;, damit sie im Markup nicht spurlos verschwinden: Steuerzeichen (außer Tab, Zeilenvorschub und Wagenrücklauf), geschützte und alle anderen Sonder-Leerzeichen außer dem normalen Leerzeichen, weiches Trennzeichen, Null-Breite-Zeichen, Richtungsmarken, Variation Selectors, BOM und Tag-Zeichen.
Bidi to markup — ersetzt Bidi-Steuerzeichen durch Markup: Einbettungen (LRE/RLE) durch <span dir="ltr|rtl">, Overrides (LRO/RLO) durch <bdo dir="…">, Isolates (LRI/RLI/FSI) durch <bdi>; PDF und PDI schließen das jeweilige Element, offen gebliebene Elemente schließt das Tool am Ende. Die Richtungsmarken LRM/RLM werden zu &lrm; und &rlm;.

Beim Dekodieren versteht das Feld numerische Referenzen (hexadezimal und dezimal) und alle 2125 benannten HTML5-Entities — aufgelöst vom HTML-Parser deines Browsers, einschließlich der alten Formen ohne Semikolon wie &copy. , Surrogate und Werte über U+10FFFF werden wie im HTML-Standard zum Ersatzzeichen U+FFFD. Die Bereiche  bis  liest das Tool bewusst als die C1-Steuerzeichen, die sie nach Unicode sind — nicht als Windows-1252-Zeichen wie €, die ein Browser beim Rendern daraus macht.

Percent encoding (URIs)

Feld Percent encoding (URIs): Die %XX-Notation für URLs. Jedes Zeichen außer A–Z, a–z, 0–9, -, ., _ und ~ wird als UTF-8-Byte prozentkodiert — ü wird zu %C3%BC, ein Leerzeichen zu %20, auch /, ? und & werden kodiert. Umgekehrt löst das Feld Folgen von %XX als UTF-8 wieder auf; ein % ohne zwei Hex-Ziffern dahinter bleibt stehen. Bilden die Bytes kein gültiges UTF-8, erscheint U+FFFD (�) plus Hinweis unter dem Feld.

Hexadecimal NCRs / Decimal NCRs

Zwei Felder für Numeric Character References, wie HTML und XML sie kennen:

Hexadecimal NCRs — Form &#xHHHH; mit mindestens vier Hex-Ziffern (é, 😀 für 😀).
Decimal NCRs — Form &#NNNN; (é, 😀).

Beide haben die Optionen Keep ASCII und Keep Latin-1. Beim Dekodieren lesen beide Felder hexadezimale und dezimale Referenzen, das Semikolon ist optional; , Surrogate und Werte über U+10FFFF werden zu U+FFFD. NCRs funktionieren in jedem HTML- und 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 mit mindestens vier Hex-Ziffern: U+00E9, U+1F600.
0x... notation — die 0x-Schreibweise ohne führende Nullen (0xE9, 0x1F600), wie sie viele Programmiersprachen für Hex-Literale nutzen.

Aufeinanderfolgende Notationen trennt ein Leerzeichen, das der Decoder wieder entfernt; ein echtes Leerzeichen direkt nach einer Notation (oder wenn weder Keep ASCII noch Keep Latin-1 an ist) erscheint selbst als U+0020 bzw. 0x20. Beim Dekodieren werden 1 bis 6 Hex-Ziffern gelesen. Beide Felder haben Keep ASCII und Keep Latin-1.

Hex code points / Decimal code points

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

Hex code points — hexadezimal mit mindestens vier Stellen (00E9 1F600).
Decimal code points — dieselben Werte dezimal (233 128512).

Beim Dekodieren sind die Felder großzügig: Trennzeichen dürfen Leerzeichen, Kommas oder Semikolons sein, und im Hex-Feld werden auch Werte mit Präfix U+, 0x, \u, \u{…}, \x oder &#x angenommen (im Dezimal-Feld &#). Token, die keine Zahl sind, bleiben als Text stehen und werden in der Hinweiszeile genannt; Werte über U+10FFFF werden zu U+FFFD und ebenfalls gemeldet. Praktisch, wenn du Code-Points aus einer Tabelle oder einem Programm übernehmen oder dorthin weiterreichen willst.

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, je Byte zwei Hex-Ziffern (é → C3 A9, 😀 → F0 9F 98 80).
UTF-16 code units — die UTF-16-Code-Units mit vier Stellen, inklusive Surrogate-Paaren für Zeichen jenseits der Basic Multilingual Plane (😀 → D83D DE00).

Beim Dekodieren nimmt das UTF-8-Feld die Bytes auch zusammengeschrieben (C3A9) oder mit Präfix 0x, \x oder % an; ungültige Bytefolgen werden zu U+FFFD plus Hinweis. Im UTF-16-Feld werden Werte über FFFF gemeldet. 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 — druckbares ASCII bleibt stehen; \b, \t, \n, \v, \f, \r, \", \' und \\ erscheinen in Kurzform, NUL als \0 (vor einer Ziffer als \x00), übrige Steuerzeichen als \xHH, alles von U+0080 bis U+FFFF als \uXXXX. Für Zeichen oberhalb von U+FFFF wählst du im Auswahlfeld Above U+FFFF die Schreibweise: \uD83D\uDE00 (pair) — das Surrogate-Paar, Standard und überall gültig —, \u{1F600} (ES6) oder \U0001F600 (C, Python). Beim Dekodieren versteht das Feld die volle JavaScript-Escape-Grammatik einschließlich \u{…}, \xHH und Zeilenfortsetzung, dazu die C/Python-Form \UXXXXXXXX.
CSS escapes — Backslash, " und ' bekommen einen Backslash vorangestellt, druckbares ASCII bleibt stehen, alles andere wird zu \HEX plus einem Leerzeichen (é → \E9 ). Das Leerzeichen beendet das Escape und wird vom CSS-Parser verschluckt — es muss also mitkopiert werden. Beim Dekodieren liest das Feld 1 bis 6 Hex-Ziffern samt optionalem Leerraum danach; ungültige Werte werden zu U+FFFD.

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 — die Ausgabe entsteht schon beim Tippen.

Aufbau und Bedienelemente

Links der Source-Bereich mit einem Format-Auswahlfeld (Auto-detect als Standard, dazu JSON, YAML, TOML, XML, INI), rechts der Output-Bereich mit eigenem Format-Auswahlfeld (YAML, JSON, TOML, XML, INI; Standard JSON). Steht die Quelle auf Auto-detect, zeigt ein Abzeichen neben dem Auswahlfeld das erkannte Format — oder rot „unknown", wenn kein Parser die Eingabe annimmt. Beide Bereiche sind syntaxhervorhebende ACE-Editoren (Theme „Dracula", Zeilenumbruch an, Einrückung zwei Leerzeichen); das Output-Feld ist schreibgeschützt. Über den Editoren steht der Hinweis, dass alles in deinem Browser läuft.

Die Knöpfe sind reine Symbole; ihre Namen erscheinen als Tooltip. Im Source-Bereich:

Paste from clipboard — liest die Zwischenablage (dein Browser fragt dafür ggf. um Erlaubnis) und setzt den Inhalt als Quelle ein. Klappt das nicht, meldet das Tool „Failed to read clipboard. Please paste manually." — dann fügst du mit Strg+V bzw. Cmd+V direkt in den Editor ein.
Open file — lädt eine lokale Datei (.json, .yaml, .yml, .toml, .xml, .htm, .html, .ini, .cfg, .conf). Bei .json, .yaml/.yml, .toml, .xml und .ini stellt die Endung das Source-Format ein; bei .htm/.html, .cfg und .conf springt die Auswahl auf Auto-detect, weil die Endung dort nichts Eindeutiges sagt.
Clear — leert Quelle, Ausgabe und die Meldungen.

Im Output-Bereich: Copy to clipboard und Save as file — der Download heißt converted.json, converted.yaml, converted.toml, converted.xml oder converted.ini. Bei leerer Ausgabe melden beide „Nothing to copy." bzw. „Nothing to save.".

Unter den Editoren:

Convert — wandelt sofort um und bestätigt das Ergebnis mit einer kurzen Meldung.
Swap — die Ausgabe wird zur neuen Quelle, das bisherige Zielformat zum Quellformat und das tatsächlich verwendete Quellformat (auch ein automatisch erkanntes) zum neuen Ziel.

Live-Konvertierung

Jede Änderung im Source-Editor löst 350 Millisekunden nach dem letzten Tastendruck eine Konvertierung aus; ein Wechsel des Quell- oder Zielformats konvertiert sofort. Bei Eingaben über 400.000 Zeichen schaltet sich die Live-Konvertierung ab — dann wandelst du mit Convert um, damit der Browser beim Tippen nicht ins Stocken gerät.

Wie die Konvertierung funktioniert

Jede Konvertierung läuft in zwei Schritten über eine gemeinsame Zwischenstufe: Das Quellformat wird zu einem Objektbaum geparst, und dieser Baum 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 gemeinsame Mitte herum.

Verwendete Bausteine:

JSON — die Bibliothek lossless-json (öffnet in neuem Tab) zum Lesen (doppelte Schlüssel mit unterschiedlichem Wert gelten als Fehler, ein Duplikat mit gleichem Wert wird ohne Meldung angenommen), Ausgabe mit zwei Leerzeichen Einrückung.
YAML — die Bibliothek js-yaml (öffnet in neuem Tab) (load / dump, Einrückung 2, ohne automatischen Zeilenumbruch, ohne Anker/Referenzen — mehrfach verwendete Knoten werden ausgeschrieben).
TOML — die Bibliothek smol-toml (öffnet in neuem Tab), ein vollständiger TOML-1.0-Parser und -Serializer; ungültiges TOML wird mit Zeilenangabe abgewiesen.
XML — der DOMParser des Browsers zum Lesen, ein eigener Serializer zum Schreiben.
INI — eigener Parser und Serializer.

Exakte Zahlen

Liest das Tool JSON, reisen große Ganzzahlen jenseits von 2^53 (etwa 20-stellige IDs) und ganzzahlige Gleitkommazahlen wie 1.0 nicht als JavaScript-Zahl durch die Konvertierung, sondern als ziffergenaue Zeichenfolge. 12345678901234567890 bleibt in JSON, YAML, XML und INI genau so stehen, statt zu 12345678901234567000 zu werden, und 1.0 bleibt 1.0 statt 1. Ausnahme INI: In Listen, die INI als JSON-String schreibt (siehe Fehler und Hinweise), stehen solche Zahlen wieder als JavaScript-Zahl — aus [[1.0, 12345678901234567890]] wird [[1,12345678901234567000]]. TOML kennt nur 64-Bit-Ganzzahlen: Größere Werte schreibt das Tool dort als String und meldet das.

Dieser Schutz hängt am Quellformat:

JSON: wie beschrieben. Andere Gleitkommazahlen werden aber als JavaScript-Zahl gelesen, eine Nachkomma-Null wie in 1.10 entfällt (1.1).
TOML: Ganzzahlen bis 64 Bit bleiben ziffergenau, Gleitkommazahlen werden als JavaScript-Zahl gelesen — aus 1.0 wird 1, selbst bei TOML → TOML.
YAML: Jede Zahl wird als JavaScript-Zahl gelesen. Große Ganzzahlen verlieren ihre letzten Stellen, 1.0 wird zu 1.
XML und INI: Solche Werte bleiben Strings (siehe Grenzen und Sonderfälle), die Ziffern also erhalten.

Keiner dieser Verluste — 1.10 aus JSON, Zahlen aus YAML und TOML, Zahlen in den JSON-Strings von INI — wird eigens gemeldet. Datums- und Zeitwerte aus TOML behalten ihre Form (lokales Datum, lokale Uhrzeit oder Zeitstempel mit Offset) und werden in den anderen Formaten als ISO-Zeichenfolge ausgegeben, ebenfalls ohne Hinweis.

Automatische Format-Erkennung

Auto-detect rät nicht nach Mustern, sondern parst die Eingabe probeweise — strenge Formate zuerst:

Beginnt der Text mit <, gilt er als XML.
Beginnt er mit { oder [ und ist gültiges JSON: JSON.
Lässt er sich als TOML lesen (mit mindestens einem Schlüssel): TOML.
Ergibt er als YAML ein Objekt oder eine Liste (nicht nur einen einzelnen Wert): YAML.
Lässt er sich als INI lesen: INI.
Ist er sonst gültiges JSON in beliebiger Form, etwa ein einzelner Wert wie 42 oder "text": JSON.

a = 1 ist damit TOML, [server] mit host = localhost dagegen INI (unquotierte Strings sind in TOML ungültig), name: x ist YAML. Passt nichts, meldet das Tool „The format was not recognized" und empfiehlt, das Format links von Hand zu wählen — dann siehst du die genaue Fehlermeldung des jeweiligen Parsers.

Fehler und Hinweise

Unter den Editoren erscheinen zwei Arten von Meldungen:

Fehler (rot) — die Eingabe ließ sich nicht lesen. Die Meldung des Parsers nennt, wo möglich, Zeile und Spalte; der Knopf Go to line … setzt den Cursor genau dorthin, und im Source-Editor markiert ein Fehlersymbol die Zeile. Klappt das Schreiben ins Zielformat nicht, steht „Writing … failed" da.
Hinweise (gelb) unter der Überschrift „Not everything fits the target format:" — die Anpassungen, die das Tool vornimmt, weil das Zielformat etwas nicht abbilden kann, jeweils mit Pfad zur betroffenen Stelle. Vollständig ist diese Liste nicht: Einige Änderungen geschehen ohne Hinweis (siehe unten).

Die möglichen Hinweise:

TOML: null gibt es nicht — Schlüssel mit null entfallen, null in Listen wird entfernt. Ganzzahlen über 64 Bit werden zu Strings. Steht oben kein Objekt (sondern eine Liste oder ein einzelner Wert), landet es unter dem Schlüssel items.
JSON: inf und nan (etwa aus TOML) gibt es nicht — sie werden zu null.
XML: Ungültige Element- oder Attributnamen werden umbenannt (unerlaubte Zeichen werden zu _, ein Name, der nicht mit Buchstabe oder _ beginnt, bekommt ein _ vorangestellt). Steuerzeichen, die XML 1.0 nicht einmal als Referenz erlaubt, werden entfernt. Eine Liste auf oberster Ebene wird in <root> mit einem <item> je Eintrag verpackt. Beim Lesen: XML-Kommentare werden nicht übernommen, und Text zwischen Kind-Elementen (Mixed Content) wird in #text zusammengefasst — seine Position geht verloren.
INI: Listen, die Objekte oder weitere Listen enthalten (etwa ein TOML-Array [[servers]]), werden als JSON-String geschrieben, null als leerer Wert, Schlüssel mit =, [ oder ] umbenannt; steht oben kein Objekt, landet es unter items. Beim Lesen: Kommt ein Schlüssel doppelt vor, gewinnt der letzte Wert.

Ohne Hinweis bleiben dagegen:

Kommentare und Formatierung (nur verworfene XML-Kommentare werden gemeldet),
die Punkt-Notation, mit der tief verschachtelte Objekte beim Schreiben nach INI flachgeklopft werden,
die Hülle <root>, die beim Schreiben nach XML entsteht, wenn das Objekt nicht genau einen passenden Schlüssel hat,
Zahlen aus YAML- und TOML-Quellen, die Stellen oder die Form 1.0 verlieren, und die Nachkomma-Null von JSON-Gleitkommazahlen wie 1.10 (siehe Exakte Zahlen),
verlorene Stellen und die verlorene Form 1.0 in Listen, die INI als JSON-String schreibt (gemeldet wird nur der JSON-String selbst),
Datums- und Zeitwerte aus TOML, die in den anderen Formaten zu Zeichenfolgen werden.

Eine leere Hinweis-Box heißt also nicht, dass nichts verändert wurde.

Grenzen und Sonderfälle

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

Kommentare gehen verloren. Kommentare aus YAML, TOML, INI oder XML überleben die Konvertierung nicht, weil die Zwischenstufe keine Kommentare kennt (bei XML weist das Tool darauf hin).
Typisierung nur, wo sie eindeutig ist. XML-Texte und -Attribute sowie unquotierte INI-Werte werden nur dann zu Boolean oder Zahl, wenn sie exakt true/false oder eine kanonisch geschriebene Zahl sind (42, -3.5). 0123, +49, 0755, 1e3, yes und on bleiben Strings — eine Postleitzahl mit führender Null oder ein Dateimodus kommt also unverändert heraus.
XML → Objekt: Der Name des Wurzelelements bleibt als oberster Schlüssel erhalten (<book>…</book> → {"book": {…}}). Attribute landen als Schlüssel mit @-Präfix, Text neben Attributen oder Kind-Elementen als #text. Wiederholte gleichnamige Elemente werden zu einem Array, ein leeres Element zu einem leeren String. Namen mit Namespace-Präfix (dc:title) bleiben, wie sie sind.
Objekt → XML: Es entsteht eine XML-Deklaration <?xml version="1.0" encoding="UTF-8"?>. Hat das Objekt genau einen Schlüssel (kein @/#-Schlüssel, kein Array), wird dieser zum Wurzelelement, sonst heißt die Wurzel root — beim Zurücklesen erscheint root dann als zusätzlicher oberster Schlüssel. @-Schlüssel werden zu Attributen, #text zum Textinhalt, Arrays zu wiederholten gleichnamigen Elementen (Arrays in Arrays bekommen ein Hüll-Element mit <item>-Einträgen), null zu einem leeren Element. Ein Namespace-Präfix bleibt nur erhalten, wenn ein passendes @xmlns:präfix im Gültigkeitsbereich steht — sonst wird der Doppelpunkt zu _, damit das Ergebnis wohlgeformt bleibt.
INI lesen: Zeilen mit ; oder # am Anfang sind Kommentare, ; oder # nach einem unquotierten Wert leiten einen Inline-Kommentar ein. [section] öffnet eine Sektion — nur eine Ebene; [a.b] ergibt einen Schlüssel namens a.b, keine Verschachtelung. key[] = wert sammelt mehrere Zeilen zu einer Liste. Werte in doppelten Anführungszeichen verstehen \n, \t, \r, \" und \\, Werte in einfachen Anführungszeichen werden wörtlich genommen. Eine Zeile ohne = ist ein Fehler mit Zeilenangabe.
INI schreiben: Werte der obersten Ebene kommen zuerst (ohne Sektionskopf), Unter-Objekte werden zu [section]-Blöcken, tiefer verschachtelte Objekte werden ohne Hinweis mit Punkt-Notation (db.host = …) flachgeklopft, Listen einfacher Werte werden zu key[] = …-Zeilen, Listen mit Objekten oder Listen darin zu einem JSON-String (mit Hinweis). Strings, die beim Zurücklesen als anderer Typ ankämen ("true", "42"), leer sind, Leerraum am Rand oder Sonderzeichen wie ;, # und Zeilenumbrüche enthalten, werden in Anführungszeichen gesetzt und escaped. Die Punkt-Notation macht der INI-Leser beim Zurückwandeln nicht rückgängig: db.host bleibt ein Schlüssel mit Punkt.

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