什麼是檔案魔數（Magic Number）？格式辨識原理與常見範例

作業系統怎麼知道檔案類型？

把一個 PNG 檔案改名成 .txt，用 macOS 的 Quick Look 預覽，它依然能正確顯示圖片。在 Linux 上執行 file renamed.txt，輸出依然是 PNG image data。檔名明明改了，為什麼格式沒變？

因為許多格式偵測器會檢查檔案內容中的位元組——也就是魔數（Magic Number）或檔案簽章——而不是只相信檔名。

副檔名仍會影響系統關聯與開啟方式。<code>file</code> 等工具及部分 MIME 處理流程也會檢查位元組，但它們不會使用完全相同的規則。

魔數是什麼？

每種檔案格式在設計時，都會在檔案開頭預留幾個固定位元組作為格式宣告——這就是魔數（Magic Number），也叫檔案簽章（File Signature）或檔頭（File Header）。

類比一下：你出入境時，海關不需要聽你自我介紹，直接翻開護照第一頁就能確認國籍。魔數就是檔案的「護照首頁」——不管檔案叫什麼名字，打開頭幾個位元組就能確認真實身分。

Unix 的 file 指令會將檔案內容與 magic 位元組規則庫比對。這能提供格式線索，但不能取代 MIME、容器中繼資料或具體工具的處理規則。

常見格式魔數速查表

以下是開發中最常見格式的檔頭簽章，均來自實際位元組定義：

陷阱：只看前 4 位元組會誤判

表格裡有兩類格式需要特別注意——RIFF 容器和 ftyp 容器。它們的前幾個位元組相同，但實際上包含完全不同的媒體類型，只看前 4 位元組會直接誤判。

RIFF 容器（WebP / WAV / AVI）

WebP、WAV、AVI 都以 RIFF（52 49 46 46）開頭。真正的子類型藏在偏移 8–11 位元組處：

ftyp 容器（MP4 / MOV / M4A）

MP4、MOV、M4A 的開頭 4 位元組是可變的 box 大小，偏移 4–7 位元組固定為 ftyp，偏移 8–11 位元組才是品牌碼，決定具體格式：

常見品牌碼：isom / iso2 / avc1 = MP4，M4A = M4A（Apple 音訊），qt = QuickTime MOV。

動手驗證：用 file 指令讀取魔數

在 macOS 和 Linux 上，file 指令透過讀取檔案原始位元組並與 magic 規則庫比對來辨識格式，與副檔名無關：

# macOS / Linux
$ file -b photo.png
PNG image data, 617 x 875, 8-bit/color RGBA, non-interlaced

$ file -b photo.txt       # 將副檔名改為 .txt
PNG image data, 617 x 875, 8-bit/color RGBA, non-interlaced

file 是 macOS 和 Linux 的內建工具，Windows 沒有原生等效指令。

如果需要在程式碼中實作相同的格式偵測邏輯，核心只需要這幾行 JavaScript：

// 取 Base64 字串前 24 個字元（atob 解碼後 = 18 位元組），用於格式偵測
// (每 4 個 Base64 字元 = 3 位元組)
const b64 = "iVBORw0KGgoAAAANSUhEUgAA...";
const bin = atob(b64.slice(0, 24));
const hex = [...bin]
  .map(c => c.charCodeAt(0).toString(16).padStart(2, "0"))
  .join(" ");
console.log(hex);
// → 89 50 4e 47 0d 0a 1a 0a ...（PNG）

對照速查表：89 50 4e 47 是 PNG，ff d8 ff 是 JPEG，25 50 44 46 是 PDF。

小結

魔數是判斷底層二進位格式的重要證據，但不是萬能的類型系統。還應結合簽章、宣告的 MIME、容器中繼資料以及具體工具的處理規則。

改名不會改變檔案位元組，因此依內容偵測的工具仍可能辨識原格式；依檔名建立的系統關聯則可能有不同結果。