ファイルのマジックナンバーとは何ですか？

ファイル先頭の数バイトで、名前が何であろうとその形式を示すものです。PNG は必ず 89 50 4E 47 で始まり、ZIP は 50 4B 03 04 で始まります。OS もブラウザも file コマンドも、拡張子を信用せずこのバイト列を読みます。だからファイル名を変えても中身の正体は変わりません。

マジックナンバーを自分で確認する方法は？

macOS や Linux なら xxd -l 16 ファイル名で先頭 16 バイトが表示されます。Windows なら PowerShell で Format-Hex -Path ファイル名 -Count 16 です。あるいはこのサイトのファイル形式判別ツールにドロップすれば、ローカルでバイト列を読んで形式を教えてくれます。アップロードはありません。

2 つの形式が同じマジックナンバーを持つのはなぜ？

一方が他方の上に作られているからです。docx、xlsx、pptx、apk、jar、epub はすべて中身が ZIP アーカイブなので ZIP の署名で始まり、区別するには内部のエントリを見る必要があります。Java の class ファイルと macOS のユニバーサルバイナリはどちらも CA FE BA BE で始まり、直後のフィールドで見分けます。

マジックナンバーがまったくないファイルもある？

あります。XML、HTML、JSON、SVG、CSV といったテキストベースの形式には固定のバイト署名がないため、構造から判別します。先頭の <?xml 宣言、<svg 要素、あるいは { に続く引用符付きのキーなどです。これは確定ではなく推測なので、このリファレンスではそうした形式をプローブ判別として示しています。

マジックナンバーが一致すればそのファイルは安全？

いいえ。わかるのは形式であって、中身が無害かどうかではありません。正規の PDF や docx でも悪意のあるペイロードを含んでいることがあります。特に拡張子とバイト列が食い違うときに真の形式を知るのは有用な第一段階ですが、マルウェアスキャンではありません。

MP4 ファイル形式

Q: マジックナンバーを自分で確認する方法は？

macOS や Linux なら xxd -l 16 ファイル名 で先頭 16 バイトが表示されます。Windows なら PowerShell で Format-Hex -Path ファイル名 -Count 16 です。あるいはこのサイトのファイル形式判別ツールにドロップすれば、ローカルでバイト列を読んで形式を教えてくれます。アップロードはありません。

Q: マジックナンバーが一致すればそのファイルは安全？

いいえ。わかるのは形式であって、中身が無害かどうかではありません。正規の PDF や docx でも悪意のあるペイロードを含んでいることがあります。特に拡張子とバイト列が食い違うときに真の形式を知るのは有用な第一段階ですが、マルウェアスキャンではありません。

MPEG-4 Part 14。ウェブ動画・音声の標準 ISO-BMFF コンテナ。

MIME タイプ: video/mp4
拡張子: .mp4
カテゴリ: 動画

マジックナンバー（ファイル署名）

0x00000004	66747970	ftyp	ISO-BMFF 'ftyp' box
0x00000008	69736F6D	isom	a major brand, e.g. 'isom'/'mp42'

MP4 形式について

MP4 はストリーミングとダウンロード配信で圧倒的に主流のコンテナで、通常は H.264/H.265 または AV1 の映像と AAC 音声を格納します。フレームの並びではなくボックスの木構造で、各ボックスはビッグエンディアン 32 ビットのサイズに 4 文字の型が続く形をしており、ISO/IEC 14496-12 は FileTypeBox がその先頭に来ることを要求しています。見慣れた ASCII の ftyp がオフセット 0 ではなくオフセット 4 にあるのはそのためで、手前の 4 バイトは、それが導入するボックスのサイズです。プレイヤーがデコードに必要とするもの、つまりトラック一覧・コーデックパラメータ・サンプルテーブル・タイムスタンプはすべて moov ボックスにあり、圧縮されたサンプル本体は 1 つ以上の mdat ボックスにあります。この 2 つのどちらが先に来るかを形式は何も定めておらず、その制約なしの並び順の判断ひとつが、MP4 で人がぶつかる実務上の面倒のほとんどを生んでいます。

ヘッダーの構造（バイト単位）

オフセット	長さ	フィールド	意味
0	4	ftyp box size	FileTypeBox 全体のバイト数をビッグエンディアンで表したもので、この 4 バイトも含みます。00 00 00 20 なら 32 バイトで、メジャーブランド、マイナーバージョン、互換ブランド 4 つが入る大きさです。サイズが 1 なら型の後ろに 64 ビットの largesize が続き、0 ならボックスはファイル末尾まで伸びます。ftyp でこの抜け道が使われることはまずありません。
4	4	Box type 'ftyp'	66 74 79 70。これがすべての ISO base media ファイルの実質的なマジックナンバーで、オフセット 0 にないのは意図的です。この形式のボックスはどれも、名前の手前に自分の長さを持っているからです。
8	4	Major brand	ファイルが従うと主張している仕様を示す 4 文字コードです。isom、iso2、iso5、iso6、mp41、mp42、avc1、セグメント化されたストリームなら dash。MP4 を MOV・M4V・M4A・3GP・AVIF・HEIC から分けているのはこのバイト範囲で、これらはどれも手前にまったく同じ ftyp ボックスを持っています。
12	4	Minor version	ビッグエンディアンの 32 ビット数値ですが参考情報でしかなく、仕様はこれを理由にファイルを拒否してはならないと定めています。ffmpeg は isom ブランドの隣に 00 00 02 00 を書き、その値がウェブ上の膨大な数のファイルに載っているのは、それ以上の理由がありません。
16	variable	Compatible brands	4 文字ブランドのリストで、1 つ 4 バイト、ボックスの残りを埋めます。メジャーブランドを理解できないプレイヤーでも、ここに認識できる項目があれば処理を続けてよいことになっていて、dash セグメントや avc1 のファイルが isom しか知らないデコーダでも開けるのはそのおかげです。
32	8	Second box header	ftyp の後に続くもののサイズと型で、moov・mdat・free・wide のいずれかです。オフセット 32 になるのは ftyp ボックスが 32 バイトのときで、よくあるケースではありますが規則ではありません。位置を決め打ちせず、オフセット 0 のサイズを読んでください。

似た形式との見分け方

紛らわしい形式	見分け方
QuickTime Movie	先頭 8 バイトはバイト単位で同一で、分けるのはオフセット 8 のメジャーブランドだけです。末尾にスペース 2 つの qt、つまり 71 74 20 20 なら QuickTime です。ブランド判定ではまったく捕まえられないケースがもうひとつあります。2004 年ごろより前に書かれた QuickTime ファイルには ftyp ボックスがそもそも無く、オフセット 4 が直接 moov・mdat・free・skip・wide・pnot のいずれかで始まります。
M4V	同じボックス、同じ配置で、オフセット 8 のブランドが M4V、末尾スペース付きの 4D 34 56 20 です。保護のかかっていない M4V はあらゆる意味で MP4 なので、拡張子を変えるだけで足ります。再生できないのは FairPlay で保護されたもので、それはヘッダではなくファイルの奥にある暗号化されたサンプルエントリとして見えてきます。
3GP	オフセット 8 のブランドが 3gp4・3gp5・3gp6、つまり 33 67 70 に数字が続く形です。3GP は携帯端末向けに同じコンテナを制限したプロファイルなので、その中のボックスはすべて合法な MP4 ですが、逆は成り立ちません。H.265 や AC-3 を運ぶ MP4 は、パーサが平然と歩けたとしても正しい 3GP ファイルではありません。
AVIF	こちらも ftyp ボックスを持ち、ブランドは avif か avis で、同じ名前のボックスが詰まっています。ただし静止画で、絵は時間軸を持つトラックではなく meta ボックスに入っています。HEIC も同じ話で、ブランドが heic・heix・mif1 になるだけです。ftyp だけで判断するツールは、写真を平然と動画と呼びます。
WebM	まったく無関係です。WebM と Matroska は EBML ファイルで、オフセット 0 が 1A 45 DF A3 で始まります。混乱の元はバイトではなく拡張子のほうで、どちらも AV1 と Opus を運びブラウザで再生できるため、両者の間でリネームされて開けなくなる事故が起きます。

よくある壊れ方

moov ボックスの欠落。バッテリー切れで止まった録画や、途中で強制終了した書き出しは、mdat に全フレームを抱えたまま索引が一度も書かれていないファイルを残します。多くの muxer は moov をメモリ上で組み立てて最後に追記するからです。ファイルは大きく、hex ダンプでは明らかに映像データで埋まっていて、まったく再生できません。復旧には、同じ機器が作った別の無事なファイルからサンプルテーブルを組み直す作業が要ります。
moov ボックスが末尾にあるファイルをストリーミングしている場合。ここでは壊れているものは何ひとつありませんが、HTTP でファイルを取ってくるプレイヤーは末尾までダウンロードしないと再生を始められないので、遅い回線では壊れたファイルとまったく同じに見えます。このボックスを前に移すのが faststart フラグの仕事で、再エンコードではなくオフセットの書き換えを行います。
ダウンロードの途中切れ。ボックスは先に自分の長さを申告するので、パーサは最後の完全なボックスまで到達したあと、残りより多くのバイトを約束するサイズフィールドに出くわします。よくできたリーダーはそこで止めて読めた分を再生し、そうでないものは大半がきちんとデコードできていてもファイルを破損と報告します。
サイズが嘘をついている場合。サイズとタイプのフィールドだけで 8 バイトあるので 8 未満はありえないのですが、バイトが壊れればそういう値も生まれます。素朴なパーサはサイズをカーソルに足したあと、同じオフセットで無限ループします。ツールが失敗ではなくハングしたときは、手で確認する価値があります。
先頭に余分なバイトが付いた場合。.mp4 という名前で保存された HTML のエラーページや、実データの手前に紛れ込んだ BOM は、ftyp をオフセット 4 から押し出します。moov ボックス内のチャンクオフセットはすべてファイル先頭からの距離なので、ゴミの正体が分かっても、読み飛ばすだけでは再生できません。実際に取り除く必要があります。

この形式の現在地

インターネット上の動画とは、実質 MP4 のことです。HLS も DASH もこれをフラグメント化して配り、あらゆるスマートフォンがこれで録画し、地球上のあらゆるブラウザとハードウェアデコーダがこの中の H.264 を再生し、あらゆる編集ソフトがこれを読み込みます。WebM が生まれた理由は MP4 の特許事情にあり、オープンウェブでロイヤリティフリーの AV1 や VP9 を配る用途で WebM は実際にシェアを取りました。Matroska は保管用途を取りました。多数の字幕・音声トラックを扱う手間が少ないからです。それでも MP4 が第一候補であり続ける理由はハードウェアです。MP4 の中の H.264 トラックは、この 15 年に作られたほぼすべてのスマートフォン・テレビ・ノート PC で専用回路がデコードします。バッテリー駆動の機器では、その価値が圧縮率の優位を上回ります。Safari と iOS が完全な一級市民として扱う唯一のコンテナでもあり、不特定多数に動画を届ける立場なら、それで議論は終わります。

MP4 ファイルをこのサイトで開く

どれもブラウザ内で動きます。ファイルが端末から出ることはありません。