PowerShell zu XML Converter
Füge PowerShell-Objekte oder Hashtables ein. Bekomme sauberes XML zurück.
Was dieses Tool macht
Wenn du schon mal eine PowerShell-Konfiguration in eine XML-Datei packen musstest — für eine DSC-Ressource, einen MSBuild-Task, ein app.config-Template oder ein SoapUI-Fixture — kennst du das Spiel. Du landest entweder bei ConvertTo-Xml und schneidest die hässlichen <Object Type="...">-Wrapper per Hand raus, oder bei Export-CliXml und bekommst ein CLIXML-Payload, das außerhalb von PowerShell niemand lesen kann. Füge das PowerShell hier ein und du bekommst wohlgeformtes XML zurück, das jeder normale XML-Parser akzeptiert — kein <Property Name="...">-Müll, keine CLIXML-Typ-Tags, einfach nur die Daten.
Das Tool versteht die Formen, die PowerShell-Code wirklich nutzt. Ein PSCustomObject wird zu einem Element mit Kind-Elementen, die nach jeder Property benannt sind. Ein Hashtable @{ Name = "Ava" } verhält sich genauso. Ein mit @(...) erzeugtes Array wird zu einem Container-Element mit einem Kind pro Eintrag. Verschachtelte [PSCustomObject]-Werte innerhalb eines Parent-Objekts kommen als verschachtelte Elemente durch, nicht als stringifizierte Klumpen. Booleans ($true, $false) und Zahlen behalten ihre nativen Typen in der Ausgabe; $null wird zu einem leeren selbstschließenden Element, damit die Form vorhersehbar bleibt, anstatt das Feld stillschweigend fallen zu lassen.
Ein paar Eigenheiten der Sprache werden so behandelt, wie ein Mensch es erwarten würde. Strings in doppelten Anführungszeichen kommen durch, ohne dass Interpolationsmarker wie $var expandiert werden — wir bewahren das, was du wörtlich eingefügt hast. Here-Strings (@" ... "@) werden als mehrzeiliger Textinhalt behandelt. Daten, die als [datetime]"2026-04-21" geschrieben sind, werden als ISO-8601-Strings ausgegeben. Property-Namen mit Bindestrichen bekommen einen sicheren Element-Namen (in PowerShell kannst du "User-Agent" = "..." in einem Hashtable schreiben, was als rohes XML-Tag illegal ist — wir konvertieren es, damit die Ausgabe weiterhin parsebar ist). Die Form bleibt dem Input treu; das XML bleibt nutzbar.
So benutzt du es
Drei Schritte. Funktioniert gleich, egal ob du ein einzelnes Hashtable einfügst oder ein ganzes Konfigurationsskript.
PowerShell einfügen (oder Beispiel ausprobieren)
Wirf dein Skript in den linken Editor. Ein einzelnes [PSCustomObject]@{...}, ein verschachteltes Hashtable, ein @(...)-Array aus Objekten oder ein ganzer Config-Block — alles geht. Klicke Beispiel laden, wenn du zuerst mit einem realistischen Order-Payload rumspielen willst.
Du musst keine Kommentare entfernen, param()-Blöcke rauswerfen oder das Skript vorher aufräumen. Füge ein, was du hast. Wir lesen nur die Objekt-Literale und ignorieren den Rest.
Konvertieren drücken
Klick auf den grünen Konvertieren-Button. Das Tool läuft durch die PowerShell-Struktur, bewahrt jede Property und jedes Array-Item und baut das XML in einem Durchgang. Du siehst eine kurze Lade-Anzeige, während es läuft.
XML kopieren
Das rechte Panel füllt sich mit eingerücktem XML, das jeder standardkonforme Parser akzeptiert. Pack es in deine DSC-Konfiguration, deine MSBuild-Datei oder wohin du es auch brauchst.
Wann das wirklich praktisch wird
DSC-Konfigurations-Payloads schreiben
Du hast ein PowerShell-Hashtable, das eine Node-Konfiguration beschreibt, und brauchst eine XML-Version für einen Non-DSC-Consumer oder für die Doku. Einfügen, konvertieren, fertig — kein Gebabysitte der ConvertTo-Xml-Ausgabe mehr.
Azure DevOps Pipeline-Variablendateien
Pipelines erwarten manchmal eine Variablengruppe als XML. Füge das PowerShell-Hashtable ein, das du eh schon pflegst, und bekomme XML zurück, das direkt in <code>variables.xml</code> passt — ohne Handarbeit.
Windows-Ereignisprotokoll-Payloads exportieren
Wenn du einen Event-Record in PowerShell als PSCustomObject baust und ihn in eine Logging-Pipeline füttern musst, die XML aufnimmt, spart dir das den Eigenbau eines Serialisierers. Die verschachtelte Form kommt unverändert durch.
app.config / web.config Seed-Templates
Verwandle ein PowerShell-Settings-Hashtable in eine Ausgangs-<code>app.config</code>, die du per Hand editieren kannst. Schneller als eine von Grund auf zu bauen und hält die Keys mit deinen Skripten synchron.
Häufige Fragen
Inwiefern unterscheidet sich das davon, ConvertTo-Xml auf mein Objekt anzuwenden?
ConvertTo-Xml packt alles in einen generischen <Object Type="..."><Property Name="...">-Umschlag — lesbar von PowerShell, hässlich überall sonst. Dieses Tool gibt die Property-Namen als echte XML-Elemente aus, sodass die Ausgabe so aussieht, wie eine Person XML von Hand schreiben würde. Keine <Property Name>-Indirektion, kein Typ-Attribut-Müll.
Produziert es CLIXML wie Export-CliXml?
Nein — und genau das ist der Punkt. Export-CliXml gibt CLIXML aus, ein PowerShell-spezifisches Format für das Roundtripping zurück nach PowerShell. Wenn du das XML an ein System übergeben musst, das kein PowerShell ist (ein Java-Service, ein Config-Reader, eine XSD-validierte Pipeline), ist CLIXML die falsche Form. Dieses Tool gibt dir stattdessen schlichtes, lesbares XML.
Kann ich eine komplette .ps1-Datei einfügen oder nur Objekt-Literale?
Füge ein, was du hast. Wenn das Skript ein einzelnes Objekt-Literal enthält, das einer Variable zugewiesen ist, kommt das durch. Wenn es mehrere Top-Level-Hashtables oder PSCustomObjects gibt, wird jedes als eigenes Element ausgegeben. Funktionskörper, param()-Blöcke, Imports und Write-Host-Zeilen werden ignoriert — nur die Datenformen zählen.
Wie werden $null, $true, $false und leere Arrays behandelt?
$null wird zu einem leeren selbstschließenden Element, damit die Form konsistent bleibt (statt dass das Feld einfach verschwindet). $true und $false werden zu den literalen Strings true und false. Ein leeres @() wird zu einem leeren Container-Element. So sieht Tooling weiter unten immer dieselbe Struktur, auch wenn manche Felder nicht gesetzt sind.
Was ist mit Hashtable-Keys, die keine gültigen XML-Namen sind — Bindestriche, Leerzeichen, Zahl am Anfang?
Keys wie "User-Agent" oder "2024-Q1" sind in einem PowerShell-Hashtable legal, aber als rohe XML-Element-Namen illegal. Wir schreiben sie in eine sichere Form um (und behalten das Original als Attribut, wo das Sinn ergibt), damit die Ausgabe parsebar bleibt. Falls das für deinen Consumer wichtig ist, schau dir die erzeugten Tags vorher an.
Wird mein Code gespeichert?
Der Code wird zur Konvertierung an das Backend geschickt und nicht persistiert — wir loggen das Payload nicht. Wenn das Skript wirklich sensibel ist (Produktions-Credentials, interne Pfade), räume es vorher auf, genau wie du es bei jedem Online-Tool tun würdest.
Andere Tools, die du vielleicht brauchst
PowerShell zu XML ist nur ein Puzzleteil. Diese Tools passen gut dazu: