De eerste keer dat XML mijn middag bijna verpestte, was het een SOAP-reactie van een betalingsgateway Eén regel Elfduizend tekens Geen nieuwe regels, geen inspringing, alleen een ononderbroken wand van hoekbeugels die mijn terminal in een onleesbare steen wikkelde Ergens in zat een enkel verkeerd element dat een kenmerkende mismatch veroorzaakte, en ik moest het met het oog vinden Ik heb sindsdien genoeg dingen gebouwd - WordPress plugins, Laravel API's, de React tooling achter [Toolz.dev] (/ - en ik kan je vertellen dat een goede XML-formatter een van die stille hulpprogramma's is die je niet waardeert tot het moment dat je met een deadline achter je aan een muur van tags staart.
Deze gids is degene die ik die middag wou hebben Het behandelt wat een XML-formatter eigenlijk doet, waarom verfraaien en minificeren twee kanten van dezelfde medaille zijn, de witruimte regel die formatteren veilig maakt, en het handjevol validatiefouten die bijna elke & quot; waarom won't deze parse" moment U kunt in de browser meegaan met de gratis XML-formatter - het draait volledig op uw machine, dus zelfs een betaallading verlaat uw laptop nooit.
tl;dr: Een XML-formatter herschrijft een document's onbeduidende witruimte - de ruimte er tussen in tags - zonder de betekenis ervan aan te raken Verfraaiing voegt regeleindes en inspringing toe zodat u de hiërarchie kunt lezen; minify stript het allemaal zodat het bestand zo klein mogelijk is Een goede opmaakmaker bewaart opmerkingen, CDATA, de XML-declaratie en attribuutvolgorde, en valideert onderweg goed gevormdheid (matching tags, gesloten elementen, beëindigde secties).Het doet nee controleer uw document aan de hand van een DTD- of XSD-schema - dat is een andere taak.
Wat doet een XML-formatter eigenlijk?
Whitespace is waar formatteren interessant wordt, omdat XML 1.0 vereist een parser om elk teken binnen een element door te geven aan de applicatie - daarom moet een formatter weten wat veilig is om aan te raken. In de kern parseert een XML-formatter uw document in een boom van knooppunten - elementen, tekst, opmerkingen, CDATA-secties, verwerkingsinstructies - en serialiseert die boom vervolgens weer met consistente afstand. Die heen- en terugreis is de hele truc. Omdat de tool de structuur begrijpt in plaats van een blinde zoek-en-vervanging uit te voeren, kan deze een diep geneste indruk maken <order><items><item> keten correct, plaats elke broer of zus op zijn eigen lijn en weet dat de tekst erin staat <price>44.95</price> moet op dezelfde lijn blijven als de tags, in plaats van zich over drie uit te strekken.
De reden dat dit ertoe doet, komt neer op een regel die begraven ligt in de XML-specificatie: het grootste deel van de witruimte tussen elementen is dat wel onbeduidend. Wanneer een parser leest <a>\n <b/>\n</a>, de nieuwe lijnen en ruimtes eromheen <b/> zijn er voor mensen en dragen geen gegevens Een formatter is toegestaan om toe te voegen, te verwijderen, of te veranderen die witruimte vrij Wat het nooit mag aanraken is significant witruimte - de tekens in een tekstknooppunt zoals <note>Call me at 9am</note>, of iets binnen een CDATA-blok - omdat die inhoud echte gegevens zijn Elke opmaakbeslissing de XML-formatter zorgt ervoor dat er geen respect meer is voor die lijn.
Verfraaien is dus geen cosmetisch pluisje Als je die elfduizend-karakter SOAP-steen opnieuw inspringt, wordt de elementenhiërarchie zichtbaar, en plotseling de misplaatste <Amount> knooppunt drie niveaus te diep is duidelijk Formatteren is zowel een foutopsporingstool als een leesbaarheidstool.
Waarom zou ik XML minifiëren in plaats van verfraaien?
Verfraaien en minificeren zijn dezelfde motor die in tegengestelde richtingen wijst. Verfraaien voegt witruimte toe voor mensen; minify verwijdert het voor machines. Je reikt naar minify wanneer grootte of transport ertoe doet: een configuratiebestand verkleinen dat in een mobiele app-bundel wordt verzonden, een verzoektekst bijsnijden voordat deze over een langzame verbinding gaat, of een document normaliseren zodat twee versies byte voor byte kunnen worden vergeleken zonder dat inkepingsruis in de weg staat.
De besparing is reëel maar zelden dramatisch. XML' De breedsprakigheid leeft in de herhaalde tagnamen, niet in de witruimte, dus minifying ligt doorgaans ergens tussen de vijf en twintig procent, afhankelijk van hoe zwaar ingesprongen het origineel was. Dat is de moeite waard, maar als je serieuze compressie nodig hebt, doet gzip op de draad veel meer: minifying en vervolgens gzipping is de riem-en-beugels die veel API's gebruiken.
Hier is het mentale model dat ik gebruik bij het beslissen welke kant ik op moet wijzen
| betrekking | mooi maken | klein worden |
|---|---|---|
| Een reactie met het oog lezen of debuggen | ja | heel weinig |
| Een configuratiebestand aan versiebeheer koppelen | Ja (schone diffs) | heel weinig |
| Verzending van XML binnen een app-bundel of via het netwerk | heel weinig | ja |
| Het opslaan van veel kleine documenten in een databasekolom | heel weinig | ja |
| Het voorbereiden van een document voor een byte-voor-byte diff | Ofwel, consequent | Ofwel, consequent |
| XML overhandigen aan een andere ontwikkelaar | ja | heel weinig |
De belangrijkste discipline is consistentie. Als u twee documenten verspreidt, voer dan uit allebei via dezelfde modus met eerst dezelfde opties - anders vergelijk je inspringstijlen, geen inhoud.
Hoe voorkomt formatteren dat mijn gegevens worden gewijzigd?
Dit is de angst die elke formatter heeft om zijn weg te vinden: " Als deze tool mijn XML herschrijft, hoe weet ik dan dat het niet stilletjes iets heeft verbroken?" Het eerlijke antwoord is dat een goed gebouwde formatter alleen ooit de witruimte tussen tags verandert en vier dingen strikt met rust laat.
De eerste is tekstinhoud. De tekens in een element worden woordelijk gekopieerd. Dat omvat entiteiten - een letterlijke & blijft &, het is nooit nuttig gedecodeerd & (wat ongeldige XML zou produceren) of dubbel gecodeerd naar &amp;. de XML-formatter behandelt uw tekst als ondoorzichtig, en dat is precies wat u wilt.
De tweede is CDATA-secties. a <![CDATA[ ... ]]> blok bestaat precies zodat u onbewerkte, onontsnapte inhoud kunt laten vallen: een fragment van JavaScript, een stuk HTML, een reeks vol met < en & - in een XML-document zonder eraan te ontsnappen Een opmaakblok zendt die inhoud precies uit zoals het die heeft gevonden, geen ontsnapping, geen herinschrijving in het blok.
De derde is opmerkingen en de verklaring. Opmerkingen (<!-- ... -->), de <?xml version="1.0"?> declaratie, en eventuele verwerkingsinstructies worden bewaard en verstandig geplaatst U kunt ervoor kiezen om opmerkingen te verwijderen wanneer u een slanker bestand wilt, maar dat is uw beslissing, niet iets wat de tool achter uw rug doet.
De vierde is attribuutvolgorde en citaat. Standaard houdt de opmaakster uw attributen in de volgorde waarin u ze hebt geschreven, met de quote-stijl die u hebt gebruikt, omdat de XML-specificatie de attribuutvolgorde als onbeduidend beschouwt en er geen reden is om deze te churnen Wanneer u beginnen te beginnen wil een canonieke ordening - voor schonere diffs, of om twee elementen te vergelijken die dezelfde attributen in verschillende volgordes dragen - een "sort attributen" optie zet ze in alfabetische volgorde voor u.
Omdat dit alles aan de clientzijde in JavaScript draait, is er ook een privacydividend: een document vol verbindingsreeksen, interne identificatiegegevens of klantgegevens wordt op uw eigen machine opgemaakt en nooit geüpload. Als het je interesseert om werkgegevens van andere mensen af te houden's servers - en dat zou je moeten doen - is dat model de moeite waard om te begrijpen, en ik heb er meer over geschreven in de gegevensprivacygids voor online tools.
Welke XML fouten vangt de formatter op?
Voordat een formatter iets mooi kan afdrukken, moet hij het document parseren, en bij het parseren vindt de nuttige validatie plaats. Dit is goed gevormdheid controleren - de structurele regels waaraan elk XML-document moet voldoen - en naar mijn ervaring zijn drie fouten verantwoordelijk voor de overgrote meerderheid van de mislukkingen.
De meest voorkomende is veruit een blote ampersand. XML-reserves & om een entiteit te starten, dus een raw & in tekst - het soort dat binnensluipt via een URL zoals ?a=1&b=2 of een bedrijfsnaam zoals " Marks & amp; Spencer" - laat de parser een entiteitsnaam verwachten en dan stikken als hij er geen vindt De oplossing is schrijven &, en een goede foutmelding zal u op de lijn wijzen, zodat u niet blind jaagt.
De tweede is een niet-overeenkomende of niet-gesloten tag. Open een <div> en sluit het af met </section>, of open een <span> en sluit het helemaal nooit, en het document is niet meer goed gevormd De formatter volgt de open-element stack terwijl deze parseert, zodat het u precies kan vertellen welke tag het verwachtte gesloten te zien en welke het daadwerkelijk gevonden heeft Dat ene bericht - & quot; verwachtte </book> maar gevonden </author> op regel 14" - is meestal genoeg om het probleem in seconden op te lossen.
De derde is een niet-beëindigde sectie: een reactie geopend met <!-- dat bereikt nooit -->, of een CDATA-blok dat nooit bereikt ]]>. Deze zijn gemakkelijk te maken wanneer u met de hand aan het bewerken bent en iets te veel verwijdert. Nogmaals, de opmaakmachine rapporteert de regel waar het weggelopen gedeelte begon.
Wat de opmaakster doet nee do is uw document controleren aan de hand van een schema Goed gevormdheid vraagt & quot; is dit structureel geldige XML?" Geldigheid vraagt " volgt deze XML de regels van mijn bijzonder documenttype - de juiste elementen, in de juiste volgorde, met de juiste gegevenstypen - zoals gedefinieerd door een DTD of XSD?" Dat zijn afzonderlijke lagen Een document kan perfect goed gevormd zijn en toch onzin zijn voor het beoogde doel Schemavalidatie heeft het schema nodig, en dat is een ander hulpmiddel De formatter garandeert de eerste laag, die ervoor zorgt dat uw parser niet crasht.
Hoe formatteer ik XML in mijn editor of bouw ik pijplijn?
De browsertool is het snelste pad voor een eenmalig document, maar het is de moeite waard om de alternatieven te kennen, zodat u de juiste voor de taak kunt kiezen.
De meeste editors formatteren XML native In VS Code, de ingebouwde & quot; Format Document" opdracht (Shift+Alt+F) verwerkt XML, en extensies zoals Red Hat' s XML taalserver toevoegen schema-bewuste opmaak bovenop IntelliJ en zijn broers en zussen opnieuw formatteren met Ctrl+Alt+L. Deze zijn ideaal wanneer het bestand al voor je open is.
Op de commandoregel, xmllint --format file.xml (onderdeel van libxml2, dat op de meeste Unix-systemen wordt geleverd) verfraait, en xmllint --noblanks file.xml brengt u dicht bij de geminificeerde uitvoer In een knooppuntproject, bibliotheken zoals xml-formatter of prettier met de XML-plugin sleuf in een build stap Python ontwikkelaars reiken naar xml.dom.minidom.parseString(s).toprettyxml(), hoewel u gewaarschuwd bent dat het berucht is vanwege het toevoegen van extra lege regels rond de bestaande witruimte.
Dus waarom de XML-formatter helemaal niet? Drie redenen waar ik steeds op terugkom. Er is geen installatie, geen configuratie en geen project nodig - je plakt en gaat. Het bewaart de gegevens op je machine, wat belangrijk is wanneer de XML een echte lading is in plaats van een speelgoedvoorbeeld. En het past op natuurlijke wijze bij de aangrenzende tools: zodra uw XML schoon en geldig is, converteert u deze naar JSON met de XML naar JSON-converter is één klik, en de omgekeerde trip door JSON naar XML gebruikt dezelfde conventies Als je dag meestal JSON is, is de JSON-formatter is het equivalent voor dat formaat, en de hele familie is gecatalogiseerd in de Webontwikkelaar Toolkit.
Wanneer moet ik mijn XML formatteren versus converteren?
Een vraag die ik van mensen nieuwer krijg om dit: als JSON gemakkelijker te lezen is, waarom XML formatteren in plaats van alleen converteren? het antwoord is dat formatteren en converteren verschillende problemen oplossen.
Opmaak wanneer dat nodig is houden de XML - omdat een SOAP-eindpunt dit vereist, omdat een RSS- of Atom-feed per definitie XML is, omdat uw configuratiebestand, uw Android-indeling of uw Maven pom.xml gewoon XML is en altijd zal zijn Formatteren maakt die XML leesbaar of compact terwijl het als XML blijft Er hoeft niets stroomafwaarts te veranderen.
Converteren wanneer u wilt werk met de gegevens in een ander formaat - waarden in een JavaScript-front-end trekken, een feed laden in een systeem dat JSON spreekt, of verschillende bronnen in één vorm normaliseren Conversie verandert het formaat, en daarmee een deel van de betrouwbaarheid: XML-attributen, gemengde inhoud en elementvolgorde hebben geen schone JSON-equivalenten, dus een converter maakt weloverwogen keuzes (attributen worden vooraf ingestelde sleutels, herhaalde tags worden arrays) die u moet begrijpen voordat u erop vertrouwt.
Mijn vuistregel: eerst opmaken, altijd Een schoon, gevalideerd document is gemakkelijker te redeneren over de vraag of uw volgende stap het bewerken, verspreiden of converteren is. Opmaak is de goedkope, veilige, verliesvrije bewerking; conversie is de verliesgevende die u doet als u eenmaal weet dat de structuur gezond is. Sitemaps zijn een mooi voorbeeld van XML dat u eerder formatteert dan converteert - als u er een bouwt, de speciale sitemap generator produceert geldige, goed gevormde output direct.
Veelgestelde vragen
Hoe formatteer ik XML online?
Plak uw XML in het invoerpaneel, kies Verfraaiing, kies een inspringingsbreedte en klik op Format. Het tool parseert het document, herinkt het opnieuw en laat u het resultaat kopiëren of downloaden. Alle verwerking gebeurt in uw browser - er wordt niets geüpload.
Wat is het verschil tussen het verfraaien en verkleinen van XML?
Verfraaien voegt regeleindes en inspringing toe zodat de elementenhiërarchie gemakkelijk te lezen is, wat ideaal is voor bewerken en debuggen Minifying verwijdert alle witruimte tussen tags om een zo klein mogelijk bestand te produceren, wat ideaal is voor opslag of verzending via het netwerk. Beiden behouden het document's betekenis; alleen de onbeduidende witruimte verandert.
Verandert het formatteren de betekenis van mijn XML?
heel weinig . Alleen de witruimte tussen tags is gewijzigd - de elementen, attributen, tekstinhoud, opmerkingen en CData zijn ongewijzigd. Omdat er in tekstknooppunten en CDATA significante witruimte wordt bewaard, gedraagt een goed gevormd document zich voor en na het opmaken identiek.
Zijn opmerkingen en cData-secties bewaard gebleven?
Ja Opmerkingen, CDATA-secties, de XML-declaratie en verwerkingsinstructies worden allemaal bewaard Opmerkingen zijn ingesprongen naast de elementen waarmee ze zitten, en CDATA-inhoud wordt woordelijk uitgezonden zonder enige ontsnapping. U kunt er ook voor kiezen om opmerkingen te verwijderen als u een slankere uitvoer wilt.
Kan deze tool mijn XML valideren?
Ja. Voordat het document wordt geformatteerd, wordt het document volledig geparseerd en structurele problemen - een niet-gesloten element, een afsluitende tag die niet overeenkomt met de openingstag, of een niet-uitgesloten commentaar- of CDATA-sectie - worden gerapporteerd met een regelnummer, zodat u ze snel kunt repareren. Het controleert goed gevormde, geen geldigheid tegen een DTD- of XSD-schema.
Waarom kan mijn XML niet formatteren?
Bijna alle storingen zijn goedvormingsfouten De meest voorkomende zijn een kale ampersand in tekst (het moet geschreven zijn als een entiteit, of de parser leest het als het begin van een entiteit), een afsluitende tag die niet overeenkomt met het element dat het sluit, en een element dat geopend maar nooit gesloten wordt De foutmelding wijst op de lijn zodat je er recht op kunt springen.
Is het veilig om XML te formatteren die gevoelige gegevens bevat?
Ja. De parser draait volledig in JavaScript in uw browser - geen enkele netwerkaanvraag draagt uw gegevens, niets wordt gelogd of opgeslagen en de tool werkt offline na het laden. XML-API-sleutels, verbindingsreeksen of klantrecords verlaat uw machine nooit.
Kan ik de geformatteerde XML achteraf naar JSON converteren?
Ja. Zodra de XML schoon en geldig is, verandert de XML naar JSON Converter het in gelijkwaardige JSON, waarbij attributen worden toegewezen aan vooraf gefixeerde sleutels en herhaalde tags aan arrays. Eerst formatteren maakt de structuur duidelijk, waardoor u begrijpt hoe deze zal worden toegewezen voordat u deze converteert.
Geschreven door Liton - bouwer van Toolz.dev, WP Adminify, en een lange lijst van Laravel en React projecten Elke tool die hier wordt genoemd draait gratis en volledig in uw browser op [Toolz.dev] (/.
