知識マップ: Windows文字コード入門 - Linux連携で起きる文字化け

記事「Windows文字コード入門 - Linux連携で起きる文字化け」の主張を、概念と関係(エッジ)に分解した知識グラフの全体です。各関係には根拠・確認日・確度が付いています。

Windowsの文字化けは、CP932で保存したバイト列をUTF-8として読む、あるいはその逆というencodeとdecodeの前提のずれから生じ、方向によって崩れ方の症状が異なります。Windows PowerShellは5.1と7以降で既定のencodingが割れており、Out-FileがUTF-16LEを、Set-ContentがCP932を書くといった経路ごとの違いが事故の温床になります。Linux側はlocaleに従いUTF-8を前提に読むため、CP932やBOM付きUTF-8を渡すと文字化けやデータ破損につながり、WSLのように両者が同居する環境ではとくに起きやすくなります。元のバイト列が残っていればiconvやPowerShellで正しいencodingとして読み直し書き出すことで復旧できますが、誤読した内容を保存してしまうと復元できません。記事は新規ファイルをUTF-8第一候補にし、encoding自体をI/Oの契約として明文化する運用を推奨しています。

flowchart LR
    accTitle: Windowsの文字化けとLinux連携の知識マップ
    accDescr: 同じバイト列をCP932とUTF-8のどちらで読むかで文字化けの症状が変わること、BOMやUTF-16LEやコンソールのコードページが独立した層であること、PowerShellのバージョンで既定のencodingが異なること、iconvやPowerShellによる復旧とUTF-8を第一候補にする運用方針の関係を示す図
    mojibake["文字化け"]
    cp932["CP932"]
    utf_8["UTF-8"]
    utf_16le["UTF-16LE"]
    bom["BOM(Byte Order Mark)"]
    encoding_overwrite_corruption["誤読内容の上書き保存によるデータ破損"]
    console_code_page["コンソールのコードページ"]
    windows_powershell_5_1["Windows PowerShell 5.1"]
    powershell_7["PowerShell 7"]
    iconv["iconv"]
    powershell["PowerShell"]
    linux_locale["Linuxのlocale"]
    wsl["WSL(Windows Subsystem for Linux)"]
    encoding_as_interface["encodingをI/O契約として明文化する運用"]
    utf8_first_policy["新規ファイルをUTF-8第一候補にする運用方針"]
    cp932 -.->|"原因になり得る"| mojibake
    utf_8 -.->|"原因になり得る"| mojibake
    utf_16le -.->|"原因になり得る"| mojibake
    bom -.->|"原因になり得る"| mojibake
    mojibake -.->|"原因になり得る"| encoding_overwrite_corruption
    console_code_page -.->|"原因になり得る"| mojibake
    windows_powershell_5_1 -->|"利用する"| utf_16le
    windows_powershell_5_1 -->|"利用する"| cp932
    powershell_7 -->|"利用する"| utf_8
    iconv -.->|"軽減する"| mojibake
    powershell -.->|"軽減する"| mojibake
    mojibake -->|"で確認できる"| iconv
    linux_locale -.->|"利用する"| utf_8
    wsl -->|"利用する"| linux_locale
    wsl -.->|"原因になり得る"| mojibake
    encoding_as_interface -->|"推奨される対応"| mojibake
    utf8_first_policy -->|"推奨される対応"| mojibake

概念間の関係(全17件)

図と同じ関係を文章でも列挙します。表示している文と機械可読な意味データ(RDFa)は同じ要素に載っています。確度が「確立した関係」のものは直接の関係として、「条件付きの関係」のものは成立条件つきの言明(rdf:Statement)として表現しています。

• CP932は文字化けの原因になることがあります。CP932で保存したバイト列をUTF-8の前提で読むと、それらしい漢字やカタカナが並ぶ形の文字化けになる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• UTF-8は文字化けの原因になることがあります。UTF-8で保存したバイト列をCP932の前提で読むと、置換文字だらけの文字化けになる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• UTF-16LEは文字化けの原因になることがあります。PowerShellの一部の書き込み経路が出すUTF-16LEを、UTF-8の1バイトストリームを想定するLinux側のツールに渡すと、NUL byteが混ざったバイナリのような文字化けになる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• BOM(Byte Order Mark)は文字化けの原因になることがあります。UTF-8のBOMを余計な先頭バイト列として扱うツールを通すと、先頭列や先頭行だけ壊れて見える / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• 文字化けは誤読内容の上書き保存によるデータ破損の原因になることがあります。文字化けして見える内容に気づかずそのまま保存すると、元のバイト列が失われ単なる表示崩れではなくデータ破損になる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• コンソールのコードページは文字化けの原因になることがあります。ファイルの実際のencodingとコンソールの入出力code pageが食い違うと、ファイル自体は無事でも表示だけ崩れて見える / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• Windows PowerShell 5.1はUTF-16LEを利用します。Windows PowerShell 5.1のOut-Fileやリダイレクト(>、>>)は既定でUTF-16LE(BOM付き)を書き込む / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Windows PowerShell 5.1はCP932を利用します。Windows PowerShell 5.1のSet-Content/Add-Contentは、新規または空ファイルに対し既定でANSI(日本語環境ではCP932)を書き込む / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• PowerShell 7はUTF-8を利用します。PowerShell 7以降はOut-File・Set-Content等の書き込み経路の既定がUTF-8 no BOMに統一されている / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• iconvは文字化けを軽減します。元のバイト列が残っていれば、正しいencodingを指定してiconvで読み直しUTF-8などへ変換することで文字化けを解消できる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• PowerShellは文字化けを軽減します。PowerShell 6.2以降は-Encodingにcode page番号(CP932なら932)を直接指定でき、Get-ContentとSet-Contentを組み合わせてencodingを変換できる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• 文字化けはiconvで確認できます。変換元のencoding指定を誤るとiconvはillegal input sequenceで処理を止めるため、指定したencodingがファイルの実体と異なることを確認する手がかりになる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• LinuxのlocaleはUTF-8を利用します。多くのLinux環境では、localeがja_JP.UTF-8のようにLANGやLC_ALLでencodingまで含めて既定の文字コードを定め、UTF-8が前提になる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• WSL(Windows Subsystem for Linux)はLinuxのlocaleを利用します。WSL上のLinux側はlocaleに従いUTF-8前提で動作するため、Windows側の文字コードの前提とぶつかりやすい / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• WSL(Windows Subsystem for Linux)は文字化けの原因になることがあります。WSLはWindows側とLinux側の文字コードの前提が1台の中に同居する環境であり、この記事が扱う文字化け事故が起きやすい / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• encodingをI/O契約として明文化する運用は文字化けに対する本記事の推奨です。CSVやログなどのencoding・BOM有無・改行コードを仕様として明文化しておくことは、文字化け事故を防ぐための本記事の推奨対応である / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 新規ファイルをUTF-8第一候補にする運用方針は文字化けに対する本記事の推奨です。新規テキストファイルのencodingとしてまずUTF-8を第一候補にすることは、Windows全体の推奨方針であり文字化け事故を減らす対応でもある / 確度: 確立した関係 / 確認日: 2026-08-01 出典

主要概念の定義

文字化け

実際のバイト列の解釈が意図したencodingとずれ、表示や内容が壊れて見える状態。

CP932

Windowsの日本語コードページ(コードページ番号932)。実務上はWindows版のShift_JISに近いが、他システムのShift_JIS実装と1バイトも違わない保証はない。

UTF-8

Unicodeの可変長エンコーディング方式。バイト列に強い制約があるため、CP932など他のエンコーディングのバイト列は厳密デコードで失敗しやすい。

UTF-16LE

Unicodeの符号点を2バイト単位のリトルエンディアンで表す文字コード。Windows APIやPowerShellの一部コマンドレットの既定出力に使われる。

BOM(Byte Order Mark)

ファイル先頭に置かれ、どのUnicodeエンコーディングかを示す数バイトの目印。UTF-8はEF BB BF、UTF-16 LEはFF FE、UTF-16 BEはFE FF。

コンソールのコードページ

cmd.exeなどコンソールの入出力に適用されるcode page。ファイル自体のencodingとは独立したレイヤー。

Windows PowerShell 5.1

Windowsに標準で同梱されている、.NET Framework上に構築されたレガシー世代のPowerShell(5.1系)のランタイム。実行ファイルはpowershell.exeで、.NETアプリからはMicrosoft.PowerShell.5.1.ReferenceAssembliesを介して呼び出せる。

PowerShell 7

PowerShell Core系譜の最新世代で、.NET(Core以降)上に構築されたPowerShellのエディション。実行ファイルはpwsh.exeで5.1のpowershell.exeとサイドバイサイドに共存し、Out-File・Set-Content・Export-Csvなどの既定書き込みencodingはBOMなしUTF-8である。

iconv

指定したencoding間でテキストのバイト列を変換するLinux/Unix系のコマンドラインツール。

PowerShell

オブジェクトパイプラインとエラー処理機構を持つ、Microsoftが最も堅牢で最新のWindows自動化に推奨するコマンドラインシェル兼スクリプト言語。

Linuxのlocale

言語・地域・文字コードの既定をまとめたLinuxの設定。多くはUTF-8をencodingとして含む。

WSL(Windows Subsystem for Linux)

Windows上でLinux環境を動かす仕組み。Windows側とLinux側の文字コードの前提が1台の中で同居する。

encodingをI/O契約として明文化する運用

CSVやログなどの受け渡しにおいて、encoding・BOM有無・改行コードを内容と同様に仕様として明記しておく運用方針。

新規ファイルをUTF-8第一候補にする運用方針

新規に作成するテキストファイルのencodingとして、まずUTF-8を第一候補として選ぶ運用方針。

機械可読データ

• JSON-LD / Turtle ── この記事の知識グラフ全体
• 概念一覧 / 語彙(述語)の定義

このページはサイトの知識グラフ(_data/knowledge/)から自動生成されています。誤りの指摘はお問い合わせからお願いします。