知識マップ: Windowsの文字コードと改行コード - 文字化けとCRLF/LFの基本

記事「Windowsの文字コードと改行コード - 文字化けとCRLF/LFの基本」の主張を、概念と関係(エッジ)に分解した知識グラフの全体です。各関係には根拠・確認日・確度が付いています。

Windowsのテキストはバイト列・文字コード・改行コード・BOMという別々の軸の組み合わせで成り立ち、UTF-8やUTF-16LEはUnicodeの符号点をバイト列にする文字コードである一方、CP932は日本語Windows独自のレガシーコードページで両者は前提を取り違えると文字化けを起こす。BOMはUTF-16のバイト順を示す目印であると同時に、UTF-8では「UTF-8である」というシグネチャとして使われ、Windows PowerShell 5.1は非ASCII文字を含むスクリプトを正しく読むためにBOMを必要とする。改行コードはCRLFとLFのどちらかで文字コードとは別問題であり、リポジトリ単位の扱いは.gitattributesで固定できるが、Gitは改行こそ変換しても文字コードは自動で正してくれない。文字化けは正しい文字コードで開き直せば戻ることが多いが、誤読した内容をそのまま保存すると元のバイト列が失われ、表示崩れではなく取り返しのつかないデータ破損になる。

flowchart LR
    accTitle: Windowsの文字コードと改行コードの知識マップ
    accDescr: UnicodeとUTF-8・UTF-16LE・CP932の関係、BOMの役割、文字化けとデータ破損の違い、PowerShellの既定値やGitの改行変換が改行コードと文字コードそれぞれにどう効くかを示す図。
    character_encoding["文字コード(キャラクターエンコーディング)"]
    line_ending["改行コード"]
    unicode["Unicode"]
    utf_8["UTF-8"]
    utf_16le["UTF-16LE"]
    cp932["CP932"]
    active_code_page["アクティブコードページ(ANSI/ACP)"]
    bom["BOM(Byte Order Mark)"]
    mojibake["文字化け"]
    powershell_text_encoding["PowerShellの文字コード既定値"]
    gitattributes[".gitattributes"]
    reencoding_data_loss["誤読内容の再保存によるデータ破損"]
    character_encoding -.->|"利用する"| unicode
    character_encoding -->|"利用する"| utf_8
    character_encoding -->|"利用する"| utf_16le
    character_encoding -->|"利用する"| cp932
    character_encoding -->|"利用する"| active_code_page
    character_encoding -.->|"利用する"| bom
    character_encoding -->|"原因になり得る"| mojibake
    utf_8 -->|"実装を担う"| unicode
    utf_16le -->|"実装を担う"| unicode
    cp932 -.->|"両立しない"| utf_8
    cp932 -.->|"原因になり得る"| mojibake
    active_code_page -.->|"両立しない"| utf_8
    utf_16le -.->|"両立しない"| active_code_page
    bom -->|"利用する"| unicode
    powershell_text_encoding -.->|"利用する"| utf_8
    powershell_text_encoding -.->|"利用する"| active_code_page
    powershell_text_encoding -.->|"前提とする"| bom
    line_ending -.->|"で構成できる"| gitattributes
    mojibake -.->|"原因になり得る"| reencoding_data_loss

概念間の関係(全19件)

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

• 文字コード(キャラクターエンコーディング)はUnicodeを利用します。UTF-8やUTF-16のような現代の文字コードでは、Unicodeは文字を番号で表す枠組みであり、これらの文字コードがこれをバイト列に変換する(CP932のようなUnicode以前のレガシーコードページはUnicodeを介さない) / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• 文字コード(キャラクターエンコーディング)はUTF-8を利用します。現代のWindows実務では新規テキストの第一候補としてUTF-8を使う / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 文字コード(キャラクターエンコーディング)はUTF-16LEを利用します。Windows APIやPowerShellの一部の出力は既定でUTF-16LEを使う / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 文字コード(キャラクターエンコーディング)はCP932を利用します。日本語Windowsのレガシーテキストは実務ではCP932として意識したほうが安全である / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 文字コード(キャラクターエンコーディング)はアクティブコードページ(ANSI/ACP)を利用します。Windowsの「ANSI」という表記は多くの場合そのマシンのアクティブコードページを指す / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 文字コード(キャラクターエンコーディング)はBOM(Byte Order Mark)を利用します。UTF-8やUTF-16のようなUnicode系の文字コードでは、仕様はBOMの有無まで決めて初めて運用ルールとして成立する(CP932のようなレガシーコードページにはBOMの概念自体がない) / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• 文字コード(キャラクターエンコーディング)は文字化けの原因になることがあります。書き込み時と読み込み時で前提とする文字コードが一致しないと文字化けが起きる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• UTF-8はUnicodeの実装を担います。UTF-8はUnicodeの符号点を1〜4バイトの可変長バイト列にエンコードする文字コードである / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• UTF-16LEはUnicodeの実装を担います。UTF-16LEはUnicodeの符号点を2バイト単位のリトルエンディアンでエンコードする文字コードである / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• CP932はUTF-8と両立しません。非ASCII文字を含む場合、同じバイト列をUTF-8として書きCP932として読む、またはその逆をすると、正しい文字列に戻らない(ASCII範囲のみのバイト列はどちらの前提で読んでも一致するため問題は表面化しない) / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• CP932は文字化けの原因になることがあります。UTF-8で書かれたバイト列をCP932の前提で読むと、別の文字列に見える文字化けが起きる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• アクティブコードページ(ANSI/ACP)はUTF-8と両立しません。非ASCII文字を含むUTF-8のファイルをアクティブコードページの前提で読むと、文字化けが起きる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• UTF-16LEはアクティブコードページ(ANSI/ACP)と両立しません。UTF-16LEのログをアクティブコードページ前提のツールへ渡すと、NULバイトが混ざるなど文字化けの一種として見える / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• BOM(Byte Order Mark)はUnicodeを利用します。BOMはUnicodeが定めるU+FEFFという符号点をファイル先頭に置く目印である / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• PowerShellの文字コード既定値はUTF-8を利用します。PowerShell 6以降では、すべてのテキスト出力の既定がutf8NoBOM(UTF-8 BOMなし)である(Windows PowerShell 5.1はコマンドレットごとに既定がそろっていない) / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• PowerShellの文字コード既定値はアクティブコードページ(ANSI/ACP)を利用します。Windows PowerShell 5.1では、BOMのないファイルをGet-Contentやスクリプト読み込みでアクティブコードページとみなす(PowerShell 6以降はutf8NoBOMに統一されており該当しない) / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• PowerShellの文字コード既定値はBOM(Byte Order Mark)を前提とします。Windows PowerShell 5.1で、非ASCII文字を含むスクリプトファイルを実行する場合に限り、BOMがないとアクティブコードページとして読まれてスクリプトが壊れる(PowerShell 6以降はutf8NoBOMに統一されているため該当しない) / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• 改行コードは.gitattributesで構成できます。Gitリポジトリで管理する場合、リポジトリ単位の改行コードの扱いは.gitattributesで固定できる(Git管理下にないテキストファイルの改行コードには関与しない) / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• 文字化けは誤読内容の再保存によるデータ破損の原因になることがあります。文字化けして見える内容に気づかずそのまま保存すると、元のバイト列が失われ表示崩れではなくデータ破損になる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典

主要概念の定義

文字コード(キャラクターエンコーディング)

文字列をバイト列として保存・伝送するための対応規則。Unicodeのような文字集合をどうバイト列にするかを定めるUTF-8やUTF-16、Windows独自のCP932のようなレガシーコードページなどが含まれる。

改行コード

行の区切りに使うバイト列。WindowsではCRLF(0D 0A)が伝統的で、Linux/macOSではLF(0A)が一般的。文字コードとは別の軸で決まり、同じ文字コードのファイルでも改行だけがCRLFとLFの間でずれることがある。

UTF-8

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

UTF-16LE

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

CP932

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

アクティブコードページ(ANSI/ACP)

Windowsの「ANSI」という表記が多くの場合指す、そのマシンに設定されている既定のコードページ。日本語環境では通常CP932になる。

BOM(Byte Order Mark)

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

PowerShellの文字コード既定値

PowerShellのコマンドレットが読み書きに使う既定の文字コード。PowerShell 6以降はutf8NoBOMに統一されている一方、Windows PowerShell 5.1はコマンドレットごとに既定がそろっていない。

文字化け

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

機械可読データ

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

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