§

Bemenet

Mód
§

Kimenet

Az USA-ban és az Egyesült Királyságban dolgozó csapatok minden nap áthidalják az XML-t és a JSON-t, általában azért, mert a stack két fele nem ért egyet abban, hogy melyik formátumot használják. Az Egyesült Államok Egészségügyi Minisztériuma HL7 FHIR erőforrásokat tesz közzé XML-ben és JSON-ban is a 45 CFR Part 170 alatt. Az NHS Digital FHIR XML-t ír elő a GP Connect számára és FHIR JSON-t az NHS bejelentkezéshez. A JPMorgan és a Bank of America SOAP szolgáltatásai továbbra is XML borítékokat adnak vissza, amelyeket a React front-end-ek JSON-ként szeretnének. Az olyan brit biztosítók, mint az Aviva és a Legal & General, ugyanazt a formátumot szállítják. Az adatoldalon az AWS SNS és SQS törzsek, az USPS szállítási jegyzékek és a Companies House bejelentések XML-ben érkeznek, amelyet a mérnökök JSON-ba alakítanak, mielőtt az Snowflake-be vagy BigQuery-be kerülne. A megoldás minden esetben ugyanaz: egy gyors, helyi konverter, amelyet újrafuttathat egy friss adattartalmon anélkül, hogy bárhová elküldené.

Mi az az XML ↔ JSON konverzió?

XML (Extensible Markup Language) egy tag-alapú szöveges formátum hierarchikus adatokhoz. Találkozhat vele SOAP webszolgáltatásokban, RSS és Atom hírcsatornákban, HL7 FHIR egészségügyi rekordokban, sitemap.xml fájlokban és a Maven, Spring és Android Gradle fájljaiban. JSON (JavaScript Object Notation, RFC 8259 által definiálva) ugyanazt a fajta beágyazott adatot írja le, de kapcsos zárójelekkel és tömbökkel a nyitó- és zárótag-ek helyett. A JSON-t beszéli ma szinte minden REST API, és ez a böngésző minden futásidejű környezetének natív érték formája. A két formátum közötti konvertálás azok közé a feladatok közé tartozik, amelyek triviálisnak tűnnek, amíg nem találkozik attribútumokkal, vegyes tartalommal, ismétlődő gyermekekkel és CDATA-val. Egy egyéni regex a rossz válasz; egy valódi elemző a helyes. Ez az eszköz egy valódi elemzőt (fast-xml-parser) használ, és a böngészőjében fut, így beilleszthet egy XML borítékot, amelyet egy örökölt SOAP szolgáltatás adott vissza, és láthatja, ahogy JSON objektummá válik, amelyet betölthet egy Redux tárolóba, vagy vehet egy JSON adattartalmat, amelyet egy REST kliensben állított össze, és visszaalakíthatja XML formába, amelyet egy vállalati végpont még mindig elvár.

Hogyan működik az XML ↔ JSON leképezés?

Minden konverzió helyben fut a böngészőjében a beépített fast-xml-parser könyvtár használatával (MIT, 4.x verzió). A magas szintű leképezési szabályok:

  1. Elem kulcsra: minden XML elem neve JSON objektum kulccsá válik. <user><name>Alice</name></user>{"user":{"name":"Alice"}}.
  2. Attribútum előtaggal ellátott kulcsra: egy attribútum egy olyan kulcs alatt tárolódik, amely a választott előtag hozzáadásával jön létre. @ előtaggal a <user id="1"> {"user":{"@id":"1"}}-t eredményez.
  3. Szöveges tartalom szöveges csomópont kulcsra: ha egy elemnek attribútumai és szövege is van, a szöveg a választott szöveges csomópont kulcs alá kerül. <price currency="USD">9.99</price> a #text kulccsal {"price":{"@currency":"USD","#text":"9.99"}}.
  4. Ismétlődő gyermekek tömbre: amikor Tömb kényszerítése ismétlődő gyermek tag-ekhez be van kapcsolva, a többszörös, azonos nevű testvér elemek egy JSON tömbben egyesülnek. <items><item>A</item><item>B</item></items>{"items":{"item":["A","B"]}}.
  5. CDATA szekciók: a <![CDATA[…]]>-n belüli nyers szöveg a #cdata kulcs alatt marad meg, így a szögletes zárójelek és az & jelek nem kerülnek újra escape-elésre a körút során.
  6. JSON → XML visszafelé fordítja a leképezést: az objektum kulcsok elemekké, az előtaggal ellátott kulcsok attribútumokká válnak, a tömbök pedig ismétlődő testvér elemekké bővülnek.

Miért konvertáljon XML-t és JSON-t ezzel az eszközzel?

  • Az adatai az Ön gépén maradnak. Minden elemzés és építés ezen oldal JavaScript kontextusában fut. FHIR betegcsomagok, SOAP hitelesítési borítékok, védett konfigurációs fájlok, számlázási exportok — semmi sem éri el a szervereinket, mert nincs feltöltési lépés a kód útvonalában. Nyissa meg a hálózati panelt és figyelje.
  • Az örökölt SOAP egy REST-first front-end-be a leggyakoribb kérés, amit hallunk. Egy bank vagy biztosító olyan SOAP végpontot tesz elérhetővé, amelyet évekig nem fognak kivonni; a React vagy Vue alkalmazás, amely hívja, nem akar megtanulni XML-t. Illessze be a borítékot, kapja vissza a JSON-t előtagolt attribútumokkal és megőrzött névterekkel, töltse be a Body tartalmat az állapot tárolójába.
  • Az RSS, Atom és sitemap fogyasztók is profitálnak belőle. Egy podcast könyvtár, egy hírolvasó vagy egy belső irányítópult, amely sitemap.xml-et dolgoz fel, kihagyhatja az XML elemző írását. Konvertálja a hírcsatornát egyszer, dolgozzon a JSON tömbbel, és a kliens kódja abban a nyelvben marad, amelyet már beszél.
  • A konfigurációs export teszi teljessé a listát. A Maven, Spring, Android Gradle és a régi iskolás Ant build-ek XML-t állítanak elő; a másik oldali felhő-natív eszközök (Terraform, Ansible, GitHub Actions, cloud-init) JSON-t vagy YAML-t olvasnak. Konvertáljon a böngészőben ahelyett, hogy egy Python parancsfájlt futtatna egy harmadik féltől származó függőséggel, különösen hasznos légmentes környezetekben, ahol egy ismeretlen webszolgáltatásba történő beillesztés nem opció.

Mik az XML ↔ JSON konverzió gyakori alkalmazásai?

Az XML és JSON áthidalása az integrációs mérnöki, API eszköztári és adatmérnöki munkában merül fel. Néhány minta uralja a munkaterhelést:

  • SOAP-REST áthidalás: a Body adattartalom kihúzása egy SOAP borítékból, amelyet egy örökölt banki vagy biztosítási API adott vissza, és JSON-ba konvertálása, hogy egy React vagy Vue front-end fel tudja használni anélkül, hogy egy kiszolgáló oldali proxy rétegre lenne szükség előtte.
  • FHIR egészségügyi rekordok: HL7 FHIR XML csomagok (a HHS/ONC és NHS Digital által előírt formátum a klinikai adatcseréhez) konvertálása JSON-ba egy MongoDB Atlas gyűjteménybe vagy egy PostgreSQL JSONB oszlopba történő betöltéshez, ahol az elemzők lekérdezhetik őket.
  • Sitemap és hírcsatorna feldolgozás: egy sitemap.xml vagy RSS/Atom hírcsatorna JSON tömbbé alakítása, hogy egy egyedi indexelő, egy Slack bot vagy egy irányítópult widget végig tudjon iterálni a bejegyzéseken anélkül, hogy egy XML elemzőt kellene függőségként behúznia.

Hogyan néz ki egy XML ↔ JSON körút?

Vegyünk egy kis példát. Illessze be a <user id="1"><name>Alice</name></user>-et a bemenetbe, állítsa az attribútum előtagot @-ra, hagyja a módot XML → JSON-on, és nyomja meg a Konvertálás gombot. A kimenet: {"user":{"@id":"1","name":"Alice"}}. Váltsa a módot JSON → XML-re, illessze be vissza a JSON-t, állítsa a behúzást 2 szóközre, és nyomja meg újra a Konvertálás gombot. A következőt kapja: <user id="1"> <name>Alice</name> </user>, szerkezetileg azonos az eredetivel. Az egyetlen dolog, ami nem garantált a körút során, az az attribútumok sorrendje, mert a JSON objektum kulcsok specifikáció szerint rendezetlenek.

Ez az XML ↔ JSON konverter a fast-xml-parser@4-et tartalmazza, ugyanarról az eredetről csomagolva, kezeli az attribútumokat, a CDATA-t, az ismétlődő gyermek tageket és a névtér előtagokat, és offline is működik, miután az oldal betöltődött. Nincs feltöltési lépés, nincs CDN proxy, nincs analitikai beacon, nincs telemetria. Minden bemeneti és kimeneti bájt a böngészőjében marad, ami pontosan az, amit akkor szeretne, ha az adattartalom történetesen egy FHIR betegcsomag, egy SOAP hitelesítési boríték vagy bármilyen más adatforma, amelyet senkinek sem szabad látnia a csapatán kívül.