Klistra in PowerShell till vänster och klicka på "Konvertera" — vi gör XML av detKlistra in PowerShell-kod

Vad verktyget gör

Om du någonsin har behövt trycka in en PowerShell-konfiguration i en XML-fil — för en DSC-resurs, en MSBuild-task, ett app.config-template eller en SoapUI-fixture — så vet du redan proceduren. Du hamnar antingen med ConvertTo-Xml och får klippa bort de fula <Object Type="...">-omslagen för hand, eller tar till Export-CliXml och får tillbaka en CLIXML-payload som ingen utanför PowerShell vet hur man läser. Klistra in PowerShell här så får du tillbaka välformad XML som en vanlig XML-parser accepterar — inget <Property Name="...">-brus, inga CLIXML-typtaggar, bara datat.

Verktyget förstår formerna som PowerShell-kod faktiskt använder. Ett PSCustomObject blir ett element med barn-element namngivna efter varje property. Ett hashtable @{ Name = "Ava" } beter sig likadant. En array skapad med @(...) blir ett container-element med ett barn per objekt. Nästade [PSCustomObject]-värden inuti ett parent-objekt kommer igenom som nästade element, inte som stringifierade klumpar. Booleans ($true, $false) och tal behåller sina nativa typer i output; $null blir ett tomt självstängande element så att formen förblir förutsägbar istället för att fältet tyst försvinner.

Några av språkets egenheter hanteras som en människa skulle förvänta sig. Strängar inom dubbla citattecken kommer igenom utan att interpolationsmarkörer som $var expanderas — vi bevarar det du klistrade in bokstavligen. Here-strings (@" ... "@) behandlas som flerradigt textinnehåll. Datum skrivna som [datetime]"2026-04-21" matas ut som ISO-8601-strängar. Property-namn som innehåller bindestreck får ett säkert element-namn (PowerShell låter dig skriva "User-Agent" = "..." i ett hashtable, vilket är olagligt som rå XML-tagg — vi konverterar så att output fortsätter att parsas). Formen förblir trogen indatat; XML:en förblir användbar.

Så använder du det

Tre steg. Funkar likadant oavsett om du klistrar in ett enda hashtable eller ett helt konfigurationsskript.

1

Klistra in din PowerShell (eller testa exemplet)

Släpp ditt skript i editorn till vänster. En ensam [PSCustomObject]@{...}, ett nästat hashtable, en @(...)-array av objekt, eller ett helt config-block — allt funkar. Klicka Ladda exempel om du vill leka med en realistisk Order-payload först.

Du behöver inte ta bort kommentarer, plocka bort param()-block eller städa skriptet i förväg. Klistra in det du har. Vi läser bara objekt-literalerna och ignorerar resten.

2

Tryck Konvertera

Klicka på den gröna Konvertera-knappen. Verktyget går igenom PowerShell-strukturen, bevarar varje property och array-objekt, och bygger XML:en i en enda körning. Du ser en kort laddningsindikator medan det pågår.

3

Kopiera XML

Panelen till höger fylls med indenterad XML som vilken standardkompatibel parser som helst accepterar. Släng in det i din DSC-konfiguration, din MSBuild-fil eller var du nu behöver det.

När det verkligen kommer till användning

Skriva DSC-konfigurationspayloads

Du har ett PowerShell-hashtable som beskriver en nodkonfiguration och behöver en XML-version för en icke-DSC-konsument eller för dokumentation. Klistra, konvertera, klart — ingen mer barnvaktande av ConvertTo-Xml-output.

Azure DevOps pipeline-variabelfiler

Pipelines förväntar sig ibland en variabelgrupp som XML. Klistra in PowerShell-hashtablet du redan underhåller, få tillbaka XML som passar rakt in i <code>variables.xml</code> — utan handredigering.

Exportera Windows-händelseloggpayloads

När du bygger en händelsepost i PowerShell som ett PSCustomObject och behöver mata den till en loggningspipeline som tar in XML, sparar det dig från att skriva en egen serializer. Den nästade formen kommer igenom oförändrad.

app.config / web.config seed-mallar

Förvandla ett PowerShell-inställningshashtable till en startpunkts-<code>app.config</code> som du kan redigera för hand. Snabbare än att generera en från grunden och håller nycklarna synkade med dina skript.

Vanliga frågor

Hur skiljer sig det här från att köra ConvertTo-Xml på mitt objekt?

ConvertTo-Xml slår in allt i ett generiskt <Object Type="..."><Property Name="...">-kuvert — läsbart av PowerShell, fult överallt annars. Det här verktyget skickar ut property-namnen som riktiga XML-element, så output ser ut som XML skrivet av en person för hand. Ingen <Property Name>-omväg, inget typ-attribut-skräp.

Producerar det CLIXML som Export-CliXml gör?

Nej — och det är själva poängen. Export-CliXml matar ut CLIXML, ett PowerShell-specifikt format designat för round-tripping tillbaka till PowerShell. Om du behöver lämna över XML till ett system som inte är PowerShell (en Java-tjänst, en config-läsare, en XSD-validerad pipeline) är CLIXML fel form. Det här verktyget ger dig vanlig, läsbar XML istället.

Kan jag klistra in en hel .ps1-fil eller bara objekt-literaler?

Klistra in vad du har. Om skriptet innehåller en ensam objekt-literal tilldelad till en variabel är det den som kommer ut. Om det finns flera hashtables eller PSCustomObjects på toppnivå skickas varje ut som sitt eget element. Funktionskroppar, param()-block, imports och Write-Host-rader ignoreras — bara dataformerna spelar roll.

Hur hanteras $null, $true, $false och tomma arrayer?

$null blir ett tomt självstängande element så att formen förblir konsekvent (istället för att fältet försvinner). $true och $false blir de bokstavliga strängarna true och false. En tom @() blir ett tomt container-element. På så sätt ser downstream-verktyg alltid samma struktur även när vissa fält är osatta.

Och hashtable-nycklar som inte är giltiga XML-namn — bindestreck, mellanslag, börjar med siffror?

Nycklar som "User-Agent" eller "2024-Q1" är lagliga i ett PowerShell-hashtable men olagliga som råa XML-elementnamn. Vi skriver om dem till en säker form (och behåller originalet som attribut där det är rimligt) så att output fortsätter att parsas. Om det spelar roll för din konsument, kolla de genererade taggarna först.

Sparas min kod?

Koden skickas till backenden för konvertering och lagras inte — vi loggar inte payloaden. Om skriptet verkligen är känsligt (produktionscredentials, interna sökvägar), rensa det innan du klistrar in, på samma sätt som du skulle göra med vilket online-verktyg som helst.

Andra verktyg du kan behöva

PowerShell till XML är bara en pusselbit. Dessa verktyg passar bra ihop med det: