Converteer XML gratis online naar Markdown

XML naar Markdown omzetten: tags eruit, hiërarchie erin

XML heeft een gewoonte die geen enkel ander formaat deelt: het schrijft de naam van elk element twee keer op. Eén keer om te openen, één keer om te sluiten. Tel er namespace-prefixen bij op, plus attributen, plus de inspringing die het leesbaar maakt, en je eindigt geregeld met een bestand waarin de tags zwaarder wegen dan de inhoud die ze omhullen. Een productcatalogus met 200 items kan duizenden regels beslaan en toch maar zo'n anderhalve pagina echte informatie bevatten.

XML naar Markdown converteren behoudt de boom en schrapt het ceremonieel. Elementnesting wordt kopniveaus, herhalende siblings worden lijsten of tabellen, en de punthaken verdwijnen. Upload hierboven een .xml-bestand en je krijgt het binnen een paar seconden terug — gratis, geen account nodig, plafond van 50 MB, er wordt niets bewaard.

Wat er van de elementboom wordt

De conversie loopt door het document en vertaalt elke constructie:

• Container-elementen worden koppen. Een element met kindelementen maar zonder eigen tekst is een sectie. Zijn diepte in de boom bepaalt het kopniveau, dus een vijf lagen diep enterprise-schema komt binnen als een keurig ingedeeld document.
• Leaf-elementen worden gelabelde waarden. <author>Ursula Le Guin</author> lees je als author: Ursula Le Guin. Eén naam in plaats van twee, geen haken.
• Herhalende siblings worden lijsten of tabellen — daarover hieronder meer, want daar zit de meeste winst.
• Mixed content blijft inline behouden. Dat is het geval waarin tekst en kindelementen door elkaar staan, zoals in <para>Zie de <ref>bijlage</ref> voor details</para>. Naïeve converters hakken dat in brokstukken en je verliest de zin. Het hoort er als één leesbare regel door te komen, met de verwijzing intact.
• Comments, processing instructions en de XML-declaratie gaan eruit. Geen van alle zijn ze inhoud.

Attributen: het deel dat mensen kwijtraken zonder het te merken

XML bewaart gegevens op twee plekken — tussen de tags, en erbinnen. Elementtekst is vanzelfsprekend. Attributen zie je makkelijk over het hoofd, en veel naïeve extractie laat ze stilletjes vallen. Dat is prima als het metadata is zoals id="4471". Het is een ramp als ze de payload zijn.

En dat komt vaak voor. <price currency="GBP">49.99</price> is betekenisloos zonder de valuta. Configuratieformaten zijn nog erger — Maven, Ant, Spring, Android-manifesten en .NET-app.config-bestanden stoppen vaak vrijwel alles in attributen, dus een extractie die alleen elementtekst pakt levert daar een document op dat structureel klopt en vrijwel volledig leeg is. Converteer je een configbestand en ziet de uitvoer er verdacht kort uit, dan is dit waarom.

In de Markdown-uitvoer horen attributen naast het element te staan waar ze bij horen, niet te verdwijnen — weergegeven als korte toevoeging naast de waarde, of als extra kolommen wanneer het element deel uitmaakt van een herhalende set. Controleer het eerste scherm uitvoer tegen de bron voordat je er iets belangrijks aan toevertrouwt. Tien seconden scannen verslaat een verward gesprek met een model later.

Herhalende siblings worden tabellen

De gunstigste vorm van XML is een parent met veel identieke kinderen: <item>-elementen in een RSS-feed, <row>-elementen in een database-export, <employee>-records in een HR-dump. Elk kind heeft dezelfde sub-elementen in dezelfde volgorde.

Dat klapt samen tot één Markdown-pipetabel. Namen van sub-elementen worden kolomkoppen, elk record wordt een rij, en de tagherhaling — die in het ruwe bestand betekende dat elke veldnaam twee keer per record werd uitgeschreven — gebeurt precies één keer, in de kop. Het is de grootste besparing die je bij welke XML-conversie dan ook zult zien, en dé reden om voor alles wat record-vormig is Markdown boven platte tekst te kiezen.

Het gaat mis als records rafelig zijn — optionele elementen die bij sommige kinderen wel en bij andere niet aanwezig zijn, of één kind met een genest blok dat de andere niet hebben. Dan krijg je gaten, of het geneste deel wordt onder de tabel geduwd. Is je data echt rechthoekig, exporteer dan naar CSV en gebruik de CSV naar Markdown converter voor schonere tabellen. En is de bron JSON-vormig in plaats van tag-vormig, dan pakt de JSON naar Markdown converter hetzelfde probleem van de andere kant aan.

Namespaces, envelopes en enterprise-ruis

XML uit de praktijk is zelden schoon. Drie dingen blazen het op tot ver voorbij de informatie die erin zit:

• Namespaces. xmlns-declaraties en prefixen zoals soap:, xsi:, atom: of dc: bestaan om naambotsingen tussen vocabulaires te voorkomen. Voor een lezer betekenen ze niets. Prefixen worden bij de conversie gestript, dus <dc:creator> lees je als creator. Het enige moment om erop te letten is wanneer twee namespaces echt dezelfde lokale naam voor verschillende dingen gebruiken — zeldzaam, maar controleer het als je vocabulaires samenvoegt.
• SOAP-envelopes. Een webservice-response wikkelt het deel dat je wilt in Envelope en Body, vaak plus headers vol security tokens en routeringsdata. Na conversie heb je een document waarin de payload eindelijk zichtbaar is in plaats van vier niveaus diep begraven onder boilerplate die je in je hoofd moet overslaan.
• Schemaverwijzingen. xsi:schemaLocation, DTD-declaraties en validatie-attributen beschrijven hoe het bestand gecontroleerd moet worden, niet wat erin staat. Voor elk doel hier: ruis.

RSS- en Atom-feeds zitten aan de vriendelijke kant van dit spectrum. Ze zijn uniform, ondiep, en converteren naar een schone lijst gedateerde items — een prima manier om een model een maand aan blogposts te geven. Let wel: feed-beschrijvingen bevatten meestal HTML die ge-escaped in de XML zit, en die komt als markup in je uitvoer terecht; haal die door de HTML naar Markdown converter als je het schoon wilt, of gebruik Web2Txt om de pagina's fatsoenlijk op te halen.

Wanneer je de ruwe XML moet houden

Een eerlijk antwoord, want genoeg pagina's die converters verkopen geven je er geen: modellen lezen XML prima. Het is breedsprakig, maar ondubbelzinnig en extreem goed vertegenwoordigd in trainingsdata. Converteren is een keuze, geen vereiste.

Houd het ruw als je vraagt om XPath-expressies, een XSLT-stylesheet, een parser of een schema — alles waarbij het model exacte elementnamen, namespace-prefixen en het onderscheid tussen attribuut en element moet reproduceren. Markdown strijkt juist die details bewust glad. Plak dan liever een representatief fragment van het echte bestand.

Converteer als een mens het moet lezen, als je snel een onbekend schema wilt doorgronden, of als het ruwe bestand grotendeels uit tags bestaat en je krap in je context zit. Dat zijn echte winstpunten. Al het andere is smaak.

De XML waarvan je niet wist dat het XML was

Een flink aantal formaten die je als binair beschouwt is onderhuids gezipte XML. Hernoem een .docx naar .zip, pak hem uit, en je vindt document.xml plus een stapel relationship-bestanden. EPUB is hetzelfde verhaal: XHTML-inhoudsdocumenten en een XML-pakketmanifest in een zip. Dat geldt ook voor .pptx, en ook voor .xlsx.

Je zou er een kunnen unzippen en de XML met de hand converteren. Doe het niet — de interne markup staat vol stijlruns, wijzigingsregistratie en lay-outinstructies die de tekst overspoelen. Gebruik Word naar Markdown of EPUB naar Markdown, die weten welke delen van die XML inhoud zijn en welke opmaakinstructies. Deze pagina is voor XML die je als XML kreeg aangereikt: feeds, exports, API-responses, config, gegevensuitwisseling.

Veelgestelde vragen

Hoe converteer ik XML naar Markdown?

Upload de .xml hierboven en de documentstructuur wordt op Markdown afgebeeld — elementhiërarchie wordt kopniveaus, herhaalde sibling-elementen worden lijsten of tabellen. Gratis, 50 MB per bestand, geen account nodig. Het behoudt de vorm van het document, en dat is het verschil met platslaan naar tekst.

Wordt de elementhiërarchie omgezet in kopniveaus?

Dat is inderdaad de afbeelding — een genest element wordt een diepere kop. Dat werkt goed voor document-vormige XML zoals DocBook, TEI of een artikel-export, waar de nesting echt secties binnen secties weerspiegelt. Het werkt slecht voor data-vormige XML waar de nesting een databaseschema weerspiegelt: dan krijg je twaalf kopniveaus die één record beschrijven.

Wat gebeurt er met namespace-prefixen?

Die vallen uit de uitvoer weg. Een kop die dc:title of tei:head luidt zegt een mens niets en een model nog minder, dus prefixen worden gestript en de lokale elementnaam wordt gebruikt. Definiëren twee namespaces in hetzelfde document dezelfde lokale naam, dan klappen ze samen — zeldzaam, maar de moeite van een blik waard als koppen dubbel lijken.

Is dit bruikbaar voor DocBook of DITA?

Als eerste slag: ja. Proza, secties, lijsten en inline nadruk komen goed over, omdat die formaten ze expliciet markeren. Conditional profiling, content references, entity includes en het oplossen van kruisverwijzingen overleven het niet — dat waren nou net de onderdelen die het formaat de moeite waard maakten, en geen generieke converter kan ze oplossen.

Wat kies ik voor een groot XML-corpus?

Tekst, in de meeste gevallen. Bouw je embeddings over duizenden records, dan is kopsyntaxis overhead die op elke chunk wordt herhaald zonder winst bij het ophalen. Markdown verdient zijn plek wanneer een mens of een model één document gaat lezen en moet weten waar de secties zitten.

Liever platte tekst, en de rest van de suite

Wil je helemaal geen structuur — tekst voor embeddings, een zoekindex, of het laagst mogelijke aantal tokens — gebruik dan XML naar platte tekst, die de inhoud tussen de tags vandaan haalt en verder niets achterlaat. De formaat-schakelaar bovenaan deze pagina wisselt tussen de twee en houdt je bestand geladen, dus beide uitvoeren vergelijken kost één klik. De tokenteller onder de uitvoer vertelt je wat elk van beide kost.

Is de XML één bestand in een project — een config, een build-descriptor, een fixture — dan geeft los converteren een model de data zonder de code eromheen. Met de GitHub repository naar tekst converter en de lokale-mapconverter neem je de XML en zijn afnemers samen mee, en dat is meestal de nuttigere eenheid. File2Txt behandelt elk ondersteund formaat op één plek, en de gids voor het voorbereiden van bestanden voor LLM's behandelt de algemene principes.

Repo2Txt wordt gebouwd en onderhouden door v12hero, een onafhankelijke ontwikkelaar die privacy-first native en webapps maakt.