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

ファイル先頭の数バイトで、名前が何であろうとその形式を示すものです。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 でも悪意のあるペイロードを含んでいることがあります。特に拡張子とバイト列が食い違うときに真の形式を知るのは有用な第一段階ですが、マルウェアスキャンではありません。

Ogg ファイル形式

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

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

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

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

Ogg コンテナ。多くは Vorbis/Opus 音声や Theora 映像を格納します。

MIME タイプ: application/ogg
拡張子: .ogg, .oga, .ogv
カテゴリ: 音声

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

0x00000000

4F676753

OggS

'OggS' page capture pattern

Ogg 形式について

Ogg は特許の制約がないオープンなストリーミングコンテナで、Vorbis または Opus 音声を入れることが最も多く、ゲームやオープンソースソフトウェアで広く使われています。すべてのページはキャプチャパターン OggS で始まります。この「すべての」という部分が設計そのものです。Ogg ファイルはヘッダの後ろにデータが続く構造ではなく、自己記述的なページの連鎖です。各ページが自分のチェックサム、シーケンス番号、ストリームシリアルを持つので、デコーダはライブストリームの途中から参加できますし、壊れたダウンロードも次の 4F 67 67 53 を前方に探せば再同期できます。コンテナ自身はコーデックについて何も語りません。それを決めるのは、最初のページに載る最初のパケットです。

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

オフセット	長さ	フィールド	意味
0	4	Capture pattern 'OggS'	4F 67 67 53。これはページの先頭を示すもので、ファイルの先頭ではありません。1 秒の音声クリップにもすでに数十個含まれています。hex エディタでこれを検索すれば、ストリーム中のページ境界がすべて見つかります。
4	1	Stream structure version	常に 0。Ogg のフレーミングに 2 つ目のバージョンが定義されたことはないので、それ以外の値なら、そのバイト列は本当は Ogg ページではありません。
5	1	Header type flag	ビット 0 は最初のパケットが前のページからの継続であること、ビット 1 は論理ストリームの開始、ビット 2 は終了を示します。したがってファイルの一番最初のページは 02 と読めます。
6	8	Granule position	リトルエンディアンの符号付き 64 ビットの位置で、意味を定めるのは Ogg ではなくコーデックです。Vorbis なら PCM サンプル数、Opus なら 48 kHz サンプル数の計数です。全ビットが立った状態（-1）は、このページで終わるパケットが無く、報告すべき新しい位置が無いことを意味します。
14	4	Bitstream serial number	このページが属する論理ストリームを識別する、ランダムに近いリトルエンディアンの id です。映像と音声を運ぶファイルは異なるシリアルのページを交互に並べますし、連結されたファイルは区間ごとにシリアルを持ちます。
18	4	Page sequence number	リトルエンディアンで、論理ストリームごとに 0 から数えます。この番号が飛ぶことこそが、データが壊れているのではなくページが落ちたのだとデコーダに分かる仕組みです。
22	4	Page checksum	このフィールドを一時的にゼロにしたページ全体に対する CRC-32 です。多項式は 0x04C11DB7、入出力の反転も最終 XOR もありません。ZIP や gzip が使う CRC-32 とは意図的に別物で、両者を取り違えられないようになっています。
26	1	Number of page segments	セグメントテーブルのエントリ数で、0 から 255 です。これによりページは 27 + 255 + 255 × 255 = 65307 バイトで頭打ちになります。コーデックが何をしようと Ogg の遅延に上限があるのはこのためです。
27	variable	Segment table	1 セグメントにつき 1 バイト、各値は 0〜255 です。パケットの長さは 255 未満の値が現れて終端するまでの累計になるので、ちょうど 255 という値は常に「継続する」を意味します。手書きの Ogg パーサが必ず間違えるのがここです。
variable	variable	First packet — the codec identification header	セグメントテーブルの直後にあるので、セグメント 1 つの先頭ページならオフセット 28 です。Vorbis は 01 に続けて vorbis、Opus は OpusHead、Ogg 内の FLAC は 7F に続けて FLAC、Theora は 80 に続けて theora を書きます。音声が実際に何なのかを決めるのは、拡張子ではなくこれです。

似た形式との見分け方

紛らわしい形式	見分け方
oga/ogv/opus	コンテナのレベルでは区別するものが何もありません。4 つの拡張子はどれも同じ OggS のフレーミングで、.oga が音声、.ogv が映像、.opus が Opus ストリームというのは慣習にすぎません。答えは常にセグメントテーブルの後ろの識別パケットにあります。素の Vorbis ファイルならオフセット 28 に 01 と vorbis、Opus ならオフセット 28 に OpusHead です。リネームしても何も変わりませんし、MIME タイプを信じても同じことです。
FLAC	FLAC には 2 つの衣装があり、取り違えやすくなっています。ネイティブの FLAC はオフセット 0 が 66 4C 61 43 で始まり、いきなり 34 バイトの STREAMINFO ブロックに入ります。Ogg の中の FLAC は他と同じく 4F 67 67 53 で始まり、オフセット 28 にマーカー 7F 46 4C 41 43 が現れ、マッピングのバージョン、ヘッダパケット数と続いて、そこでようやくネイティブの fLaC マーカーとその STREAMINFO が来ます。
WebM	もうひとつの特許フリーなオープンコンテナで、どちらを使うべきかと聞かれたときの定番の対抗馬です。WebM と Matroska は 1A 45 DF A3 で始まる EBML ドキュメントで、OggS とはバイトを 1 つも共有していません。ブラウザの映像では WebM が勝ち、Ogg は Vorbis と Opus を確保しました。
MP3	MP3 はコンテナを持たない素のフレーム列で、ID3 タグか、11 個の立ったビットからなるフレーム同期で始まります。ページのチェックサムもシーケンス番号も無く、フレームの喪失を伝える手段もありません。Ogg がストリーミング向けに埋めようとしたのは、まさにその空白です。

よくある壊れ方

ライブストリームでのページ落ち。Ogg はこれを致命的ではなく通常の事象として扱います。オフセット 18 のシーケンス番号が飛び、デコーダは欠落を報告し、次のキャプチャパターンから再生を再開します。部分的に壊れたダウンロードも同じやり方、つまり 4F 67 67 53 を前方に探してそこから拾い直すことで復帰します。
終端ページの無い途中切れ。最後のページのヘッダタイプフラグにビット 2 が立たないままなので、最終的なグラニュール位置を述べるものが無く、総再生時間が不明になります。届いた分の音声は最後まで再生されますが、シークバーと表示される長さは狂ったままです。
ページ本体のビット腐敗。オフセット 22 のページチェックサムが失敗し、デコーダはファイルではなくそのページ 1 枚、コンマ数秒の音声だけを捨てます。破損はクリックノイズとして聞こえ、それ以降のページはすべて検証を通ります。
素朴な連結。Ogg ファイル 2 つを cat でつなぐと、異なるシリアル番号を持つ合法な連鎖ストリームができますが、多くのプレイヤーは最初の終端ページで止まり、1 つ目のファイルの長さしか報告しません。連結ではなく remux するのが正解です。
先頭に付いた余分なバイト。HTTP のエラー本文や、前に貼り付けられた ID3 タグが、最初のキャプチャパターンをオフセット 0 から押し出します。ページはすべて無傷で、再同期するプレイヤーならちゃんと見つけますが、オフセット 0 しか読まない検出器はこのファイルを不明と報告します。

この形式の現在地

Ogg の役目は昔より狭くなりましたが、その分とても堅固です。Vorbis は MP3 に対するフリーな回答で、MP3 に制約があった時代に何の縛りも無かったため、今も膨大な数のゲームとオープンソースアプリケーションが音声をこれで同梱しています。RFC 6716 で標準化され、ファイルでは Ogg に、通話では RTP に載る Opus は、いまや WebRTC の既定の音声コーデックであり、汎用の低遅延音声コーデックとして最良のものです。つまり Ogg は、コーデック戦争の勝者を中に抱えて生き残りました。映像ではこのコンテナは WebM と MP4 に完敗し、.ogv は事実上の歴史遺物です。Ogg が第一候補であり続ける領域は、損失に耐えなければならないストリーミングです。ページは自己記述的でチェックサム付きで再同期できるので、デコーダはライブストリームに途中参加でき、帯域外の信号なしにパケット落ちから復帰できます。

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

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