檔案魔術數字 (magic number) 是位於檔案最開頭的短而固定的位元組序列，能比副檔名更可靠地識別檔案格式。該模式通常佔據位移零 (offset zero) 的最前幾個位元組，因此偵測器無需掃描整個檔案就能讀取前綴，並在任何深度解析開始之前辨識出格式。例如 JPEG 幾乎都以位元組 FF D8 FF 開頭，而可攜式文件則以位元組 25 50 44 46（即 ASCII 字串 %PDF）開頭。由於該值位於已知位置，魔術位元組被命令列工具、上傳驗證器、檔案管理器、防毒引擎和事件回應流程廣泛採用，作為對未知二進位檔案的第一道快速檢查。其權衡在於前綴匹配只是一種訊號而非證明：惡意檔案可以複製預期的位元組，單一前綴可能對應多種容器格式，且僅憑前綴無法保證安全性或完整的結構有效性。一份常見簽章的可搜尋參考資料，搭配一個有維護的解析器，幾乎是任何偵測任務的實際起點。
位移零前綴如何識別格式
檔案魔術數字是偵測器讀取的第一個訊號，它的有效是因為位置可預測。大多數二進位格式都會在最前幾個位元組保留一個固定標頭，其中包含可列印的識別碼或格式規範所定義的常數。PNG 檔案總是以八個位元組 89 50 4E 47 0D 0A 1A 0A 開頭，ELF 執行檔以 7F 45 4C 46 開頭，而 SQLite 資料庫則以字面 ASCII 字串 SQLite format 3 接著一個空位元組 (null byte) 開頭。僅讀取這些位元組既便宜又無副作用且與語言無關，這就是為何上傳流程、郵件閘道和逆向工程工具都會先採用前綴。
位移很重要。精簡參考資料中列出的簽章恰好在位移零進行檢查，因此偵測器只需從檔案開頭讀取固定數量的位元組。像 libmagic 這類通用工具則更進一步：它們會評估其他位移、間接位移、遮罩、數值端序 (endianness)、字串和巢狀條件下的位元組序列。這種更廣的範圍能捕捉身分藏在標頭更深處的格式，但也需要真正的規則引擎。普通的位移零前綴表格適合用於快速的第一道檢查、教學參考，或是讀者想要直接複製貼上的偵測規則。
前綴只是一種訊號。相同的位元組序列可能出現在不相關的內容中，格式錯誤的檔案可能開頭正確但隨後偏離，惡意檔案也可以複製預期的位元組，卻在後面攜帶不同的酬載。生產環境的偵測始終會將前綴與結構式解析、大小限制、可信賴的解碼器以及針對特定情境的安全控制結合起來，而不是單獨依賴前綴。
十二種常見簽章一次收錄
一份精簡、經來源驗證的十二種格式清單，涵蓋開發人員在單一工作日中遇到的大部分二進位檔案：影像、文件、封存檔、執行檔和嵌入式資料庫。檔案簽章 (魔術位元組) 清單 參考資料中的十二列分別代表 JPEG、PNG、GIF 的兩種標頭（87a 與 89a）、PDF、ZIP、GZIP、7-Zip、RAR 4、RAR 5、ELF 和 SQLite 3。數值以空格分隔的大寫十六進位位元組儲存，因此可以直接與十六進位檢視器、二進位解析器、上傳檢查規則或事件分析記錄進行比較，無需從其他表示法轉換。
參考表格刻意保持簡短。它不包含執行檔子類型、媒體編解碼器、磁碟映像、字型、郵件格式或所有封存變體。這些內容由更大的維護資料庫所涵蓋；本清單是事件回應期間或撰寫偵測規則時，可用肉眼驗證的小型精確前綴子集。
| 格式 | 常見副檔名 | 位移零十六進位前綴 | 備註 |
|---|---|---|---|
| JPEG | .jpg, .jpeg | FF D8 FF | 影像，後面通常接著 EXIF 或 JFIF 標記 |
| PNG | .png | 89 50 4E 47 0D 0A 1A 0A | 影像，固定的八位元組標頭 |
| GIF87a | .gif | 47 49 46 38 37 61 | 影像，ASCII 字串 GIF87a |
| GIF89a | .gif | 47 49 46 38 39 61 | 影像，ASCII 字串 GIF89a |
| 25 50 44 46 | 文件，ASCII 字串 %PDF | ||
| ZIP | .zip, .docx, .xlsx, .jar, .epub | 50 4B 03 04 | 容器，也用於 DOCX、XLSX、JAR、EPUB |
| GZIP | .gz, .gzip, .tgz | 1F 8B | 壓縮串流 |
| 7-Zip | .7z | 37 7A BC AF 27 1C | 封存檔 |
| RAR 4 | .rar | 52 61 72 21 1A 07 00 | 封存檔，版本 4 |
| RAR 5 | .rar | 52 61 72 21 1A 07 01 00 | 封存檔，版本 5 |
| ELF | (無，執行檔) | 7F 45 4C 46 | 執行檔，ASCII 字串 .ELF |
| SQLite 3 | .sqlite, .sqlite3, .db | 53 51 4C 69 74 65 20 66 6F 72 6D 61 74 20 33 00 | 資料庫，ASCII 字串 SQLite format 3 加空位元組 |
上述數值是各格式公開規範所定義的標準位移零前綴，並記錄於 file 指令的魔術資料庫中。它們以大寫、空格分隔的十六進位表示，因此可以直接貼入規則、筆記記錄或十六進位比較中，無需再進行轉換。
如何查找並驗證魔術數字
從未知檔案到已知前綴的最快途徑是單一可搜尋的表格。下方經驗證的工作流程以檔案簽章 (魔術位元組) 清單作為查找步驟，並以一個有維護的解析器作為驗證步驟。
- 依格式、副檔名、位元組或備註（例如 container）進行搜尋。在搜尋框中輸入 zip、container 或十六進位位元組 50 4B 03 04，從十二列中篩選到你所需的格式。搜尋會在格式名稱、副檔名、十六進位字串和描述性備註之間進行正規化 (normalized)，因此部分查詢仍可命中。
- 將位移零的十六進位序列與可信的二進位檢視進行比對。在十六進位檢視器中開啟檔案，或使用你所用語言的二進位讀取器讀取最前幾個位元組，然後將位元組與表格中的前綴對齊。參考資料以大寫十六進位加上單位元組間距顯示，以便進行逐字比對。
- 複製前綴以用於文件記錄或經測試的偵測規則。使用工具中的複製功能，將精確的位元組放入偵測規則、wiki 頁面或事件記錄中。從參考資料複製可避免轉錄錯誤，並保持大小寫和位元組順序與你將比對的規則引擎一致。
- 在信任或處理檔案之前，先以有維護的解析器確認完整結構。匹配前綴後，使用有維護的解析器驗證整個檔案，強制執行白名單 (allowlist)，並套用針對特定情境的安全控制。參考資料是起點，而非授權步驟。
容器格式會產生真正的歧義
前綴可以識別容器，但不一定能識別其中的應用程式格式。ZIP 的本地檔案標頭 50 4B 03 04 是典型範例。它會出現在一般的 ZIP 封存檔中，也會出現在位移零的 Office Open XML 文件（如 DOCX 和 XLSX）、Java JAR 封存檔、EPUB 電子書以及其他許多套件格式中。僅在前綴停下來的偵測器會樂於將惡意的 .docx 標記為 .zip 下載，反之亦然，而使用者僅從位元組無法分辨差異。
健全的偵測器必須開啟容器並檢查必要的內部路徑、中繼資料、關聯和內容類型。DOCX 預期會包含 word/document.xml 和 [Content_Types].xml 項目；EPUB 的第一個項目是內容為 application/epub+zip 的 mimetype；JAR 則包含 META-INF/MANIFEST.MF。參考資料中的表格明確標示了這項限制，而非聲稱 50 4B 03 04 唯一代表 .zip 下載。將容器偵測視為僅僅是初篩，與將其視為更多，正是實用過濾器與漏洞之間的差別。
容器格式本身也帶有風險。解壓縮炸彈 (decompression bomb) 會將微小的封存檔膨脹為數 GB 的輸出，路徑遍歷攻擊 (path traversal) 會逸出預期的解壓目錄，而解析器漏洞會將格式錯誤的條目變成任意程式碼執行。建立預期內部檔案的白名單、強制執行單檔與總大小限制、隔離解壓路徑，以及對高風險工作流程執行防毒分析，都是同一道防線的一部分。
僅有前綴匹配並不足夠的時候
匹配的前綴絕不能證明檔案是安全的。檔案開頭的位元組模式可能被惡意行為者複製，然後在其後附加或交錯不同的酬載，因此一個僅憑前綴強度就接受酬載的嗅探規則，等於是在接受不受信任的內容。使用有維護的解析器驗證完整結構、強制執行白名單、在伺服器端重新命名上傳檔案、隔離儲存、在適當情況下封鎖主動式內容，以及以安全標頭提供下載，都是同一組控制措施的一部分。針對高風險工作流程，可能還需要防毒或沙箱分析。
截斷的輸入是另一種常見的誤判。一個以 FF D8 FF 開頭的一 KB 檔案，無論前綴看起來多乾淨，都不是可用的 JPEG。偵測器應明確拒絕截斷的檔案，而不是依賴向上冒出的解析器錯誤。避免將解析器錯誤、檔案系統路徑或內部規則暴露給不受信任的使用者，並保持偵測程式庫和解碼器的更新。在開發期間以及每次規則更新時，測試格式錯誤、多重格式 (polyglot)、過大以及巢狀的樣本。
參考資料完全在瀏覽器中執行，不會請求或讀取本機檔案。搜尋和複製都停留在當前分頁，無需帳號，也不會新增任何相依套件。這使得在事件回應期間或撰寫偵測邏輯時查閱它是安全的，不會意外洩漏正在分析的檔案。
Beyond the Twelve: Where to Go Next
Once a developer needs more than offset-zero prefixes, the next two resources are the maintained file command magic database and a community-maintained signature table. The file command magic database is the canonical source behind the libmagic library used by the Unix file command, and it evaluates byte sequences at indirect offsets, masks, numeric endianness, strings, and nested conditions. The SEARCH GCK File Signatures table is searchable by extension and description and covers many more formats. Both should be consulted when implementing production detection beyond the common examples in the twelve-row reference.
The entries in the twelve-row reference are protected by tests for exact size and uniqueness, but standards and implementations can evolve. Verify critical production rules against current upstream documentation, record the rule version, and maintain regression samples that include both accepted formats and adversarial near-matches. Record both the observed bytes and the parser verdict so later reviewers can distinguish a prefix match from a validated file structure. That audit trail is what separates a detection rule you can defend in a postmortem from one that quietly accepts an attacker's hand-crafted prefix.
Related reading: Common Port Numbers: How to Identify Any Service Port.
Related reading: File Signatures List Alternative: Twelve Verified Prefixes.