2017/12/10

この記事はPowerShell Advent Calendar 2017の10日目です。

PowerShellはオブジェクトを扱うシェルですが、別にテキストデータを扱えない訳ではありません。むしろ、PowerShellで取得したデータをテキストファイルとして保存したり、スクリプトで用いるデータをテキストファイルで保存しておくことは日常的に行われることだと思います。

ただし、PowerShellで扱うデータはオブジェクトであり、テキストファイルは文字通り文字列であることから、コマンドレットを用いる等、何らかの手段で変換が必要になります。また、テキストデータ形式にも様々な種類があり、それぞれメリット、デメリットが存在します。今回の記事では、PowerShellで用いるデータを保持しておく際のテキストデータ形式について比較をしてみます。

プレーンテキスト

プレーンテキスト、すなわち書式なしのテキストファイルです。もっともシンプルな使い方をする場合、文字列配列の各要素に含まれる文字列が、テキストファイルの1行と対応します。

書き出し
$lines | Set-Content -LiteralPath file.txt -Encoding UTF8

$linesは文字列変数です。

特に理由がなければ文字コードはUTF-8で良いと思います。

追記
$lines | Add-Content -LiteralPath file.txt -Encoding UTF8

Add-Contentは実行のたびにファイルを開いて、書き込んでから閉じるという動作をするので、1行ずつforeachで実行するのはNGです。

読み込み
$lines = @(Get-Content -LiteralPath file.txt -Encoding UTF8)
メリット
  • 文字列配列をテキストファイルに書き出すのは多分これが一番楽だと思います。
  • 書き出したデータは人間にも読みやすい。 編集もしやすい。
デメリット
  • 文字列だけを保存しておきたいというケースがそもそも少ない。
CSV

コンマ等の特別な文字で区切り、1行あたりに複数のデータを保存できる形式です。

PowerShellのコマンドレットで扱う場合、オブジェクトが持つプロパティがヘッダ列名に対応します。各行にオブジェクト配列1要素のプロパティ値が、カンマ区切りで保持されます。

書き出し
$objects | Export-Csv -LiteralPath file.csv -NoTypeInformation -Encoding Default

$objectsは任意のオブジェクト配列です。必要であればSelect-Objectコマンドレットを併用して、プロパティを絞り込みます。

文字コードはExcelでそのまま読み込み/書き出しができるDefault(日本語環境ではShift_JIS)がお勧めです。(最近のExcel2016ならUTF8も一応読めますが)

追記
$objects | Export-Csv -LiteralPath file.csv -Append -NoTypeInformation -Encoding Default
読み込み
$objects = Import-Csv -LiteralPath file.csv -Encoding Default
メリット
  • オブジェクトのプロパティ値が、すべて数値あるいは文字列で表現できる値を持つ場合に最も適合する。
  • 人間にも読みやすく、ある程度は編集もできる。
  • Excelで開ける。
デメリット
  • オブジェクトのプロパティが、数値と文字列以外のオブジェクトである場合、すなわち、階層構造を持つデータの保存には適さない。
  • 数値も文字列として読み込まれてしまうので、数値として扱いたい場合は変換が必要になる。
  • Export-CsvとImport-Csvで扱うCSVファイルはヘッダが必須。つまり、ヘッダなしのCSVファイルが既にあって、それを読み書きするという用途には適さない。(できなくはないが)
  • 書き出し時の列順を制御することができない。つまり、PowerShellで書き出したCSVを、列順が固定であるとの想定である他のプログラムで読み込むことは基本NG。
  • 書き出し時、1つ目の要素に存在しないプロパティは、2つ目以降では存在しないものとして扱われる。同種のオブジェクトで構成される配列なら通常は問題ないのだが、要素によって動的に追加されるプロパティがあったりなかったりすると厄介。(ADでありがち)
JSON

JavaScriptのような表記でデータを保持するデータ形式です。データの受け渡しに様々な言語で利用できます。Web APIでもよく利用されます。

PowerShellではv3からJSONを扱うコマンドレットが提供されています。

書き出し
$objects | ConvertTo-Json | Set-Content -LiteralPath file.json -Encoding UTF8
読み込み
$objects = Get-Content -LiteralPath file.json -Encoding UTF8 -Raw | ConvertFrom-Json
メリット
  • CSVと異なり、階層構造を持ったデータでも扱える。
  • CSVと異なり、数値は数値型のまま読み書き可能。 (整数値はint、小数値はdecimal)
  • 人間にもまぁまぁ読めるし、頑張れば編集できなくもない。
デメリット
  • -Depthパラメータによりプロパティを展開する階層の深さを指定はできるが、プロパティに応じて深さ指定を変化させるというようなことはできない。基本的には、自分で構築したPSCustomObjectを使うか、JSON化する前に自分で元オブジェクトを整形しておく必要がある。
  • 直接ファイルに書き出し、追記、ファイルから読み込みするコマンドレットはない。
  • 実は細かい話をしだすと色々と罠があります…。
CLIXML

PowerShellではPSリモーティング等、プロセス間でオブジェクトのやり取りを行う際に、CLIXML形式を介してシリアライズ/デシリアライズが実行されます。シリアライズ対象によっては、完全に元のクラスのオブジェクトに復元されます。(復元されないオブジェクトにはクラス名にDeserialized.との接頭辞が付与され、プロパティ値のみ復元される)

ユーザーもコマンドレットを用いて、任意のデータをCLIXML形式でシリアライズし、XMLファイルとして保存することができます。

書き出し
$objects | Export-Clixml -LiteralPath file.xml
読み込み
$objects = Import-Clixml -LiteralPath file.xml
メリット
  • 元のオブジェクトの構造、プロパティ値と型情報を含めてほぼ完全にテキストファイルに保存できる。
  • 復元したオブジェクトはプロパティ値を参照できるのはもちろん、オブジェクト全体が完全にデシリアライズされ、元の型に戻った場合には、メソッドを実行することも可能。
  • 例え元の型に戻らず、Deserialized.との接頭辞が付いた状態でも、コンソールに表示する場合は元の型のフォーマットが使われるので見やすい。
デメリット
  • すべてのオブジェクトが元の型に戻せるわけではない。戻せるかどうかは確認が必要。
  • 人間が読み書きするようなものではない。

ちなみに、ConvertTo-Xmlという似たようなコマンドレットがありますが、出力形式はCLIXMLではない上、復元の手段もなく、かといって別に読みやすいXMLというわけでもなく、正直何のために使うのかよく分かりません(適切なxsltでも用意すればいいのかな?)。まだConvertTo-Htmlの方が使えそうです。

psd1

psd1は「PowerShellデータファイル」で、モジュールマニフェストやローカライズデータに使われるファイル形式です。スクリプトファイルの1種ですが、数値や文字列リテラル、配列、連想配列、コメントなど基本的な言語要素のみ使用可能です。PowerShell 5.0以降ではImport-PowerShellDataFileコマンドレットを用いて、任意のpsd1ファイルのデータを読み込み、変数に格納することが可能です。

書き出し

書き出し用のコマンドレットはありません。

読み込み

例えば以下のような内容をbackup_setting.psd1として保存しておきます。ルート要素は必ず連想配列にします。

@{
	Directories = @(
		@{
			From = "C:\test1"       # コピー元
			To = "D:\backup\test1"  # コピー先
			Exclude = @("*.exe", "*.dll")
			Recurse = $true
		},
		@{
			From = "C:\test2"
			To = "D:\backup\test2"
			Exclude = @("*.exe")
			LimitSize = 50MB
		},
		@{
			From = "C:\test3"
			To = "D:\backup\test4"
		}
	)
	Start = "0:00"
}

なお、dataセクションで全体を括ってもいいですが、psd1で許容される言語要素はdataセクションより更に制限がきついので、敢えてしなくてもいいんじゃないかと思います。

このファイルは以下のように読み込めます。

$setting = Import-PowerShellDataFile -LiteralPath backup_setting.psd1

$settingには連想配列が格納され、以下のように値が参照できます。

$setting.Directories | foreach {Copy-Item -Path $_.From -Destination $_.To}
メリット
  • PowerShellの構文でデータを記述できる。
  • 通常のps1ファイルを呼び出すのとは異なり、式の評価やコマンド実行などはされない分、セキュアである。
  • 配列と連想配列の組み合わせにより、JSONライクな階層構造を持てる。型情報も保持される。
  • JSONとは違い、コメントが入れられる。
デメリット
まとめ

PowerShellで扱うデータをテキストファイルとして保存する際には、各テキストデータ形式の特性を理解し、メリット、デメリットを踏まえて選定する必要があります。

また、当然ながらテキストファイルに保持することが不適切なデータもありますので、そこは注意してください。(画像データを敢えてBase64とかでエンコードしてテキストファイル化する意味があるのか、とかですね)

個人的には…

ちょっとした作業ログ等を記録しておきたい→プレーンテキスト

.NETオブジェクトの一部のプロパティだけ抜き出してファイル化したい→CSV

自分で構築したPSCustomObjectをファイル化したい→JSON

.NETオブジェクト全体をファイル化したい→CLIXML

スクリプトで使う設定データを用意したい→psd1

みたいな感じでなんとなく使い分けていると思います。psd1はまだ採用例はないですが…。

今回はビルトインのコマンドレットで扱えるもののみ取り上げましたが、他にもyaml等のテキストデータ形式が存在し、有志によるモジュールを用いて扱うことが可能です。

2014/04/15

PowerShellはゆるふわな言語ですが、そのゆるふわさがたまによく牙を剥きます。今日はそんなお話。

あえとすさんがこんなツイートをされていました。

直観的には、$xには'A', 'B', 'C'の3要素が格納された配列となるのでLengthは3、$x[2]は最後の要素である'C'が入っていそうです。

さて、何故だかわかりますか。シンキングタイム3分。

…では解説です。

まず、'A' + @('B', 'C')というのは実は3要素の配列を返さず、単一の文字列を返します。というのもPowerShellは+, -等の二項演算子を利用する際、左辺と右辺の型が異なる場合は、まず右辺の型を左辺の型に暗黙の型変換を行ってから演算を行います。この場合だと右辺は@('B', 'C')なので文字列配列(厳密にはobject[])、左辺は文字列型なので、文字列配列が文字列に型変換されるわけです。

さて、ここで配列→文字列の型変換がどうやって行われるかという話なのですが、まず配列要素がそれぞれ文字列型に変換されます。この変換は型によってそれぞれ挙動が違いますが、特にPowerShell上で定義がない場合はToString()されたものが返されます。今回のは配列要素が元々文字列なので変換はありません。

次に、文字列同士がユーザー定義$OFSに格納されている文字列で連結されます。$OFSはデフォルトではnull(定義なし)なのですが、nullの場合は" "(半角スペース)として扱われます。

※ちなみにOFSとはOutput Field Separatorの略です。awkとかPerlとかにも同様の変数があり、PowerShellのはそれらを参考にしたものと思います。

よって、@('B', 'C')が文字列に変換されると、'B'と'C'が$OFSのデフォルトの" "で連結され、'B C'となります。変換の後+演算子が実行されて、'A'と'B C'が連結されるので、'AB C'となります。この値が$xに格納されるわけです。

$xには配列ではなく単一の文字列が格納されているので、Lengthプロパティはstringクラスのものが参照されるので、文字数を返却します。$xの中身はA,B,半角スペース,Cの4文字なので$x.Lengthは4になります。

また文字列変数に数値でのインデックスアクセスをすると、該当文字位置に格納されたchar型の文字が返されるので、$x[2]は$xに格納された3番目の文字(インデックスは0から始まるので)、' '(半角スペース)を返すわけですね。

これであえとすさんの疑問は解消したわけですが、じゃあ本来の目的である、「単一の値と配列を連結して配列を得る」にはどうするか、というと…

となるわけです。こうやって非配列値をあらかじめ@()により要素数1の配列にしておくと、+演算子の左辺と右辺がどちらも配列型となるため型変換は行われず、配列同士の+演算、すなわち配列の連結処理が行われるわけですね。

その1とありますがその2があるかは不明。なお、闇が沢山あるのは事実です。('A`)ヴァー

2010/09/20

文字列を連結する際、+=演算子などを使うとループ回数によっては非常に時間がかかることがあります。これは+=演算子が実行されるたびに毎回string型の新しいインスタンスを生成しているからです。同じ文字列変数に対して+=演算子で文字列を追加していくループがある場合は、+=演算子の代わりにStringBuilderクラスを使うのが良いです。

たとえば、

$str=""
@("aaaa","bbbb","cccc","dddd")|
%{$str += $_}
$str

というようなコードと同様の結果を得るためには、

$sb=New-Object System.Text.StringBuilder
@("aaaa","bbbb","cccc","dddd")|
%{[void]$sb.Append($_)}
$sb.ToString()

のようにします。[void]にキャストしているのは、AppendメソッドがStringBuilderのインスタンスを返すため、それを表示させないようにするためです。結果はいずれも

aaaabbbbccccdddd

となり、文字列の連結が可能です。

このようにループ回数が少ない場合はそれほど所要時間に差はないのですが、数千の文字列を連結していく場合だと+=演算子を使うと非常に時間がかかります。どれくらい差が出るのか、スクリプトを書いて検証してみました。

function Measure-StringJoinCommand
{
    param([int]$itemCount)
    
    $randomStrs=@()
    @(1..$itemCount)|%{$randomStrs += Get-Random}
    $StringJoinTime=@()
    $StringBuilderTime=@()
    @(1..3)|
    %{
        $StringJoinTime +=
            (Measure-Command {
                $str=""
                $randomStrs|%{$str+=$_}
                $str
            }).Ticks
        $StringBuilderTime +=
            (Measure-Command {
                $sb=New-Object System.Text.StringBuilder
                $randomStrs|%{[void]$sb.Append($_)}
                $sb.ToString()
            }).Ticks
    }   
   
    $result=New-Object psobject
    $result|Add-Member -MemberType noteproperty -Name ElementCount -Value $itemCount
    $result|Add-Member -MemberType noteproperty -Name StringJoinTime -Value (($StringJoinTime|Measure-Object -Average).Average/10000)
    $result|Add-Member -MemberType noteproperty -Name StringBuilderTime -Value (($StringBuilderTime|Measure-Object -Average).Average/10000)
    $result|Add-Member -MemberType noteproperty -Name StringJoinTicksPerElement -Value (($StringJoinTime|Measure-Object -Average).Average/$itemCount)
    $result|Add-Member -MemberType noteproperty -Name StringBuilderTicksPerElement -Value (($StringBuilderTime|Measure-Object -Average).Average/$itemCount)
    $result 
}

@(100,300,500,800,1000,3000,5000,8000,10000,30000,50000,80000)|
    %{Measure-StringJoinCommand -itemCount $_}|
    Format-Table -Property `
        @{Label="Elements";Expression={$_.ElementCount.ToString("#,##0")};Width=8},
        @{Label="StringJoin(msec)";Expression={$_.StringJoinTime.ToString("#,##0")};Width=20},
        @{Label="StringBuilder(msec)";Expression={$_.StringBuilderTime.ToString("#,##0")};Width=20},
        @{Label="StringJoin(tick/element)";Expression={$_.StringJoinTicksPerElement.ToString("#,##0")};Width=30},
        @{Label="StringBuilder(tick/element)";Expression={$_.StringBuilderTicksPerElement.ToString("#,##0")};Width=30}

CPU=Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz,memory=3GB,Windows 7 x86での実行結果は次の通り

Elements StringJoin(msec)     StringBuilder(msec)  StringJoin(tick/element)       StringBuilder(tick/element)   
-------- ----------------     -------------------  ------------------------       ---------------------------   
100      8                    6                    830                            646                           
300      22                   22                   719                            746                           
500      36                   34                   718                            689                           
800      60                   55                   755                            690                           
1,000    86                   72                   857                            721                           
3,000    264                  192                  880                            638                           
5,000    573                  334                  1,146                          667                           
8,000    1,534                522                  1,917                          653                           
10,000   2,562                731                  2,562                          731                           
30,000   23,386               2,204                7,795                          735                           
50,000   60,805               3,730                12,161                         746                           
80,000   184,407              6,541                23,051                         818   

この表は左から、連結する文字列要素数(ループ回数)、+=演算子を使った場合の所要時間(ミリ秒)、StringBuilderを使った場合の所要時間(ミリ秒)、+=演算子を使った場合の1要素あたりの所要時間(tick=100ナノ秒)、StringBuilderを使った場合の1要素あたりの所要時間(tick=100ナノ秒)、です。なお1要素当たりの平均文字数は9文字程度です。また、測定は3回おこない平均値を取っています。

この表によるとループ回数が5000回程度であれば所要時間にさほど差違は見られませんが、それ以降は急激に+=演算子の所要時間が増えることが分かります。また、+=演算子はループが5000回より増えるとループ回数が増えれば増えるほど1要素あたりにかかる時間も増えるのに対し、StringBuilderの場合はほぼ一定です。

というわけで1ループあたりに追加する文字数とループ回数が少ない場合は+=演算子でもそれほど問題にはなりませんが、そうでない場合はStringBuilderを使うのが良さそうです。これらの値が増加する可能性がある場合は、最初からStringBuilderを使っておけば、ある日突然処理がめちゃくちゃ重くなる、という事態も避けられるでしょう。PowerShellでStringBuilderを使っているサンプルがネットにはあまり見当たらなかったのですが、PowerShellでも積極的に使うと幸せになれると思います。

元記事:http://blogs.wankuma.com/mutaguchi/archive/2010/09/20/193089.aspx


Copyright © 2005-2018 Daisuke Mutaguchi All rights reserved
mailto: mutaguchi at roy.hi-ho.ne.jp
プライバシーポリシー

Books

Twitter