Windows×Linux間の文字化けを根本解決する

まず押さえたいこと

文字化けは「日本語が難しいから」起きるのではありません。同じバイト列を別の文字コードとして読んだ、または誤って読んだ結果を別の文字コードで保存したことが原因です。

重要な6点:

1. 文字化けは「文字」の問題ではなく「バイト列の解釈」の問題
2. Windows には Unicode 系と legacy code page 系が共存している
3. Linux 側は UTF-8 前提が強いため、CP932 や UTF-16 が混ざると事故になる
4. 表示が崩れた段階と壊れた内容を保存した段階は別問題
5. 新規テキストは UTF-8 を第一候補に、既存の legacy ファイルは現状維持が安全
6. ファイルの encoding、エディタの encoding、コンソールの code page、アプリ内部の文字列形式は別物

文字化けの正体

文字化けの仕組みは単純です:

1. 文字列をある文字コードで encode（符号化）してバイト列にする
2. バイト列を別の文字コードで decode（復号）して文字列に戻す
3. encode と decode の前提が合わなければ、別の文字列として読まれる

例: あ を UTF-8 で保存 → バイト列 E3 81 82。これを CP932 として読むと 縺� のように見える。

表示が崩れただけならまだ戻せる

元のバイト列が変わっていなければ、正しい encoding で開き直せば戻せます。危ないのは「見えている文字列」をそのまま保存して、元のバイト列が失われることです。

さらに危ないのは「表現できない文字」を狭い code page に落とすとき

CP932 に存在しない Unicode 文字が ? や � に置き換わると、後から復元できません。

なぜ Windows ではややこしくなりやすいのか

Windows には Unicode の世界と legacy code page の世界が同居しています。

Windows API には2系統ある:

• W 系: wide character。Unicode を UTF-16 で扱う
• A 系: ANSI（code page 系）

Windows の日本語でよく混ざる4つ:

• CP932: 日本語 Windows の legacy text
• UTF-8: 新しいテキスト、Web、クロスプラットフォーム系
• UTF-16LE: Windows 系ツールや API で使われる
• コンソールの code page: cmd.exe の入出力に影響する別レイヤ

注意: chcp 65001 でコンソールの code page を変えても、既存ファイルの encoding は変わりません。

ファイル名とファイル内容は別問題

• パス/ファイル名を扱う層
• ファイルの中身を読む層
• コンソールに表示する層

この3つは別々です。日本語パスが扱えても、中身が CP932 なら Linux 側で壊れます。

PowerShell の版差にも注意

• Windows PowerShell 5.1: 既定 encoding が一貫していない（UTF-16LE や ANSI）
• PowerShell 7 以降: UTF-8 no BOM が既定

Linux と組み合わせたときの典型事故

1. Windows の CP932 ファイルを Linux が UTF-8 として読む

最も多い事故。Legacy アプリが CP932 で書いた CSV/TXT を、Linux のツールが UTF-8 前提で読んで文字化け。

2. UTF-8 no BOM ファイルを Windows が ANSI 扱い

Linux や VS Code で作った UTF-8 no BOM ファイルを、PowerShell 5.1 や古いツールが ANSI として読み、日本語行だけ壊れる。

3. UTF-16LE を Linux 側で読む

PowerShell 5.1 の一部出力や古いツールが UTF-16LE を書き、Linux 側では NUL バイト混じりのバイナリに見える。

4. BOM の有無による摩擦

Windows ツールは BOM があると助かるが、Linux ツールは BOM を先頭のゴミとして扱う。

5. コンソールの見え方を信じると迷う

「コンソールで読めたからファイルも大丈夫」「コンソールで崩れたから壊れている」は危険。表示と実バイトは別に確認する必要があります。

文字化け調査の4つの質問

1. 元のバイト列は何か - UTF-8 / CP932 / UTF-16LE のどれか
2. 誰がどの前提で書いたか - Windows legacy / PowerShell / Linux / VS Code など
3. 誰がどの前提で読んでいるか - 自動検出か明示指定か
4. 読み間違えた内容がすでに保存されたか - 表示だけか、データ破損か

この4問が埋まれば、たいてい原因は見えます。

事故を減らす運用ルール

1. 新規ファイルは UTF-8 を第一候補に - BOM を付けるかどうかも決める
2. 既存 legacy ファイルは明示的な移行タスクまで維持 - ついでの UTF-8 化をしない
3. encoding をインターフェイスの一部として扱う - 「テキストで渡す」は仕様になっていない
4. 書き込み時は encoding を明示する - 既定値任せにしない
5. コンソールとファイルを分けて確認する - 表示確認と再オープン確認は別
6. Git は encoding を直してくれない - 壊れたバイト列もそのまま履歴に入る

まとめ

• 文字化けはバイト列の解釈ずれ
• 表示崩れとデータ破損は別
• Windows ではファイル / エディタ / コンソール / API の層を分けて考える
• Linux とやり取りするテキストは UTF-8 を第一候補に
• 既存 legacy ファイルの変換は通常改修と分ける

文字コードは地味ですが、Windows と Linux の間では I/O 契約そのものです。