Indsæt PowerShell til venstre og klik på "Konverter" — vi laver det om til XMLIndsæt PowerShell-kode

Hvad værktøjet gør

Hvis du nogensinde har haft brug for at proppe en PowerShell-konfiguration ind i en XML-fil — til en DSC-ressource, en MSBuild-opgave, et app.config-template eller en SoapUI-fixture — kender du dansen. Du ender enten med at køre ConvertTo-Xml og trimme de grimme <Object Type="...">-wrappers i hånden, eller med at gribe Export-CliXml og få et CLIXML-payload tilbage, som ingen uden for PowerShell ved, hvordan man læser. Indsæt PowerShell her, og du får velformet XML retur, som en normal XML-parser accepterer — ingen <Property Name="...">-støj, ingen CLIXML-typetags, bare dataene.

Værktøjet forstår de former, PowerShell-kode faktisk bruger. Et PSCustomObject bliver til et element med child-elementer navngivet efter hver property. En hashtable @{ Name = "Ava" } opfører sig på samme måde. En array lavet med @(...) bliver til et container-element med ét child per element. Nestede [PSCustomObject]-værdier inde i et parent-objekt kommer igennem som nestede elementer, ikke som stringificerede klumper. Booleans ($true, $false) og tal beholder deres native typer i outputtet; $null bliver til et tomt selv-lukkende element, så formen forbliver forudsigelig i stedet for at feltet stille forsvinder.

Nogle af sprogets særheder håndteres, som et menneske ville forvente. Strenge i dobbelte anførselstegn kommer igennem uden at interpolationsmarkører som $var bliver udvidet — vi bevarer det, du indsatte, bogstaveligt. Here-strings (@" ... "@) behandles som flerlinjet tekstindhold. Datoer skrevet som [datetime]"2026-04-21" udsendes som ISO-8601-strenge. Property-navne, der indeholder bindestreger, får et sikkert element-navn (PowerShell lader dig skrive "User-Agent" = "..." i en hashtable, hvilket er ulovligt som et råt XML-tag — vi konverterer det, så outputtet stadig kan parses). Formen forbliver tro mod inputtet; XML'en forbliver brugbar.

Sådan bruger du det

Tre trin. Virker ens, uanset om du indsætter én hashtable eller et helt konfigurationsscript.

1

Indsæt din PowerShell (eller prøv eksemplet)

Smid dit script i editoren til venstre. Et enkelt [PSCustomObject]@{...}, en nestet hashtable, en @(...)-array af objekter eller en hel config-blok — alt går. Klik Indlæs eksempel, hvis du vil lege med en realistisk Order-payload først.

Du behøver ikke fjerne kommentarer, pille param()-blokke ud eller rydde op i scriptet på forhånd. Indsæt det, du har. Vi læser kun objekt-literalerne og ignorerer resten.

2

Tryk på Konverter

Klik på den grønne Konverter-knap. Værktøjet går igennem PowerShell-strukturen, bevarer hver property og hvert array-element, og bygger XML'en i ét hug. Du ser en kort loading-indikator, mens det kører.

3

Kopier XML

Panelet til højre fyldes med indrykket XML, som enhver standardoverholdende parser vil acceptere. Smæk det ind i din DSC-konfiguration, din MSBuild-fil, eller hvor du nu har brug for det.

Når det virkelig er praktisk

Skrive DSC-konfigurationspayloads

Du har en PowerShell-hashtable, der beskriver en nodekonfiguration, og du har brug for en XML-version til en ikke-DSC-consumer eller til dokumentation. Indsæt, konverter, færdig — slut med at være barnepige for ConvertTo-Xml-output.

Azure DevOps pipeline-variabelfiler

Pipelines forventer nogle gange en variabelgruppe som XML. Indsæt den PowerShell-hashtable, du alligevel vedligeholder, og få XML retur, der passer lige ned i <code>variables.xml</code> — uden håndredigering.

Eksportere Windows-hændelseslog-payloads

Når du bygger en hændelsesrecord i PowerShell som et PSCustomObject og skal fodre det ind i en logging-pipeline, der tager XML, sparer det dig fra at skrive en custom serializer. Den nestede form kommer igennem uændret.

app.config / web.config startskabeloner

Lav en PowerShell-settings-hashtable om til et start-<code>app.config</code>, du kan redigere i hånden. Hurtigere end at generere en fra bunden, og holder nøglerne i sync med dine scripts.

Almindelige spørgsmål

Hvordan er det her anderledes end at køre ConvertTo-Xml på mit objekt?

ConvertTo-Xml pakker alt ind i en generisk <Object Type="..."><Property Name="...">-konvolut — læsbar fra PowerShell, grim alle andre steder. Dette værktøj sender property-navnene ud som rigtige XML-elementer, så outputtet ser ud som XML skrevet af en person i hånden. Ingen <Property Name>-omvej, ingen type-attribut-rod.

Producerer det CLIXML som Export-CliXml?

Nej — og det er lige præcis pointen. Export-CliXml outputter CLIXML, et PowerShell-specifikt format designet til round-tripping tilbage til PowerShell. Hvis du skal aflevere XML til et system, der ikke er PowerShell (en Java-service, en config-læser, en XSD-valideret pipeline), er CLIXML den forkerte form. Dette værktøj giver dig almindelig, læsbar XML i stedet.

Kan jeg indsætte en hel .ps1-fil, eller kun objekt-literaler?

Indsæt det, du har. Hvis scriptet indeholder et enkelt objekt-literal tildelt til en variabel, er det, der kommer ud. Hvis der er flere top-level hashtables eller PSCustomObjects, sendes hver ud som sit eget element. Funktionskroppe, param()-blokke, imports og Write-Host-linjer ignoreres — kun dataformerne betyder noget.

Hvordan håndteres $null, $true, $false og tomme arrays?

$null bliver til et tomt selv-lukkende element, så formen forbliver konsistent (i stedet for at feltet forsvinder). $true og $false bliver til de bogstavelige strenge true og false. Et tomt @() bliver til et tomt container-element. På den måde ser downstream-værktøjer altid den samme struktur, selv når nogle felter ikke er sat.

Og hashtable-nøgler, der ikke er gyldige XML-navne — bindestreger, mellemrum, starter med tal?

Nøgler som "User-Agent" eller "2024-Q1" er lovlige i en PowerShell-hashtable, men ulovlige som rå XML-elementnavne. Vi skriver dem om til en sikker form (beholder originalen som attribut, hvor det giver mening), så outputtet stadig kan parses. Hvis det betyder noget for din consumer, kig på de genererede tags først.

Bliver min kode gemt?

Koden sendes til backenden for at blive konverteret og gemmes ikke — vi logger ikke payloaden. Hvis scriptet er rigtig sensitivt (produktions-credentials, interne stier), så rens det, før du indsætter det, ligesom du ville med et hvilket som helst online-værktøj.

Andre værktøjer du måske får brug for

PowerShell til XML er bare et puslespilsstykke. Disse værktøjer passer godt sammen med det: