PowerShell naar XML Converter
Plak PowerShell-objecten of hashtables. Krijg schone XML terug.
Wat deze tool doet
Als je ooit een PowerShell-config in een XML-bestand moest proppen — voor een DSC-resource, een MSBuild-task, een app.config-template of een SoapUI-fixture — ken je de routine. Je eindigt óf met ConvertTo-Xml waarna je de lelijke <Object Type="...">-wrappers met de hand wegknipt, óf je grijpt naar Export-CliXml en krijgt een CLIXML-payload terug dat niemand buiten PowerShell kan lezen. Plak je PowerShell hier en je krijgt welgevormde XML terug die een normale XML-parser accepteert — geen <Property Name="...">-herrie, geen CLIXML-type-tags, gewoon de data.
De tool begrijpt de vormen die PowerShell-code daadwerkelijk gebruikt. Een PSCustomObject wordt een element met child-elementen genoemd naar elke property. Een hashtable @{ Name = "Ava" } gedraagt zich hetzelfde. Een array gemaakt met @(...) wordt een container-element met één kind per item. Geneste [PSCustomObject]-waarden binnen een parent-object komen door als geneste elementen, niet als gestringifieerde blobs. Booleans ($true, $false) en getallen houden hun native types in de output; $null wordt een leeg zelfsluitend element zodat de vorm voorspelbaar blijft in plaats van dat het veld stilletjes verdwijnt.
Een paar eigenaardigheden van de taal worden afgehandeld zoals een mens zou verwachten. Strings tussen dubbele aanhalingstekens komen door zonder dat interpolatie-markers zoals $var worden uitgeklapt — we bewaren wat je letterlijk hebt geplakt. Here-strings (@" ... "@) worden behandeld als meerregelige tekstinhoud. Datums geschreven als [datetime]"2026-04-21" komen als ISO-8601-strings uit. Property-namen met streepjes krijgen een veilige elementnaam (PowerShell laat je "User-Agent" = "..." in een hashtable schrijven, wat als rauwe XML-tag illegaal is — we converteren het zodat de output parsebaar blijft). De vorm blijft trouw aan de input; de XML blijft bruikbaar.
Hoe gebruik je 'm
Drie stappen. Werkt hetzelfde of je nou één hashtable plakt of een heel configuratiescript.
Plak je PowerShell (of probeer het voorbeeld)
Gooi je script in de editor links. Een enkele [PSCustomObject]@{...}, een geneste hashtable, een @(...)-array van objecten, of een heel config-blok — alles is prima. Klik op Voorbeeld laden als je eerst met een realistische Order-payload wilt spelen.
Je hoeft geen commentaar weg te halen, geen param()-blokken te slopen en het script niet vooraf op te schonen. Plak wat je hebt. We lezen alleen de object-literalen en negeren de rest.
Druk op Converteren
Klik op de groene Converteren-knop. De tool loopt door de PowerShell-structuur, bewaart elke property en elk array-item, en bouwt de XML in één keer op. Je ziet een korte laadindicator terwijl het loopt.
Kopieer de XML
Het rechterpaneel vult zich met ingesprongen XML die elke standaardconforme parser accepteert. Plop het in je DSC-configuratie, je MSBuild-bestand, of waar je het ook nodig hebt.
Wanneer dit echt handig is
DSC-configuratiepayloads opstellen
Je hebt een PowerShell-hashtable die een node-configuratie beschrijft en je hebt een XML-versie nodig voor een niet-DSC consumer of voor documentatie. Plakken, converteren, klaar — geen gebabysit meer op de output van ConvertTo-Xml.
Azure DevOps pipeline-variabelebestanden
Pipelines verwachten soms een variabelengroep als XML. Plak de PowerShell-hashtable die je toch al onderhoudt, krijg XML terug dat zo in <code>variables.xml</code> past — zonder met de hand te redigeren.
Windows event-log payloads exporteren
Als je een event-record in PowerShell bouwt als PSCustomObject en het moet doorsturen naar een loggingpipeline die XML consumeert, bespaart dit je het schrijven van een custom serializer. De geneste vorm komt onveranderd door.
app.config / web.config seed-templates
Zet een PowerShell-settings-hashtable om in een startpunt-<code>app.config</code> die je met de hand kunt bewerken. Sneller dan er eentje vanaf nul te genereren en houdt de keys in sync met je scripts.
Veelgestelde vragen
Hoe verschilt dit van ConvertTo-Xml op mijn object draaien?
ConvertTo-Xml wikkelt alles in een generieke <Object Type="..."><Property Name="...">-envelop — leesbaar vanuit PowerShell, lelijk overal elders. Deze tool geeft de property-namen als echte XML-elementen uit, dus de output ziet eruit zoals een persoon XML met de hand zou schrijven. Geen <Property Name>-omweg, geen type-attribuut-rommel.
Produceert het CLIXML zoals Export-CliXml?
Nee — en dat is precies het punt. Export-CliXml geeft CLIXML uit, een PowerShell-specifiek formaat ontworpen voor round-tripping terug naar PowerShell. Als je de XML moet afleveren aan een systeem dat geen PowerShell is (een Java-service, een config-reader, een XSD-gevalideerde pipeline), is CLIXML de verkeerde vorm. Deze tool geeft je in plaats daarvan platte, leesbare XML.
Mag ik een complete .ps1-file plakken of alleen object-literalen?
Plak wat je hebt. Als het script één object-literal bevat dat aan een variabele is toegewezen, komt dat door. Zijn er meerdere top-level hashtables of PSCustomObjects, dan wordt elk als eigen element uitgegeven. Functie-bodies, param()-blokken, imports en Write-Host-regels worden genegeerd — alleen de datavormen tellen.
Hoe worden $null, $true, $false en lege arrays afgehandeld?
$null wordt een leeg zelfsluitend element zodat de vorm consistent blijft (in plaats van dat het veld verdwijnt). $true en $false worden de letterlijke strings true en false. Een lege @() wordt een leeg container-element. Zo ziet downstream-tooling altijd dezelfde structuur, ook als sommige velden niet gezet zijn.
En hashtable-keys die geen geldige XML-namen zijn — streepjes, spaties, beginnen met een cijfer?
Keys als "User-Agent" of "2024-Q1" zijn legaal in een PowerShell-hashtable maar illegaal als rauwe XML-elementnamen. We schrijven ze om naar een veilige vorm (met de originele als attribuut waar dat zin heeft) zodat de output blijft parsen. Als dat belangrijk is voor je consumer, bekijk de gegenereerde tags eerst even.
Wordt mijn code opgeslagen?
De code wordt voor de conversie naar de backend gestuurd en niet bewaard — we loggen de payload niet. Als het script echt gevoelig is (productie-credentials, interne paden), maak het schoon voor je plakt, net als je bij elke online tool zou doen.
Andere tools die je misschien nodig hebt
PowerShell naar XML is maar een stukje van de puzzel. Deze tools passen er goed bij: