Powershell: De vele manieren om naar bestanden te lezen en te schrijven

Get-Content -Path $Path -Raw

$data | Export-CSV -Path $PathImport-CSV -Path $Path

$data | Export-CSV -Path $Path -NoTypeInformation

Rijke objectgegevens opslaan met Export-CliXml

Het Export-CliXml commando wordt gebruikt om volledige objecten op te slaan in een bestand en ze vervolgens weer te importeren met Import-CliXml. Dit is voor objecten met geneste waarden of complexe datatypes. De ruwe data zal een verbose geserialiseerd object in XML zijn. Het mooie is dat je een object in het bestand kunt opslaan en wanneer je het importeert, krijg je dat object weer terug.

Dit geserialiseerde formaat is niet bedoeld om direct bekeken of bewerkt te worden. Hier is hoe het date.clixml bestand eruit ziet:

Probeer het maar niet te begrijpen. Het is niet de bedoeling dat je er in gaat graven.

Dit is nog een commando dat ik niet vaak gebruik. Als ik een geneste of hiërarchische dataset heb, dan is JSON mijn favoriete manier om die informatie op te slaan.

Gestructureerde gegevens opslaan met ConvertTo-Json

Wanneer mijn gegevens genest zijn en ik ze misschien met de hand wil bewerken, dan gebruik ik ConvertTo-Json om ze naar JSON te converteren. ConvertFrom-Json zal het weer omzetten in een object. Deze commando’s kunnen zelf geen bestanden opslaan of uitlezen. Daarvoor moet u Get-Content en Set-Content gebruiken.

Er is een belangrijk ding om op te merken bij dit voorbeeld. Ik heb een gebruikt voor mijn $Data maar ConvertFrom-Json geeft in plaats daarvan een . Dit is misschien geen probleem, maar er is geen eenvoudige oplossing voor.

Ook het gebruik van de Get-Content -Raw in dit voorbeeld. ConvertFrom-Json verwacht één string per object.

Hier volgt de inhoud van het JSON-bestand van hierboven:

{ "Address": { "State": "California", "Street": "123 Elm" }}

Je zult merken dat dit lijkt op de oorspronkelijke hashtable. Dit is waarom JSON een populair formaat is. Het is gemakkelijk te lezen, te begrijpen en te bewerken indien nodig. Ik gebruik dit de hele tijd voor configuratie bestanden in mijn eigen projecten.

Andere opties en details

Al deze CmdLets zijn eenvoudig om mee te werken. We hebben ook nog wat andere parameters en toegang tot .Net voor meer opties.

Get-Content -ReadCount

De -ReadCount parameter op Get-Content definieert hoeveel regels die Get-Content in een keer zal lezen. Er zijn enkele situaties waarin dit de geheugen-overhead van het werken met grotere bestanden kan verbeteren.

Dit omvat in het algemeen het pipen van de resultaten naar iets dat ze kan verwerken als ze binnenkomen en de invoergegevens niet hoeft te bewaren.

$dataset = @{}Get-Content -Path $path -ReadCount 15 | Where-Object {$PSItem -match 'error'} | ForEach-Object {$dataset += 1}

Dit voorbeeld telt hoe vaak elke fout in de $Path opduikt. Deze pijplijn kan elke regel verwerken terwijl deze uit het bestand wordt gelezen.

Je hebt misschien geen code die hier vaak gebruik van maakt, maar dit is een goede optie om je bewust van te zijn.

Sneller lezen met System.IO.File

Het gebruiksgemak dat de CmdLets bieden, kan ten koste gaan van de ruwe prestaties. Het is klein genoeg dat je het niet zult merken bij het meeste scriptwerk dat je doet. Wanneer de dag komt dat je meer snelheid nodig hebt, zul je merken dat je je wendt tot de native .Net commando’s. Gelukkig zijn deze eenvoudig om mee te werken.

::ReadAllLines( ( Resolve-Path $Path ) )

Dit is net als Get-Content -Path $Path in die zin dat je eindigt met een verzameling vol met strings. U kunt de gegevens ook lezen als een tekenreeks met meerdere regels.

::ReadAllText( ( Resolve-Path $Path ) )

try{ $stream = ::new( $Path ) $data | ForEach-Object{ $stream.WriteLine( $_ ) }}finally{ $stream.close()}

$Xml = "<r><data/></r>"$Path = (join-path $pwd 'File.xml')$Xml.Save($Path)