02.1 文字コードとは何か — バイトと文字の対応表

ファイルの中身はバイトの並びでしかない

テキストファイルに保存されているのはバイト（0〜255 の数値）の並びだけです。「あ」という文字そのものが保存されているわけではありません。どのバイト列がどの文字を表すかを決めた対応表が「文字コード」です。

同じ「あ」でも、対応表が違えばバイト列は変わります。

Windows で登場する主な文字コード

問題の核心 — テキストファイルは文字コードを自己申告しない

ここが最大のポイントです。HTML や HTTP には文字コードを宣言する場所がありますが、プレーンテキストのファイルにはそれがありません。

<!-- HTML なら宣言できる -->
<meta charset="UTF-8">

# HTTP なら宣言できる
Content-Type: text/plain; charset=UTF-8

# ただのテキストファイル（.ps1 .txt .csv）には宣言する場所がない
Write-Host "こんにちは"

宣言がないので、読み込む側は「たぶんこの文字コードだろう」と推測するしかありません。その推測ルールが処理系ごとに違うことが、02.2 で扱う問題の正体です。

BOM — 唯一の明示的な手がかり

BOM（Byte Order Mark）は、ファイルの先頭に置く数バイトの目印です。文字としては表示されず、「このファイルはこの文字コードです」という宣言としてだけ働きます。

つまり BOM は「自己申告できないテキストファイル」に唯一つけられる名札です。次の章で見るとおり、PowerShell はこの名札の有無で挙動を変えます。

02.2 なぜ ps1 は BOM 付き UTF-8 なのか

5.1 と 7 で、推測ルールが逆になっている

PowerShell がスクリプトファイルを読むとき、BOM があればそれに従います。問題はBOM がなかったときです。ここで 5.1 と 7 は正反対の推測をします。

この違いを保存形式ごとに整理すると、次のようになります。

実務で最も遭遇する事故 — 「pwsh に変えたら化けた」

図の3行目に注目してください。Shift-JIS の ps1 は 5.1 では動くのに、7 では壊れます。

• 事故1長年 5.1 で動かしていた Shift-JIS のスクリプトを、PowerShell 7 で実行したら日本語が全部化けた
• 事故2PowerShell 7 の環境で作った BOM なし UTF-8 のスクリプトを、同僚の 5.1 に渡したら化けた

どちらも「自分の環境では動く」ため、渡した側は気づけません。BOM 付き UTF-8 で統一しておけば、両方とも起きません。

保存方法

VS Code の場合

右下のステータスバーに現在のエンコーディング（UTF-8 など）が表示されています。クリックして ［エンコード付きで保存］→［UTF-8 with BOM］を選びます。

PowerShell から書き出す場合 要注意

ここに同じ名前で結果が違うという罠があります。

# Windows PowerShell 5.1
Set-Content -Path .\a.ps1 -Value $text -Encoding UTF8      # → BOM 付き UTF-8

# PowerShell 7
Set-Content -Path .\a.ps1 -Value $text -Encoding utf8      # → BOM なし UTF-8（！）
Set-Content -Path .\a.ps1 -Value $text -Encoding utf8BOM   # → BOM 付き UTF-8

確認方法

BOM が付いているかは、先頭3バイトを見れば分かります。

# 先頭 3 バイトが EF BB BF なら BOM 付き UTF-8
Get-Content .\a.ps1 -AsByteStream -TotalCount 3          # pwsh 7
Get-Content .\a.ps1 -Encoding Byte -TotalCount 3         # 5.1

-AsByteStream は 7 で追加された指定で、5.1 の -Encoding Byte に相当します。pwsh 7

02.3 なぜ CRLF なのか

改行にも3つの流儀がある

「改行」も画面上は見えませんが、実体はバイトです。歴史的な経緯から3種類が存在します。

正直に言うと、ps1 は LF でも動く

ここは誤解されやすい点なので明確にしておきます。PowerShell スクリプト自体は LF 改行でも問題なく動作します。5.1 でも 7 でも同じです。

ではなぜ CRLF に揃えるのか。理由は3つあります。

Git を使うなら core.autocrlf に注意

Git には、コミット時とチェックアウト時に改行コードを自動変換する設定があります。これが意図せず有効だと、手元では CRLF なのにリポジトリ上は LFという状態になります。

より確実なのは .gitattributes で拡張子ごとに固定する方法です。

# .gitattributes
*.ps1  text eol=crlf
*.bat  text eol=crlf
*.cmd  text eol=crlf

JavaScript / Node.js との違い

Node.js のプロジェクトでは LF が標準です。Prettier や ESLint の既定も LF で、CRLF だと警告が出ます。同じ PC で PowerShell 資材と Node.js 資材の両方を扱うときは、拡張子ごとに使い分けるのが現実的です。

02.4 ps1 / bat / cmd の使い分けとランチャー

3つの拡張子の役割

冒頭の「この資料に出てくるファイルの種類」で触れた3種類を、ここまでに分かった文字コード・改行の観点で整理し直します。

.bat と .cmd はほぼ同じです。.cmd のほうが新しく、内部コマンド実行後の ERRORLEVEL の扱いがわずかに整理されています。新規に作るなら .cmd で構いません。

ps1 はダブルクリックで動かない

これは仕様です。.ps1 の既定の関連付けは「実行」ではなく「編集」になっています。スクリプトを不用意にダブルクリックして実行してしまう事故を防ぐための設計です。

加えて実行ポリシーという別の制限もあり、既定の設定ではスクリプトファイルの実行自体がブロックされます（詳しくは 03 章）。

そこで、ダブルクリックで動かしたい ps1 には、同名の cmd ランチャーを添えます。

ランチャーの中身

@echo off
powershell.exe -NoProfile -ExecutionPolicy Bypass -File "%~dp0foo.ps1"
pause

PowerShell 7 で動かしたい場合 pwsh 7

実行ファイル名を変えるだけです。

@echo off
pwsh.exe -NoProfile -ExecutionPolicy Bypass -File "%~dp0foo.ps1"
pause

配布先に 7 が入っている保証がないなら、powershell.exe のままにしておくのが安全です。