命令列工具可以檢查本機檔案位元組，而 File Signatures (Magic Bytes) List 則是一份以瀏覽器為基礎的參考資料，可供搜尋並複製 12 個固定在位移 0 的前綴。
實際差異在於，命令列工作流程會讀取特定的本機檔案，而線上清單則協助你找到已知前綴以供比對。查詢或分類結果成功，只能算是證據，不能證明檔案完整、安全，或僅屬於單一格式。
命令列查詢與線上查詢各自的功能
依照你想回答的問題選擇：「這個本機檔案是以哪些位元組開頭？」適合使用命令列工具；「這種格式記載的前綴是什麼？」則適合使用線上清單。兩者工作不同，而線上查詢表並不是上傳掃描器。
| 方法 | 功能 | 最適用情況 | 主要限制 |
|---|---|---|---|
| 命令列分類器 | 讀取特定的本機檔案並套用 magic 規則 | 更廣泛的模式式分類 | 標籤並不等於結構驗證或安全判定 |
| 原始位元組命令 | 顯示檔案的開頭位元組 | 比對候選簽章 | 本身無法識別格式 |
| 線上 File Signatures List | 搜尋 12 個固定在位移 0 的前綴，並複製其位元組值 | 尋找文件或規則草擬所依據的已知前綴 | 不會要求、讀取、上傳或掃描本機檔案 |
| 持續維護的解析器 | 驗證必要的內部結構 | 做出信任或處理決策 | 需要特定格式的解析與獨立安全控制 |
Unix file 命令採用較廣泛的 magic 規則模型，其相關內容收錄於 file 命令 magic 資料庫。這些規則可評估其他位移的位元組序列、間接位移、遮罩、數值位元組序、字串及巢狀條件。線上清單則將每個項目固定在位移 0，以建立清楚且可測試的範圍，並未重現該規則系統。清單也省略可執行檔子類型、媒體編解碼器、磁碟映像、字型、郵件格式及所有壓縮檔變體。
在命令列檢查本機檔案
- 選擇確切的候選檔案。 將檔案路徑直接傳給每個命令；如果路徑包含空格，請加上引號。將副檔名視為線索，而非格式的證據。
- 讀取開頭位元組。 在已安裝 xxd 的 Unix-like 系統上，執行 xxd -l 16 sample.bin。另一個常見替代方式是 od -An -tx1 -N 16 sample.bin。兩者的輸出配置不同，因此應比對位元組值，而非空白、大小寫、位址欄或 ASCII 欄。
- 執行較廣泛的分類器。 若要讓已安裝的 magic 規則建議類型，請使用 file sample.bin 或 file --brief sample.bin。結果可能取決於工具版本及機器上可用的 magic 資料庫。
- 比對預期前綴。 請檢查確切數值及其位置，不要依賴外觀相似。例如，ZIP 本機檔案標頭為 50 4B 03 04，但此數值只能確立其為 ZIP 格式的容器，不能確定其中儲存的特定應用程式格式。
- 驗證完整結構。 在信任或處理候選檔案之前，先交由持續維護且針對特定格式的解析器處理。將觀察到的位元組與解析器判定分開記錄，以免將前綴相符誤認為檔案已通過驗證。
此 shell 工作流程的範圍比靜態查詢清單更廣，因為它能檢查實際的本機資料並採用更廣泛的規則。但它仍具有相同的信任界限：十六進位檢視可確立存在哪些內容，而解析器則可確立必要結構是否有效。
線上清單何時是更好的選擇
清單涵蓋 JPEG、PNG、GIF87a、GIF89a、PDF、ZIP、GZIP、7-Zip、RAR 4、RAR 5、ELF 與 SQLite 3。因此會產生 12 個經來源查核的項目，包括兩種常見的 GIF 標頭。每個項目都固定在位移 0，數值以空格分隔的大寫十六進位位元組顯示，因此可直接與十六進位檢視器、解析器規則或事件分析筆記比對。
當你需要依格式、副檔名、位元組或「container」等筆記搜尋；將已知前綴複製到文件或經過測試的偵測規則；或在不將檔案傳送至任何地方的情況下，比對可信賴的二元檢視結果時，請使用此工具。它完全在瀏覽器中執行，不會要求或讀取本機檔案，並可在目前分頁中完成搜尋與複製，無須帳戶或新增相依套件。它不是通用的檔案掃描器；如需更廣泛的涵蓋範圍，請查閱 SEARCH GCK File Signatures 資料庫及相關格式規格。
以 4 個步驟複製並驗證簽章
- 搜尋格式。 輸入格式名稱、副檔名、十六進位數值或「container」等筆記。依副檔名搜尋可縮小可能的範圍，但無法驗證副檔名的真實性。
- 在位移 0 進行比對。 在可信賴的二元檢視工具中開啟候選檔案，並將其前幾個位元組與顯示的簽章比對。請考慮十六進位表示法的差異，也不要將檔案其他位置的相符結果視為等同於固定在位移 0 的項目。
- 複製確切前綴。 文件或經過測試的偵測規則應使用所顯示、以空格分隔的大寫位元組。保留規則來源與版本，讓日後審查者能重現比對。
- 確認完整結構。 在信任或處理檔案之前，先使用持續維護的解析器驗證完整檔案。同時記錄觀察到的位元組與解析器判定，不要將審查結果簡化為單一「magic bytes matched」結果。
有些格式允許開頭資料、多個有效簽章或特定版本的標頭。短前綴也可能與無關內容發生碰撞，因此無法比對某個固定項目並不會自動識別檔案，正如比對成功也無法驗證檔案。
為何一個前綴可能隱藏多種格式
ZIP 本機檔案標頭可能出現在 Office Open XML 文件（例如 DOCX 和 XLSX）、Java JAR 壓縮檔、EPUB 檔案及其他套件中。清單明確標示了這項歧義：50 4K 03 04 可識別 ZIP 為基礎的容器，但無法區分其中包含的應用程式格式。
健全的容器偵測器必須檢查必要的內部路徑、中繼資料、關聯與內容類型。它也應防範解壓炸彈與路徑穿越。即使容器結構有效，也不能確立檔案安全：惡意檔案可以複製預期位元組，同時將無效或危險的載荷資料放在檔案後方。
生產環境檔案檢查的控制措施
線上清單不會驗證上傳內容、強制執行安全政策或授權檔案。生產環境的實作應加入符合風險程度的控制措施：
- 使用允許清單。 將通過驗證的解析器結果與預期格式結合，並強制執行大小限制；不要只因副檔名或前綴相符就接受檔案。
- 處理敵對輸入。 拒絕遭截斷或格式錯誤的檔案、維護已修補的解碼器，並對多格式混合、超大型、巢狀及對抗性近似相符的範例進行回歸測試。
- 控制儲存與傳遞。 依通過驗證的類型在伺服器端重新命名檔案、隔離儲存的上傳內容、在適當情況下封鎖有效內容，並使用安全標頭提供下載。
- 提升高風險分析的處理層級。 當前綴相符不足以支援工作流程時，可能需要防毒軟體或沙箱分析。
- 保護內部細節。 避免向不受信任的使用者公開解析器錯誤、檔案系統路徑或偵測規則。
絕不可僅因前綴與清單相符就授權上傳。magic 位元組相符只是其中一項訊號，應與結構解析、資源限制、可信賴的解碼器及情境特定的安全控制一併考量。
選擇符合任務的方法
依照所需結果，使用適當的組合：
- 檢查未知的本機檔案： 使用 xxd 或 od 查看原始位元組，使用 file 命令進行較廣泛的分類，並使用持續維護的解析器做出判定。
- 查詢已知格式： 使用線上 File Signatures List 搜尋並複製有記載且位於位移 0 的前綴，而不需讀取檔案。
- 建立生產環境偵測機制： 將經來源查核的前綴與完整結構驗證、允許清單、資源限制及適當的安全控制結合使用。
簡而言之，命令列可回答「這個本機檔案的位元組與較廣泛的規則顯示了什麼？」線上清單則可回答「我應該比對哪個已知前綴？」兩者都無法取代完整驗證。