De twee modellen komen niet op een rij te staan RFC 8259 definieert zes JSON-typen zonder attributen, terwijl XML 1.0 heeft attributen, naamruimten en geordende gemengde inhoud Deze richting opgaan betekent kiezen wat te doen met het verschil.
De eerste keer dat ik JSON-gegevens naar een systeem moest sturen dat alleen XML sprak, deed ik het naïeve: ik schreef de hoekhaken met de hand in een teksteditor Het was een leveranciersfeed die een SOAP-achtige envelop verwachtte, en mijn bron was een nette JSON-array die uit een Laravel API kwam. Twintig minuten later had ik ergens rond de veertigste plaat een afsluitende tag niet bij elkaar gepast en de ontvangende parser gooide een & quot; stapel na documentelement" fout die me niets vertelde over waarheen ook. Die avond leerde me een les die ik sindsdien op elke integratie heb toegepast: converteren tussen JSON en XML is geen creatieve daad. Het is een mappingprobleem met een klein aantal regels, en op het moment dat je die regels opschrijft, wordt het geheel mechanisch.
Deze gids is de versie van die mapping die ik wou dat I'd had. Ik bouw [Toolz.dev] (/, en een van de tools daar is een browsergebaseerd JSON naar XML converter dat geldt precies de conventies hieronder Maar het punt van dit artikel is niet de knop - it's begrip waarom een sleutel wordt een element, waarom een @-voorgefixeerde sleutel wordt een attribuut, en waarom een array verandert in herhaalde tags in plaats van een genummerde lijst Zodra die drie ideeën klikken, kunt u elke JSON met de hand naar XML converteren als dat nodig is, en u kunt de uitvoer debuggen wanneer een downstream-systeem deze afwijst.
tl;dr: Om JSON naar XML te converteren, wijst u elke objectsleutel toe aan een element
@-voorafgestelde sleutel van een attribuut op het bovenliggende element, en de#textsleutel tot het element' s tekstinhoud Vouw elke array uit in herhaalde broer-zuselementen die de sleutel delen' s naam Ontsnappen&,<, en>in tekst (plus"in attribuutwaarden), en elke sleutel opschonen die is' t een legale XML-naam.Doe het in de browser, zodat payloads met tokens of klantgegevens uw machine nooit verlaten.
Waarom zou je JSON überhaupt naar XML converteren?
JSON won de web API oorlog jaren geleden, en als je je dagen doorbrengt in React, Laravel, of Node, zou je redelijkerwijs kunnen vragen wanneer je ' ooit XML nodig hebt Het antwoord is: constant, gewoon niet op de plaatsen waar je kijkt XML is de lingua franca van een enorme geïnstalleerde basis van systemen die dateren van vóór het JSON-tijdperk en nergens heen gaan SOAP webservices - nog steeds de ruggengraat van bank, verzekeringen, logistiek, en overheidsintegraties - dragen hun payloads in XML. RSS en Atom feeds zijn XML. Sitemaps zijn XML. Android lay-outs, .docx en .xlsx internals (Office Open XML), SVG, RSS podcast feeds, en talloze B2B EDI-stijl uitwisselingen zijn allemaal XML.
Het real-world scenario heeft dus bijna altijd dezelfde vorm: je hebt data volgens JSON omdat dat' s wat uw stapel produceert, en u hebt het nodig volgens XML omdat dat' s wat de andere kant vraagt Misschien duw je ' je productgegevens naar een marktplaats die alleen een XML-feed accepteert Misschien wikkelt u ' een API-antwoord in een SOAP-body in Misschien u ' genereert u een RSS-feed van een JSON-inhoudexport In elk geval, u don' t wilt de serialisatie elke keer opnieuw uitvinden - u wilt een voorspelbare regel die elke JSON-structuur in geldige XML verandert, zodat u deze kunt automatiseren en er niet meer over nadenkt.
There' s ook een rustigere reden: leesbaarheid tijdens het debuggen Wanneer u ' staren naar een diep geneste JSON blob proberen te begrijpen van een hiërarchie, converteren naar ingesprongen XML maakt de boomstructuur soms springen uit, omdat XML' s open/close tags maken nesting expliciet op een manier die JSON ' s braces don' t. Ik houd de JSON naar XML converter en het omgekeerde XML naar JSON-converter open vaker in aangrenzende tabbladen dan I' had geraden.
Hoe kan JSON precies naar XML worden toegewezen?
Hier is de kern ervan Er zijn maar vier regels, en al het andere is een detail.
Regel 1: Objectsleutels worden elementen. Een JSON object { "book": { "title": "..." } } HALD <book><title>...</title></book>. De sleutel is de tagnaam; de waarde is wat erin gaat.
Regel 2: @-voorgefixeerde sleutels worden attributen. XML-elementen kunnen attributen dragen, en JSON heeft er geen eigen concept van, dus we hebben een conventie nodig De veelgebruikte - en degene die mijn tool gebruikt - is een prefix-teken, @ standaard. Dus { "book": { "@id": "bk101", "title": "..." } } HALD <book id="bk101"><title>...</title></book>. Attributen kunnen alleen primitieve waarden bevatten (strings, getallen, booleans), nooit geneste structuren, wat overeenkomt met hoe XML-attributen feitelijk werken.
Regel 3: De #text sleutel wordt tekstinhoud. Wanneer een element nodig heeft allebei attributen en tekst - denk <title lang="en">Hello</title> - dat kun je wel ' t uitdrukken met een gewone tekenreekswaarde, omdat de tekenreeks geen ruimte laat voor het attribuut De conventie is een gereserveerde sleutel, #textpiepsel { "title": { "@lang": "en", "#text": "Hello" } }. Als een element alleen tekst en geen attributen heeft, kunt u overslaan #text en gebruik gewoon een gewone tekenreekswaarde.
Regel 4: Arrays worden herhaalde elementen. Dit is degene die mensen het vaakst fout hebben XML heeft geen array type Een lijst met dingen wordt uitgedrukt als herhaalde sibling elementen met dezelfde tag naam Dus { "tags": { "tag": ["computer", "web"] } } HALD <tags><tag>computer</tag><tag>web</tag></tags> - niet <tag>0</tag> of elke index-gebaseerde onzin. De array's key levert de herhaalde tagnaam.
Zet die samen op een realistisch object en de uitvoer is precies wat een downstream XML-parser verwacht:
{
"catalog": {
"book": [
{ "@id": "bk101", "author": "Gambardella, Matthew", "price": 44.95 },
{ "@id": "bk102", "author": "Ralls, Kim", "price": 5.95 }
]
}
}
HALD
<?xml version="1.0" encoding="UTF-8"?>
<catalog>
<book id="bk101">
<author>Gambardella, Matthew</author>
<price>44.95</price>
</book>
<book id="bk102">
<author>Ralls, Kim</author>
<price>5.95</price>
</book>
</catalog>
Merk op dat de enkele sleutel op het hoogste niveau, catalog, werd het document' s root element Dat' s opzettelijk: een goed opgemaakt XML document moet precies één root hebben Wanneer uw JSON al een enkele wrapping sleutel heeft, die sleutel is de wortel. Wanneer dat het geval is't - wanneer u de converter een object met meerdere toetsen of een kale array overhandigt - wikkelt het gereedschap alles onder een configureerbaar rootelement (root standaard) zodat de uitvoer goed gevormd blijft.
Hoe zit het met ontsnappen en ongeldige namen?
Twee dingen verbreken stilletjes meer conversies dan welke nestbug dan ook: onontsnapte speciale karakters en illegale elementnamen.
Ontsnappen. XML reserveert een handvol tekens Inside element text, &, <, en > moet geschreven worden als &, <, en >. Binnen een dubbel geciteerde attribuutwaarde moet je bovendien ontsnappen aan de dubbele aanhalingstekens als ". Als uw JSON-tekenreeks bevat Tom & Jerry en je zet het in XML raw, het kale ampersand maakt het document verkeerd opgemaakt en de parser sterft Een correcte converter ontsnapt automatisch, dus "a < b & c" HALD a < b & c in de uitvoer en retourzendingen terug naar de originele tekst wanneer deze wordt geparseerd Dit is geen optionele polijst - it' s het verschil tussen geldige en ongeldige XML.
Elementnamen. XML heeft strikte regels over wat een tagnaam mag bevatten Namen kunnen't spaties bevatten, can't beginnen met een cijfer, een koppelteken of een punt, en sluiten de meeste interpunctie uit JSON-sleutels hebben dergelijke beperkingen niet - "first name", "123", en "total($)" zijn allemaal perfect legale JSON sleutels en alle illegale XML namen Een converter die dit negeert levert documenten op die geen enkele parser zal accepteren De pragmatische fix, en wat mijn tool doet, is opschonen: illegale tekens vervangen door onderstrepingstekens en een onderstrepingsteken preppen wanneer een naam begint met een cijfer Dus "123 bad" HALD <_123_bad>. It' is niet glamoureus, maar garandeert de outputparses, wat het hele punt is.
Hoe gebruik ik de browser-based converter?
De workflow aan Toolz.dev/tools/json-to-xml spiegelt de regels hierboven, met een paar opties voor de praktische randgevallen.
Plak je JSON in de invoer en druk op Converteren Als je JSON verkeerd is ingedeeld, krijg je een duidelijke parseerfout in plaats van stille vuilnis - ik leun op de browser' s eigen JSON.parse, dus de foutmeldingen komen overeen met wat u & # 39; d in uw console ziet Kies 2 of 4 inspringingsruimten wanneer u een voor mensen leesbaar document ter beoordeling wilt, of kies Minify om het geheel op één regel in te klappen wanneer u & # 39; verzendt het over de draad en telt elke byte (vooral SOAP-verzoeken en feed-payloads) Stel de naam van het hoofdelement in voor het geval dat uw JSON geen enkele wikkelsleutel heeft Schakel de XML-declaratie in (schakel de XML-declaratie in<?xml version="1.0" encoding="UTF-8"?>) aan of uit afhankelijk van of de consument een prolog verwacht En beslis of lege knooppunten zichzelf moeten sluiten als <tag/> of uitbreiden naar <tag></tag> - sommige strikte consumenten geven erom.
Alles draait client-side De converter is een afhankelijkheid-vrije serializer geschreven in TypeScript, geen wrapper rond een externe API Dat is belangrijker dan het klinkt: API-reacties en configuratiebestanden bevatten routinematig toegangstokens, klantrecords en interne identificatiegegevens, en een & quot; gratis online converter" dat POST uw payload aan iemand ' s server is een datalek die wacht om te gebeuren Omdat deze nooit een netwerkoproep doet, kunt u gevoelige gegevens veilig converteren, en het blijft werken zonder enige verbinding Als privacy in browsertools iets is waar u aan denkt - en als u met andere mensen omgaat' gegevens, zou het moeten zijn - Ik schreef er meer over in de Handleiding voor gegevensprivacytools.
JSON vs XML: een snelle vergelijking
Het helpt om de twee formaten te behouden' afwegingen in zicht, omdat de reden het in kaart brengen heeft conventies nodig zoals @ en #text is dat XML dingen kan uitdrukken JSON can't, en vice versa.
| Aspect | Json | XML |
|---|---|---|
| kenmerken | Geen inheems concept | Eerste klas (<tag attr="v">) |
| Arrays/lijsten | Native [ ] symboliseren |
Herhaalde broer-zuselementen |
| nadere beschouwing | Niet toegestaan | <!-- ... --> ondersteund |
| Naamruimten | niet een | Volledige ondersteuning voor naamruimte |
| Gemengde inhoud (tekst + elementen) | Onhandig | Native |
| Schema/validatie | JSON Schema (add-on) | XSD, DTD, RELAX NG (volwassen) |
| wijdlopigheid | Compact | Meer uitgebreid (sluitende tags) |
| Typisch gebruik vandaag | Web-API's, config | ZEEP, feeds, documenten, onderneming |
de @ voorvoegsel bestaat om de "attributes" rij; de regel met herhaalde tags overbrugt de "arrays" rij; En #text overbrugt de " gemengde inhoud" rij Als u de mapping eenmaal ziet als een brug over deze specifieke gaten, voelt deze niet meer willekeurig.
Is de retourvlucht van JSON naar XML schoon?
Meestal wel - en dat's door ontwerp Mijn JSON naar XML en XML naar JSON tools delen hetzelfde @ attribuutvoorvoegsel en #text inhoudsleutel, dus het converteren van XML → JSON en terug reproduceert over het algemeen het originele document Als u & # 39; bezig bent met het bouwen van een pijplijn die gegevens in beide richtingen moet verplaatsen, is die symmetrie de moeite waard om op te vertrouwen.
Waar round-tripping vaag wordt, is elke JSON/XML-mapping dezelfde plaats als vaag: volgorde en gemengde inhoud JSON-objecten zijn officieel ongeordend, dus een converter behoudt mogelijk niet de exacte volgorde van broers en zussen van elementen met verschillende namen. XML die tekst- en onderliggende elementen interleaft (<p>Hello <b>world</b>!</p>) heeft't een schone JSON-weergave en komt terug als benadering En een element dat soms een keer verschijnt en soms meerdere keren verschijnt is dubbelzinnig - is het een enkele waarde of een array van één? Deze aren't bugs in een bepaald hulpmiddel; ze' zijn inherent aan het feit dat de twee datamodellen elkaar niet perfect overlappen. Als u weet waar de naden zijn, kunt u uw JSON zo ontwerpen dat de conversie verliesvrij blijft: wees consistent over de vraag of iets altijd een array is en vermijd gemengde inhoud waar u maar kunt.
Als je veel met JSON werkt, zal ' Het is de moeite waard om vloeiend te werken in de hele familie van conversies - ik heb de conversies verzameld die ik het meest bereik in de Ultieme gids voor JSON-tools, en het bredere Handleiding voor coderingshulpmiddelen covers waarbij formaatconverters passen in een dagelijkse workflow Voor de omgekeerde richting en aangrenzende formaten geldt de JSON naar YAML-converter en een vlakte JSON-formatter rond de set af.
Veelgemaakte fouten bij het converteren van JSON naar XML
Een paar vallen I' Ik heb anderen geraakt of gezien
Array-indices behandelen als tagnamen. Als je ziet <item0>, <item1> in iemand's uitvoer, hebben ze de converter verkeerd gebouwd Arrays worden herhaald tags met de hetzelfde naam, afkomstig uit de array' s-toets.
Vergeten dat er maar één wortel kan zijn. Het rechtstreeks overhandigen van een object met meerdere toetsen aan een serialisator zonder het in te pakken levert meerdere elementen op het hoogste niveau op, wat geen goed gevormd document is. Wikkel het.
Ontsnappen " omdat de gegevens er schoon uitzien." Het ziet er schoon uit totdat één productbeschrijving een ampersand of een <. Ontsnap altijd; neem nooit aan.
Het plaatsen van gestructureerde gegevens in attributen. Attributen houden primitieven vast Als je een genest object in een @-voorgefixeerde sleutel, een correcte converter zal (en moet) het laten vallen of negeren, omdat er & # 39; geen geldige XML voor is. Modelleer het in plaats daarvan als een onderliggend element.
Geavanceerd: inspringing en aangifte kiezen voor de consument
Eén gewoonte die mij herhaaldelijk heen en weer heeft bespaard bij integratiepartners: match de output juist naar wat de consument verwacht, stop dan Sommige SOAP-eindpunten verwerpen een document dat een byte-ordermarkering of een onverwachte prolog bevat; anderen vereisen de <?xml ... ?> declaratie en 415 u zonder Sommige feed validators willen mooi gedrukte, ingesprongen XML voor hun eigen debugging; de meeste productietransporten willen dat het geminifieerd wordt In plaats van te argumenteren, genereer ik welke variant de spec vraagt Dat' waarom de converter inkeping (inclusief een minify-optie), de declaratie schakelaar, en zelfsluitend gedrag als eersteklas controles blootlegt - zij' zijn geen decoratie, zij' zijn de knoppen die bepalen of een kieskeurige consument uw document bij de eerste poging accepteert.
FAQ
Hoe converteer ik JSON naar XML?
Plak uw JSON in de editor en druk op Convert Objecttoetsen worden XML-elementen, arrays worden herhaalde tags en het resultaat lijkt klaar om te kopiëren of te downloaden Er is geen upload - de conversie vindt plaats in uw browser.
Hoe worden JSON-attributen weergegeven in XML?
Volgens afspraak wordt elke objectsleutel die begint met de "@" voorvoegsel is geschreven als een attribuut op het bovenliggende element in plaats van als een onderliggend element. Bijvoorbeeld {"book": {"@id": "bk101", "title": "..."}} wordt
Hoe gaat de converter om met JSON-arrays?
Elk element van een array wordt uitgezonden als een herhaald broer-zuselement dat de sleutel deelt's naam. Dus {"tags": {"tag": ["a", "b"]}} produceert
Waar is de #tekstsleutel voor?
Wanneer een element zowel attributen als tekstinhoud nodig heeft, wordt de tekst opgeslagen onder de "#tekst" sleutel. {"titel": {"@lang": "en", "#text": "Hallo"}} wordt
Kan ik minified xml krijgen in plaats van ingesprongen uitvoer?
Ja. Stel de inspringing in op 0 (minify) en de converter zendt het hele document uit op een enkele regel zonder witruimte tussen tags. Dit is handig voor SOAP-verzoeken of feeds waar de grootte van het laadvermogen van belang is; schakel terug naar 2 of 4 spaties wanneer u een leesbaar document nodig heeft.
Wat gebeurt er met sleutels die geen geldige XML-elementnamen zijn?
XML-elementnamen kunnen geen spaties bevatten, kunnen niet beginnen met een cijfer, koppelteken of punt, en sluiten de meeste interpunctie uit Sleutels die deze regels overtreden worden opgeschoond - ongeldige tekens worden onderstrepingstekens en er wordt een leidend onderstrepingsteken toegevoegd wanneer dat nodig is - dus de uitvoer parseert altijd, zelfs als uw JSON-sleutels niet XML-vriendelijk waren.
Gaat JSON naar XML-rondreis met de XML naar JSON-tool?
Voor de gangbare structuren doet het Dit hulpmiddel en het XML naar JSON hulpmiddel delen dezelfde & quot;@" attribuutvoorvoegsel en & quot;#text" content key, dus het converteren van XML naar JSON en terug reproduceert over het algemeen hetzelfde document Order-onafhankelijke details en gemengde inhoud zijn de gebruikelijke bronnen van kleine verschillen, zoals ze zijn met elke XML/JSON mapping.
Is het veilig om gevoelige JSON hier te converteren?
Ja. De converter is gewoon JavaScript dat volledig in uw browser draait - niets dat u plakt wordt naar een server verzonden, gelogd of opgeslagen Dat maakt het veilig voor API-reacties, configuratiebestanden en records die tokens of persoonlijke gegevens bevatten, en het blijft werken zonder netwerkverbinding.
