初級では「名札（拡張子）・中身（0と1）・読み方（形式）・担当（アプリ）」の4点セットを見ました。ここでは中身側の証拠と読み方の決まりの実名に踏み込みます。読み終わる頃には、文字化けと「開けないファイル」を理屈で切り分けられるはずです。
用語には「※1・※2…」と番号を付けて、各セクション末尾の「登場人物メモ」で説明します。
概要 — まず全体をつかむ
アニメーション『ダブルクリックの3秒』を開く
- あなた — ファイルをダブルクリックする人
- OS — 名札（拡張子）を見て、開く係を決める世話役
- アプリ — そのファイルの「読み方」を知っている担当者
- ファイルの中身 — 実体はどれもただの0と1の列。読み方を知る係が必要
0 / 7
詳細 — 1段階ずつ追う
① 名札を見る
🎬 アニメーション『ダブルクリックの3秒』の ② のところです！
名札は拡張子だけではありません。世界には3種類の「種別の伝え方」があります:
- 拡張子 — ファイル名の一部。OSのダブルクリック判定が見る（自己申告）
- マジックナンバー※1 — ファイル先頭の決まったバイト列。中身側の証拠で、
fileコマンドやアップロード検証が見る - MIMEタイプ※2 — Webの世界の種別宣言。HTTPレスポンスの
Content-Typeヘッダで配信側が宣言し、ブラウザはこれに従う
登場人物メモ（※の説明）:
- ※1 マジックナンバー — PNGなら
89 50 4E 47、ZIPなら50 4B、PDFなら%PDFなど、形式ごとの署名。名札と違って中身に埋まっている - ※2 MIMEタイプ —
text/htmlimage/pngのような「大分類/小分類」表記。名前の由来はメールだが、今はWeb全体の標準
⚠️ イレギュラー（3つの証言が食い違うとき）:
- 名札と中身の不一致 — 拡張子は .png なのに先頭バイトはJPEG、のようなファイルは検証のあるシステムで弾かれる。逆に検証しないシステムは偽装ファイルの侵入口になる
- ブラウザの推測（MIMEスニッフィング） — 宣言が曖昧なとき、ブラウザが中身から推測する機能。便利だが「テキストのふりをした攻撃コード」の実行につながるため、無効化を宣言するヘッダ（X-Content-Type-Options: nosniff）が存在する
この部分をもっと深く（上級）
🎬 アニメーション『ダブルクリックの3秒』の ② のところです！
上級では「名札を信じない」立場から、種別を確かめる3系統を精密にします。
- 拡張子 — ファイル名の末尾。送り手が自由に付けられる自己申告で、証拠能力はない
- マジックナンバー※1 — ファイル先頭の固定バイト列。形式の仕様が定めた署名で、中身に埋まっている物証
- MIMEタイプ※2 — 「型/サブ型」の正式名。通信（HTTPのContent-Typeヘッダ）やアプリ間で形式を伝える宣言
種別を厳密に判定したいプログラムは、名札ではなく先頭バイトを読む。UNIX系の file コマンドや、サーバのアップロード検証がこれです。拡張子・マジックナンバー・MIMEタイプは互いに独立しており、一致する保証はない——その隙間こそが、後で見る偽装の余地になります。
登場人物メモ（※の説明）:
- ※1 マジックナンバー（ファイルシグネチャ） — PNGは
89 50 4E 47、ZIPは50 4B、PDFは％PDF、ELF実行形式は7F 45 4C 46など、形式ごとに決まった先頭バイト列。中身側の物証 - ※2 MIMEタイプ（メディアタイプ） —
image/pngtext/htmlのような「大分類/小分類」表記。名前の由来はメール（Multipurpose Internet Mail Extensions）だが、今はWeb全体の標準
⚠️ イレギュラー（3つの証言が食い違うとき）:
- 署名を持たない形式 — プレーンテキストやCSVには決まった先頭署名がない。中身推測に頼るしかなく、判定が曖昧になる
- 署名を偽装したファイル — 先頭に本物の署名を貼り付けつつ、後続に別の中身を仕込むこともできる。署名の一致は「入口の一致」であって、全体の安全ではない
中身が結局すべて0と1であることは 2進数とデータ を参照。
やさしく言うと（初級）
🎬 アニメーション『ダブルクリックの3秒』の ② のところです！
ファイル名の . より後ろが拡張子です。report.pdf なら pdf、cat.jpg なら jpg。
- ダブルクリックの瞬間、OSは拡張子だけを見る
- 中身はこの時点では読んでいない
- だから拡張子は「中身の種類を示す自己申告の名札」にすぎない
名札は自己申告なので、書き換えても中身は1ビットも変わりません。cat.jpg を cat.txt に改名しても、写真のデータはそのまま——ただ、担当がメモ帳に変わって、ぐちゃぐちゃの文字が表示されるだけです。
⚠️ イレギュラー（名札にだまされるとき）:
- 二重の名札「請求書.pdf.exe」 — 効くのは最後の名札だけ。正体はPDFを装った実行プログラムで、開くと実行されてしまう。ウイルスの古典的な手口
- 名札が見えていない — OSの初期設定では拡張子が非表示のことがある。上の手口が「請求書.pdf」に見えてしまうので、拡張子は表示する設定にするのが安全
② 対応表を引く
🎬 アニメーション『ダブルクリックの3秒』の ③〜④ のところです！
OSの対応表と、その周辺の実装です:
- OSは「拡張子 → 既定のアプリ」の対応表を持つ（Windowsはレジストリ、macはLaunchServicesが管理）
- 「常にこのアプリで開く」は、この表の1行の書き換え
- アプリをインストールすると、アプリが「自分は .pdf を開けます」と候補登録する——既定を奪い合う通知が出るのはこのため
- ダブルクリック以外の入り口（コマンドラインや「プログラムから開く」）は表を経由せず、任意のアプリに任意のファイルを渡せる
⚠️ イレギュラー（対応表まわりの事故）:
- 既定アプリの乗っ取り — インストール時に関連付けを一斉に自分へ向けるお行儀の悪いソフトがある。急に開くアプリが変わったらここを疑う
- 二重拡張子 + 非表示設定 — 初級で見た「請求書.pdf.exe」。OSの既定が拡張子非表示だと成立してしまうので、表示設定が対策になる
この部分をもっと深く（上級）
🎬 アニメーション『ダブルクリックの3秒』の ③〜④ のところです！
「拡張子→アプリ」の対応表を、OSは具体的にどこに持っているか。機構はOSごとに違います。
- Windows — レジストリ（設定を集約した階層データベース）に「拡張子→ファイルタイプ→開くアプリ」を記録する。
.pdfの担当変更は、この階層の書き換え - Linux — xdg-mime の仕組み。拡張子や中身からMIMEタイプを求め、
mimeapps.listで「このMIMEタイプ→この既定アプリ」を引く。拡張子を直接ではなく、いったんMIMEタイプを介すのが特徴 - macOS — かつてのUTI※1（形式の抽象的な型）とLaunchServices※2 が、拡張子・種別・担当アプリを対応づける
- どのOSでも、コマンドラインや「プログラムから開く」は表を経由せず、任意のアプリに任意のファイルを渡せる
共通する構図は「関連付けはファイルではなくOSのローカル設定」。だから同じ拡張子でも人のPCで担当アプリが違い、世界共通の一元データベースは存在しません。
登場人物メモ（※の説明）:
- ※1 UTI — Uniform Type Identifier。macOSが使う「形式の型」の識別子。拡張子やMIMEタイプを一段抽象化したもの
- ※2 LaunchServices — macOSで「どの種別をどのアプリが開くか」を管理する仕組み
⚠️ イレギュラー（関連付けまわりの事故）:
- 既定アプリの乗っ取り — インストール時に関連付けを一斉に自分へ向けるお行儀の悪いソフトがある。急に開くアプリが変わったらここを疑う
- MIMEと拡張子のズレ（Linux／Web） — MIMEタイプを軸にする機構では、拡張子と中身から求めたMIMEタイプが食い違うと、意図しないアプリが選ばれることがある
OSがアプリを起動して橋渡しする流れは アプリとOS を参照。
やさしく言うと（初級）
🎬 アニメーション『ダブルクリックの3秒』の ③〜④ のところです！
OSは「この名札は、このアプリの担当」という対応表を持っています。
.pdf→ PDF閲覧アプリ、.jpg→ 画像ビューア、.mp3→ 音楽プレイヤー- OSは表で引いた担当アプリを起動して、ファイルの場所を渡す
- 右クリックの「プログラムから開く」は、この対応表を無視して手動で担当を選ぶ操作
- そこで「常にこのアプリを使う」を選ぶと、対応表そのものが書き換わる
同じ .pdf でも、人のPCによって開くアプリが違うのはこのためです。対応表はファイルではなくOSが持っている——ここを押さえると設定画面の意味が読めるようになります。
③ アプリが解読する
🎬 アニメーション『ダブルクリックの3秒』の ⑤〜⑦ のところです！
「読み方の決まり」の実名はファイルフォーマット仕様です。解読には層があります:
- まず大きくテキストかバイナリ※1 かに分かれる
- テキストの解読には文字コード※2 が要る——「このバイト列はこの文字」の対応表。UTF-8 が現在の標準で、Shift_JIS などの旧規格と取り違えると文字化けになる（データは無傷、読み方の取り違え）
- バイナリは形式ごとの仕様書どおりに解読する。多くの形式は圧縮※3 も組み込んでいて、可逆（ZIP・PNG）と非可逆（JPEG・MP3）で性格が違う
- 変換（.jpg → .png）とは、デコードして別の決まりで再エンコードすること。改名では起きない
登場人物メモ（※の説明）:
- ※1 テキスト / バイナリ — 文字コード表だけで人間が読める形式か、専用の仕様書が要る形式かの大別
- ※2 文字コード — バイト列と文字の対応表。UTF-8 / Shift_JIS / EUC-JP など。取り違え=文字化け
- ※3 可逆 / 非可逆圧縮 — 完全に戻せる圧縮（ZIP・PNG）と、知覚しにくい情報を捨てて縮める圧縮（JPEG・MP3）。非可逆は保存のたびに劣化が積む
⚠️ イレギュラー（解読の事故）:
- 文字化け — 原因は必ず「書いた文字コード ≠ 読んだ文字コード」。正しいコードで開き直せば直る（データは壊れていない）
- JPEGの再保存劣化 — 非可逆圧縮を重ね掛けするたび情報が捨てられる。編集の元データはPNG等の可逆形式で持つのが定石
「fileコマンド」で中身の正体を見る
Linux/Macのターミナルで file 名前 と打つと、拡張子を無視してマジックナンバーから種別を判定してくれます。cat.txt に改名した画像も JPEG image data と見破ります。名札（拡張子）・中身（マジックナンバー）・読み方（フォーマット）が別物であることを、手元で1分で確認できる実験です。
まとめ——種別の証言は名札（拡張子）/ 中身の署名（マジックナンバー）/ Webの宣言（MIMEタイプ）の3系統あり、食い違いこそがトラブルと攻撃の源でした。そして解読の最下層には文字コードと圧縮がいる。「開けない・化ける・劣化する」は全部、この地図のどこかで説明がつきます。
この部分をもっと深く（上級）
🎬 アニメーション『ダブルクリックの3秒』の ⑤〜⑦ のところです！
担当が中身を読む段でも、「宣言（拡張子・ヘッダ）」と「物証（中身）」のどちらを信じるかで挙動が変わります。
- きちんとしたアプリは、まず中身の署名や構造を検証してから解読する（宣言を鵜呑みにしない）
- Webのブラウザは原則、配信側が宣言したMIMEタイプに従って扱いを決める
- ただし宣言が曖昧・欠落のとき、ブラウザが中身から種別を推測するMIMEスニッフィング※1 が働くことがある
- スニッフィングは便利だが、「テキストのふりをしたスクリプト」を実行扱いにしてしまう危険があり、推測を禁じる宣言（X-Content-Type-Options の nosniff）で無効化できる
つまり「中身を見破る」には二つの態度がある——宣言を信じて速くするか、中身を検証して安全にするか。上級のシステム設計は、この綱引きの上に立っています。
登場人物メモ（※の説明）:
- ※1 MIMEスニッフィング — 宣言されたMIMEタイプが曖昧なとき、ブラウザが中身の先頭を覗いて種別を推測する機能。利便と危険の両面を持つ
⚠️ イレギュラー（解読の判断ミス）:
- 推測の悪用 — 攻撃者は「無害な型に見せかけつつ、ブラウザに危険な型と推測させる」ことを狙う。nosniff はこの推測経路を塞ぐ防御
- 宣言と中身の不一致 — 宣言は image/png なのに中身がHTML、のようなファイルは、検証するシステムでは弾かれ、検証しないシステムでは侵入口になる
やさしく言うと（初級）
🎬 アニメーション『ダブルクリックの3秒』の ⑤〜⑦ のところです！
起動された担当アプリが、ようやく中身を読みます。
- アプリがOS経由でファイルの中身を読み込む
- 届くのは
01001010...というただの0と1の列（どんなファイルでも！） - アプリはそれを形式の決まり（この並びは色、この並びは文字、という約束。フォーマットって言います）に沿って解読する
- 解読の結果が、あなたの見ている「文書」「写真」「音楽」
つまり .pdf と .jpg の違いは、中身が文書か写真かという以前に、「0と1をどういう決まりで並べたか」の違いです。決まりを知らないアプリには解読できない——メモ帳で写真を開くとぐちゃぐちゃなのは、故障ではなく「読み方が違う」だけなのです。
⚠️ イレギュラー（解読に失敗するとき）:
- 名札と中身が食い違う —
.mp3の名札なのに中身がPDF、のようなファイルは担当アプリが解読できずエラーになる - 新しすぎる・古すぎる形式 — 形式の決まりにも版がある。古いアプリが新しい版の決まりを知らず開けないことがある
「圧縮ファイル（.zip）」はどういう位置づけ？
.zip も名札の1つですが、中身は「複数のファイルを1つにまとめて、小さく詰め直した」特殊な形式です。担当アプリ（展開ソフト、OSに標準搭載）が解読すると、中から元のファイルたちが出てきます。「ファイルの中にファイルが入る」のではなく、「詰め直した1つの形式から、元の形を復元している」——これも0と1の並べ方の決まりの応用です。
まとめると、拡張子は「ただの名札」です。でも、OSは名札しか見ずに担当を決めるからこそ、名札は仕組みの要になっています。中身（0と1）・名札（拡張子）・読み方（形式）・担当（アプリ）——この4点セットで、ファイルにまつわる不思議はぜんぶ説明がつきます。
関連する知識
理解度チェック
そのまま解けます（成績は保存されません）。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。
問1. テキストファイルが「文字化け」する原因として正しいものはどれ？
問2. マジックナンバー（ファイル先頭の署名バイト）の説明として正しいものはどれ？
問3. Webの世界でファイル種別を伝える「MIMEタイプ（Content-Type）」と拡張子の関係はどれ？
問4. 「cat.jpg を cat.png に改名する」ことと「画像アプリで PNG形式として保存し直す」ことの違いはどれ？
問5. JPEGやMP3が使う「非可逆圧縮」の説明として正しいものはどれ？
問6. 圧縮の手順を逆にたどれば元の完全なデータへ戻せる「可逆圧縮」の例の組み合わせはどれ？
問7. 解読の最初の大きな分かれ道である「テキストとバイナリ」の違いとして正しいのはどれ？
問8. Linux や Mac のターミナルで、拡張子を無視してファイル先頭のマジックナンバーから種別を判定するコマンド名を答えてください。