XML ⇄ JSON-konverterare
Dubbelriktad XML ↔ JSON med attributhantering, CDATA-bevarande, BOM, radslut och indentering
Indata
Utdata
XML ⇄ JSON-konverterare
Dubbelriktad XML ↔ JSON med attributhantering, CDATA-bevarande, BOM, radslut och indentering
Funktioner
- Auto-detekteringsläget känner av om den inklistrade texten är XML eller JSON och kör konverteringen i motsatt riktning — klistra in vilken sida som helst utan att byta läge manuellt
- Två attributstrategier: Prefixläge emit XML-attribut med ett konfigurerbart prefix (standard `@`) som JSON-syskonnycklar; Objektläge samlar dem i ett separat `$`-objekt, så elementtext och attribut aldrig krockar
- CDATA- och textnodshantering: med "Behandla CDATA/Text som #text" på viks elementtextinnehållet ihop till en `#text`-egenskap; blandat innehåll överlever JSON-rundtripen; av bevarar den strukturella skillnaden
- Pretty-print-omkopplare med valbart indrag (2 / 4 / 8 mellanslag) för JSON- och XML-utdata — på för mänsklig läsning, av för kompakt transport
- Radslutskontroll (LF vs CRLF) för kompatibilitet med Unix vs Windows-verktyg, plus valfri UTF-8 BOM-omkopplare för system som kräver byte-order mark
- Konfigurerbart attributprefix matchar nedströms konventioner: `@` (standard), `_`, `xml:` eller annan sträng — håller den konverterade utdatan drop-in-kompatibel med din befintliga pipeline
- Ett-kliks Kopiera och Ladda ner (`converted.txt`) för utdata; konverteringsfel ytar inline med parsermeddelandet — du vet om XML var malformat eller JSON inte var representabelt som XML
- Helt klientsida: parsning via inbyggd DOMParser för XML och JSON.parse för JSON. Inga nätverksanrop, fungerar offline efter cachning
Så använder du
- Klistra in din XML eller JSON i Indata-rutan. Med Läge på Auto-detektera känner konverteraren av formatet automatiskt.
- Justera Pretty-omkopplaren och indragstorleken för att styra utdataformatering; växla Radslut mellan LF och CRLF som dina nedströms-verktyg kräver.
- Öppna Avancerade inställningar för att välja Attributläge (Prefix eller Objekt), sätta Attributprefix och växla CDATA/Text-#text.
- Klicka Konvertera. Utdata-rutan visar resultatet; konvertering körs i din webbläsare via DOMParser + JSON.parse.
- Använd Kopiera för urklipp, eller Ladda ner för att spara som `converted.txt`.
- Om parsning misslyckas visar en inline-felrad det underliggande meddelandet — fixa indatan och konvertera igen.
Tips och bästa praxis
- Vid felsökning av en XML-nyttolast från en SOAP-tjänst ger Auto-detektera + Objekt-attributläge + CDATA-#text den renaste JSON-vyn.
- Sätt Radslut till CRLF och aktivera BOM vid generering av utdata avsedd för äldre Windows-verktyg.
- Växla Attributprefix från `@` till `_` om dina JSON-konsumenter avvisar nycklar som börjar med `@` (vissa YAML-härledda parsers gör det).
- Om JSON-till-XML-utdata sätter element i fel ordning, återinsätt dina toppnivånycklar i käll-JSON i den ordning du vill emit dem.
- Kombinera med JSON Formatter när du vill inspektera eller transformera den konverterade JSON vidare; XML Formatter på XML-sidan.
Vanliga frågor
Hur ändrar Attributläget JSON-utdata?
I Prefixläge framträder XML-attribut som syskonnycklar med det konfigurerade prefixet — `<user id="42"/>` blir `{ "user": { "@id": "42" } }`. I Objektläge samlas attribut under en enda `$`-nyckel, så elementinnehåll och attributinnehåll delar inte namespace. Välj Prefix när konsumenter förväntar platta nycklar; Objekt när du behöver rundtripa attribut tillbaka till XML utan tvetydighet.
Vad är CDATA-som-#text till för?
XML har två sätt att bära text — `<a>plain</a>` och `<a><![CDATA[plain]]></a>`. Med alternativet på kollapsar båda till en `#text`-nyckel i JSON; blandat innehåll som `<p>Hej <b>världen</b></p>` överlever rundtripen. Av bevarar den strukturella skillnaden; användbart när originaldokumentets CDATA-markörer är semantiskt betydelsefulla (t.ex. inbäddade skript).
Varför spelar BOM-omkopplaren roll?
Vissa Windows-verktyg (Excel, äldre PowerShell, .NET TextReader utan explicit kodning) förväntar en UTF-8 BOM (`EF BB BF`) i början av en fil för att upptäcka kodning. Moderna webbverktyg och Unix-pipelines behandlar BOM oftast som brus. Aktivera omkopplaren för BOM-medvetna Windows-verktyg, avaktivera för allt annat.
Varför LF vs CRLF?
Windows-verktyg och äldre Microsoft-format förväntar `\r\n` (CRLF); Unix/Linux/macOS använder `\n` (LF) som standard. Git normaliserar oftast båda, men artefakter som kringgår git (nedladdningar, klistringar i Notepad, byggutdata) behöver det explicita valet. Auto-detektera-parsern ignorerar radslut; denna kontroll påverkar bara utdata.
Överlever namespaces konverteringen?
Namespace-prefixade element- och attributnamn rundtripar som bokstavliga strängar (t.ex. `xmlns:soap` blir nyckeln `@xmlns:soap`). Konverteraren löser inte namespaces mot URI:er — om din nedströmspipeline behöver namespace-upplösning, gör det steget separat. Rundtripen tillbaka till XML bevarar startprefixen.
Vad händer med tomma element?
Ett tomt XML-element `<a/>` blir `{ "a": null }` i JSON (eller `{ "a": "" }` om det var `<a></a>` med tom text och CDATA-#text på). Vid JSON-till-XML emit ett `null`-värde ett självstängande element. Rundtripen är stabil så länge du inte växlar CDATA-#text-inställningen mellan riktningarna.
Varför har min JSON-till-XML-utdata ordnade nycklar?
XML-element har definierad ordning; JavaScript-objekt bevarar insättningsordning för strängnycklar, så konverteraren skriver element i den ordning deras nycklar dök upp i JSON. Om JSON kommer från en JSON.parse-rundtrip matchar ordningen källan; programmatiskt byggt styr du ordningen genom att infoga nycklar i önskad sekvens.
Är stora dokument säkra att konvertera i denna flik?
Mellanmegabyte-stora dokument konverteras väl under en sekund. Mycket stora (>10 MB) fungerar men pinnar UI-tråden under parsning; för den lasten, kör samma logik i en Web Worker eller byggtidsskript. Konverteringstjänsten är densamma i båda kontexterna.