一份能一次顯示十二個 offset-zero 檔案簽章的參考資料，讓開發者無需讀取任何本機檔案、掃描上傳的樣本，或從線上資料庫拉取規則，就能從 檔案簽章(魔術位元組)清單 複製已驗證的前綴。該參考資料將 JPEG、PNG、兩種常見的 GIF 標頭、PDF、ZIP、GZIP、7-Zip、RAR 4、RAR 5、ELF 與 SQLite 3 整合成一個可搜尋的表格，每一列都列出格式、副檔名、精確的十六進位前綴，以及一個簡短註記(例如「容器」)來標示結構上的歧異。透過格式名稱、副檔名、十六進位字串或描述性註記搜尋，單按一次鍵就能找到該列;複製動作則會取出以空白分隔的大寫位元組，供十六進位檢視器、解析器測試或偵測規則草稿使用。這個工具不會開啟任何檔案，完全在瀏覽器中執行，除了當前的分頁之外不會留下任何痕跡。
當你真正需要超過一個簽章時
當你在編寫上傳驗證器、加強事件回應手冊，或打造一個小型檔案類型嗅探器時，卡關的地方往往不是魔術位元組本身，而是能否快速找到正確的前綴。大量參考資料消除了這個摩擦，讓每個項目都有一個穩定的偏移量、一致的表示方式，以及一個統一可複製的位置。其權衡在於範圍:這個表格刻意保持精簡，因此它是一個快速查詢工具，而非完整偵測資料庫的替代品。
為什麼大量參考比死記少數前綴更好
開發者很少只需要孤立的單一簽章。檔案上傳管線必須識別影像、文件、封存檔，甚至可能包括可執行檔或 SQLite 快照。一份安全報告常常並列引用兩到三個前綴。解析器測試套件需要每個接受和拒絕樣本的精確位元組。把每個格式當成獨立查詢會浪費時間，還會在十六進位字串中引入錯字。
大量做法將每個條目統一為以空白分隔的大寫十六進位位元組，讓目光能在各列之間移動而無需重新排版。像「容器」和「兩個有效標頭」這類註記承載了位元組本身無法容納的脈絡，這正是你需要分辨 ZIP 下載檔與恰好共用相同開頭位元組的 DOCX 上傳檔時所需的資訊。
查詢並複製多個簽章
- 在瀏覽器中開啟檔案簽章(魔術位元組)清單;無需上傳任何檔案，也不需要帳號。
- 輸入符合你任務的搜尋詞:例如「PDF」之類的格式名稱、「.sqlite」之類的副檔名、「50 4B」之類的十六進位片段，或「container」、「archive」這類描述性註記。
- 閱讀符合的該列，取得格式名稱、副檔名、精確的 offset-zero 十六進位序列，以及任何關於容器重疊、版本變體或歧異的註記。
- 為你需要的每個格式重複搜尋，讓最終得到的前綴集合在表示方式與排序上保持一致。
- 在可信的二進位檢視器或十六進位傾印工具中開啟每個候選檔案，將 offset-zero 位元組與你收集到的列進行比對。
- 使用列內的複製動作複製每個顯示的十六進位字串，然後貼到文件、上傳驗證規則、解析器測試 fixtures，或事件回應紀錄中。
- 在處理或信任任何檔案之前，使用維護良好的解析器驗證其完整結構，強制實施大小限制與白名單，並將每次前綴相符視為單一訊號而非證據。
十二個簽章及其附加註記
下表摘要列出目前參考資料中的每一列。十六進位值以空白分隔的大寫位元組書寫，以便直接與十六進位檢視器進行比對。
| 格式 | 副檔名 | Offset-zero 十六進位 | 註記 |
|---|---|---|---|
| JPEG | .jpg / .jpeg | FF D8 FF | 影像;後續有多種 JFIF/EXIF 變體 |
| PNG | .png | 89 50 4E 47 0D 0A 1A 0A | 影像;固定簽章，接著是 IHDR 區塊 |
| GIF87a | .gif | 47 49 46 38 37 61 | 影像;舊版標頭 |
| GIF89a | .gif | 47 49 46 38 39 61 | 影像;支援動畫與擴充功能的標頭 |
| 25 50 44 46 | 文件;%PDF，後接版本資訊 | ||
| ZIP | .zip | 50 4B 03 04 | 容器;同樣適用於 DOCX、XLSX、JAR、EPUB |
| GZIP | .gz | 1F 8B | 封存檔;後接壓縮內容 |
| 7-Zip | .7z | 37 7A BC AF 27 1C | 封存檔;固定簽章 |
| RAR 4 | .rar | 52 61 72 21 1A 07 | 封存檔;舊版版本 |
| RAR 5 | .rar | 52 61 72 21 1A 07 01 00 | 封存檔;目前版本 |
| ELF | (無 / 可執行檔) | 7F 45 4C 46 | 可執行檔;類別資訊在 offset 4 之後 |
| SQLite 3 | .sqlite / .db | 53 51 4C 69 74 65 20 66 6F 72 6D 61 74 20 33 00 | 資料庫;「SQLite format 3」 |
這個表格並未宣稱涵蓋所有格式。它不包含媒體編解碼器、磁碟映像、字型、郵件格式，或所有封存檔變體。凡是超出此範圍者，請參閱連結的 file 指令魔術資料庫 以及各格式的規格說明。
容器格式會產生真實的歧異
offset zero 的 ZIP 本地檔案標頭 50 4B 03 04，是偵測程式碼中最常被誤用的前綴之一。它符合一般 ZIP 封存檔，但同樣符合 Office Open XML 文件(DOCX、XLSX、PPTX)、Java JAR 檔、EPUB 電子書、Android APK 套件以及其他以 ZIP 為基礎的打包檔。辨識出容器能告訴你如何解析這個檔案，但無法告訴你它代表哪一種應用程式格式。一個健全的偵測器會檢查必要的內部路徑，例如 Office 文件的 [Content_Types].xml、JAR 的 META-INF/MANIFEST.MF、EPUB 的 mimetype，並在決定如何處理上傳檔之前先檢查 content-type 中介資料。
同樣的注意事項也適用於可執行檔前綴。ELF 以 7F 45 4C 46 開頭，但這相同的四個位元組會出現在許多 Linux 二進位檔中，不論架構為何;惡意檔案可以複製這些位元組，卻在後面攜帶無關的內容。魔術位元組是一個結構性指標，並非安全性或意圖的簽章。
超越魔術位元組檢查的檔案驗證
前綴相符只是起點，不是定論。生產環境的偵測應將大量查詢與多項控制措施搭配使用。
首先，使用與候選格式相符的維護良好的解析器驗證完整結構 — ZIP 用 libzip、PNG 用 libpng、SQLite 資料庫用 SQLite C 函式庫。即使前幾個位元組對齊，也要拒絕截斷的輸入，因為解析器會在缺少區塊或中央目錄時快速失敗。
其次，在每個上傳路徑強制實施允許的副檔名、MIME 類型與大小上限的白名單。解壓縮炸彈與過大的負載完全無法透過魔術位元組偵測;它們需要明確的限制。
第三，隔離儲存、在伺服器端重新命名檔案、在適當處阻擋主動式內容，並以安全標頭提供下載。對於風險較高的流程，可能需要防毒或沙箱分析。記錄下觀察到的位元組以及解析器的判定結果，讓後續審查者能區分前綴相符與完整驗證過的檔案結構。
第四，保持偵測函式庫與解碼器的更新，並測試畸形、多語言(mixed/polyglot)、過大以及巢狀樣本。標準與實作都會演進，因此關鍵的生產環境規則應對照 SEARCH GCK 檔案簽章 資料庫、file 指令魔術資料庫，以及相關格式規格的最新上游文件進行驗證。
大量參考 vs 完整偵測資料庫
下表比較瀏覽器內的大量參考資料，以及像 file 指令魔術資料庫這樣的通用偵測規則函式庫。這是一個結構性的比較，並非對任一方法的裁斷。
| 特性 | 檔案簽章(魔術位元組)清單 | 通用 libmagic 規則 |
|---|---|---|
| 條目數量 | 十二個 offset-zero 前綴 | 數千個，橫跨多種格式 |
| 偏移處理 | 固定於 offset zero | 任意偏移、間接偏移、遮罩、巢狀條件 |
| 表示方式 | 以空白分隔的大寫十六進位 | 混合數值、字串與正則表達式 |
| 本機檔案存取 | 無 — 僅供參考 | 直接讀取檔案位元組 |
| 範圍 | 常見影像、文件、封存檔、ELF、SQLite | 包含媒體編解碼器、字型、磁碟映像、郵件格式 |
| 最佳用途 | 快速查詢、複製已驗證前綴、講解概念 | 受控管線中的生產環境偵測 |
對於處理五種常見格式的單一上傳驗證器，瀏覽器內的參考資料已足以草擬規則清單、複製精確的位元組，並推理容器重疊問題。至於大規模的生產環境偵測，file 指令規則及類似的函式庫承擔了更重的工作，因為它們能在任意偏移評估位元組序列、檢查數值端序，並組合多個條件。將大量參考視為教學與複製輔助工具 — 以及快速的健全性檢查 — 正好符合它被建構出來的範圍。
對於想從不同角度檢視同樣十二個前綴的開發者，十二個已驗證前綴指南 從已驗證前綴的角度逐步說明，而 十二個常見前綴指南 則展示每個格式如何融入典型的偵測規則。