先日、仕事中に
UTF-8で保存した bat ファイルを Shift_JIS 前提の cmd で実行して、日本語が文字化けする
というトラブルに遭遇した。
原因も対処法も分かってしまえば単純だったけれど、
「今どき、まだここを気にしないといけないのか」と感じたのも正直なところだ。
その流れで改めて思ったのが、
PowerShell だと、このあたりの悩みがほとんど出てこないということだった。
今回は、bat と比較しながら、
PowerShell を使ったときに「違うな」と感じた点を整理してみる。
文字コードをあまり意識しなくていい
まず一番大きな違いは、文字コードの扱い。
bat ファイルでは、
- ファイルの保存文字コード
- 実行環境のコードページ
を意識しないと、日本語が簡単に文字化けする。
一方で PowerShell は、
UTF-8 前提で扱える場面が多く、日本語がそのまま扱える。
エディタで UTF-8 のまま保存しても、
echo 相当の出力やメッセージ表示が崩れにくい。
この「余計な前提を考えなくていい」感覚は、
実務ではかなり大きいと感じている。
ログや結果を“文字列”ではなく“データ”として扱える
bat では、
- コマンドの出力
- エラーメッセージ
は基本的に文字列として扱うことになる。
そのため、
- grep 的に処理する
- 行を分解する
- 条件分岐する
といった処理が、どうしても泥臭くなりがちだ。
PowerShell では、
コマンドの結果を オブジェクトとして扱える。
そのおかげで、
- 必要な情報だけを取り出す
- 条件を明確に書く
- ログを整理しやすい
といった点で、
「後から読み返して分かりやすいスクリプト」になりやすいと感じている。
日本語を含む処理が書きやすい
今回の文字化けの件で特に感じたのは、
日本語を含むメッセージやログを扱うなら、PowerShellのほうが気が楽だということ。
bat では、
- 表示はOKでもログで崩れる
- 実行環境によって挙動が変わる
といったケースを、どうしても意識しなければならない。
PowerShell では、
- 日本語メッセージ
- ファイル名
- ログ内容
を、そのまま扱っても問題になりにくい。
「文字化けしない前提」で書けるのは、
作業中のストレスをかなり減らしてくれる。
可読性という意味でも違いを感じる
bat は短い処理を書くには手軽だけれど、
処理が増えてくると、
- if の入れ子
- errorlevel の判定
- goto による分岐
などで、少し追いづらくなることがある。
PowerShell は、
- 処理の意図が読みやすい
- 条件分岐が素直
- 後から見ても流れを追いやすい
と感じる場面が多い。
特に「一度書いて終わり」ではなく、
後で修正する可能性がある作業では、差が出やすい。
それでもbatを使う場面はある
とはいえ、
PowerShell があれば bat は不要、というわけではない。
- 既存の bat 資産が多い
- 環境を選ばずすぐ動かしたい
- 本当に簡単な処理だけ
こういう場面では、今でも bat を選ぶことはある。
今回の件でも、
bat を Shift_JIS で保存し直せば問題なく動いた。
だからこそ、
「batが悪い」「PowerShellが正解」ではなく、
用途と場面の違いとして考えるのが大事だと感じている。
batでハマったからこそ見えたPowerShellの良さ
今回、bat の文字化けにハマったことで、
PowerShell の扱いやすさを改めて実感した。
- 文字コードを気にしなくていい
- 日本語が素直に扱える
- ログや結果を整理しやすい
こうした点は、
日常的な作業や運用スクリプトでは大きな差になる。
まとめ
bat ファイルで文字化けに遭遇したのをきっかけに、
PowerShell と比べてみて感じたのは、
- PowerShell は「考える前提」が少ない
- 日本語を扱う作業では特に安心感がある
- 少し複雑な処理なら PowerShell のほうが向いている
ということだった。
今後も bat を使う場面はあると思うけれど、
「日本語を含む」「後で直す可能性がある」作業では、
PowerShell を選ぶことが増えそうだと感じている。
コメント