檔案簽章清單替代方案是一份精簡對照，收錄十二個經來源核對的魔術位元組前綴，涵蓋 JPEG、PNG、兩種常見 GIF 標頭、PDF、ZIP、GZIP、7-Zip、RAR 4、RAR 5、ELF，以及 SQLite 3。可依格式、副檔名、十六進位位元組，或 container 這類備註搜尋，表格會回傳以空白分隔的大寫十六進位位元組，方便貼進十六進位檢視器比對、上傳檢查規則，或事件分析筆記。每次搜尋與複製都在目前分頁本機執行——不必帳號、不必上傳、沒有相依性——因此比起要求你送出樣本、只為了讀開頭四個位元組的託管查詢服務，這份對照是更安全的第一站。數值固定在 offset 零，讓比對規則保持簡單，任何讀程式碼的人都能審查表格。這份對照刻意停在 offset 零，因為目標是快速、透明的位元組比對，不是通用的格式推斷。
開發者為什麼要找替代的檔案簽章清單
FileSignatures.net 是長期運作的公開檔案簽章資料庫，已長時間顯示維護公告，讓依賴它快速搜尋魔術位元組的開發者失去第一站。這個缺口促使許多工程師改用強調較小、可驗證前綴集合、而非全面枚舉的替代方案。聚焦清單回答的問題，與通用識別工具不同：你不是靠上傳樣本來問「這是什麼檔？」，而是要一份乾淨對照，讓你把已經看到的位元組拿去跟已知前綴比對。
純瀏覽器執行是把替代方案放在手邊的另一個理由。當你在隔離工作站偵錯剖析錯誤、在受鎖定主機上分流可疑上傳，或在會封鎖第三方查詢的網路上處理事件時，一份在單一分頁執行、不必伺服器往返的對照，能去掉 API 後端服務無法避免的摩擦。把精確的十六進位字串複製進 runbook 或偵測規則，也比從截圖或欄位重疊的託管資料庫謄打更快。
生產管線採用 libmagic 風格偵測，也隨著這些限制一起成長。根據 file command magic database 在 GitHub 上維護，通用規則可以評估其他 offset、間接 offset、遮罩、數值 endianness、字串，以及巢狀條件下的位元組序列。那種能力在生產環境有用，但也正是許多團隊為日常比對與新人教材保留較小、固定 offset 對照的原因。替代方案不是完整 magic 資料庫的替代品——它是聚焦的補充。
瀏覽器版檔案簽章清單涵蓋什麼
File Signatures (Magic Bytes) List 儲存十二個經來源核對的 offset 零位元組前綴，帶有唯一識別碼與格式加十六進位配對，並在格式名稱、副檔名、十六進位位元組與簡短備註之間正規化。每筆記錄都固定在 offset 零，讓比對規則保持簡單，表格也讓任何讀程式碼的人都能審查。此工具不重現通用資料庫裡感知 offset、遮罩或間接 offset 的規則，也不掃描上傳檔案；它是可搜尋的對照，不是識別器。
這十二列刻意涵蓋一組在網站上傳、紀錄分析與事件分流中不斷出現的小集合格式：
| 格式 | 常見副檔名 | 類別 | 備註 |
|---|---|---|---|
| JPEG | jpg, jpeg | 圖片 | 僅 offset 零前綴 |
| PNG | png | 圖片 | 僅 offset 零前綴 |
| GIF (87a) | gif | 圖片 | 較舊的 GIF 變體標頭 |
| GIF (89a) | gif | 圖片 | 較新的 GIF 變體標頭 |
| 文件 | 文件格式標頭 | ||
| ZIP | zip | 封存容器 | 相同前綴也出現在 DOCX、XLSX、JAR、EPUB |
| GZIP | gz, gzip | 封存 | 單一 offset 零前綴 |
| 7-Zip | 7z | 封存 | 7z 容器標頭 |
| RAR（版本 4） | rar | 封存 | 較舊的 RAR 格式標頭 |
| RAR（版本 5） | rar | 封存 | 現行 RAR 格式標頭 |
| ELF | （無固定副檔名） | 可執行檔 | Linux、BSD 與 Unix 二進位檔 |
| SQLite 3 | sqlite, db, sqlite3 | 資料庫 | 資料庫容器格式 |
數值以空白分隔的大寫十六進位位元組呈現，因此你可以直接貼進十六進位檢視器、剖析器比對、上傳檢查規則，或事件分析筆記，不必從另一種記法轉換。因為列已經過來源核對，並以精確大小與唯一性測試保護，你可以信任複製的位元組與表中位元組相符——但標準與實作會演進，所以請把關鍵生產規則對照目前的上游文件驗證，並在 runbook 中記錄規則版本。
如何用替代方案查詢魔術位元組
- 搜尋表格。 在瀏覽器中開啟 File Signatures (Magic Bytes) List，並在搜尋欄輸入查詢。使用格式名稱（PDF）、副檔名（zip）、十六進位前綴（50 4B），或 container 這類短備註。搜尋會橫跨格式名稱、副檔名、十六進位位元組與備註，所以其中任何一項都能找出正確的列。
- 把 offset 零前綴與可信的二進位檢視比對。 用你選擇的十六進位編輯器或二進位檢視器開啟可疑檔，並查看開頭幾個位元組。表中以空白分隔的大寫十六進位，應與檔案開頭看到的位元組相符。若表格寫前綴從 offset 零開始，就不要從 offset 4 或 16 開始比對；位元組必須在檔案最開頭對齊。
- 複製前綴以供文件或已測試的偵測規則使用。 使用列旁的複製控制，把精確的十六進位字串放進剪貼簿。貼進偵測規則、上傳篩選器、runbook 或程式碼註解。因為此工具從不讀取你的本機檔案，在此步驟中可疑檔的任何位元組都不會離開你的機器。
- 在信任或處理檔案之前，用受維護的剖析器確認完整結構。 相符的前綴是一項訊號，不是證明。對整個檔案執行受維護的剖析器或解碼器以驗證結構，然後在對檔案內容採取行動之前，強制允許清單、大小限制，以及依情境而定的安全控制。
最後這一步最常被跳過。此工具的原則是：單靠魔術位元組絕不該授權一次上傳：驗證完整檔案、強制允許清單、在伺服器端重新命名、隔離儲存、在適當處阻擋主動內容，並以安全標頭提供下載。對較高風險的工作流程，防毒或沙盒分析可能仍有必要。即使開頭位元組相符，也要拒絕截斷的輸入，因為前綴無法告訴你檔案其餘部分的任何事。
容器格式陷阱：為什麼只偵測 ZIP 會失敗
從簽章清單推出檔案類型偵測規則時，最常見的錯誤之一，就是把單一前綴當成完整答案。例如 ZIP 的 local-file header，也會出現在 Office Open XML 文件（如 DOCX 與 XLSX）、Java JAR 封存、EPUB 檔，以及許多其他套件格式的開頭。識別容器並不能識別其中的應用程式格式，而對照表明確標示這個限制，而不是宣稱 ZIP 前綴就唯一代表可下載的封存檔。
穩健的偵測器必須檢查套件必要的內部路徑、中繼資料、關聯與內容類型，才能區分 DOCX、JAR 或 EPUB。反向也成立：若你永遠只檢查前綴，惡意檔可以複製預期的位元組，卻在檔案較後面帶著無效或危險的承載資料。魔術位元組有用，但不能取代結構剖析。縱深防禦才是原則——保持偵測函式庫與解碼器已修補，測試畸形、polyglot、過大與巢狀樣本，並把前綴相符當成驗證鏈的起點，而不是終點。
容器格式還暴露更隱微的工程風險。短前綴可能意外撞上無關內容，而 ZIP 套件尤其可能在完全正常的前綴後面藏解壓縮炸彈與路徑遍歷承載。避免向不受信任的使用者暴露剖析錯誤、檔案系統路徑或內部規則，也絕不要只因為開頭四個位元組看起來正確就接受上傳。若你需要的視野超過十二筆 offset 零紀錄能提供的範圍，受維護的公開資料庫見 SEARCH GCK File Signatures 是有用的下一站驗證來源，而上游的 file magic 目錄記錄了生產偵測器通常繼承的、感知 offset 的規則。
當對照清單不夠時：必須尊重的偵測限制
即使經來源核對的清單也有限制。這十二筆 offset 零紀錄不含可執行檔子類型、媒體編解碼器、磁碟映像、字型、郵件格式，或每種封存變體，因為對照的目的是保持精簡可審查，而不是窮盡。有些格式允許前置資料、多個有效簽章，或依版本而異的標頭，因此每列單一前綴是工作假設，不是萬用規則。短前綴可能撞上無關內容，而表格背後的契約明確警告：不要把任何前綴相符當成類型或安全性的證明。
生產偵測幾乎總是需要比這更多。通用 libmagic 規則可以評估其他 offset、間接 offset、遮罩、數值 endianness、字串與巢狀條件——此工具一項都不重現。把清單當成與結構剖析、大小限制、受信任解碼器，以及依情境而定的安全控制並列的一項訊號。當你要在這些常見例子之外實作生產偵測時，請查閱連結的主要資料庫與格式規格，並維護同時包含已接受格式與對抗性近相符的迴歸樣本。
同時記錄觀察到的位元組與剖析器判定，讓之後的審查者能區分前綴相符與已驗證的檔案結構。這份紀錄把快速查詢變成稽核軌跡，也讓替代方案能作為較重偵測堆疊的聚焦補充，而不是脆弱的替代品。
若要更深入了解，請見 HTTP 狀態碼替代方案：以登錄為先的查詢。
若要更深入了解，請見 本機 JavaScript Playground 安全測試替代方案。