檔案簽章檢查

副檔名是說法，位元組才是證據

檔名結尾是 .jpg，只說明了有人決定這樣叫它，完全沒有說裡面是什麼。開頭那幾個位元組通常會說： 大多數二進位格式的開頭都是一段固定的樣式，也就是 magic number，放在那裡的用意正是讓程式 不必相信檔名就能認出檔案。

把檔案拖到上面，這個頁面會讀開頭 512 個位元組，告訴你它們說了什麼。它不會多讀，也不會把任何東西 送出去——這正是重點，因為你會想查一個檔案的類型，通常就是因為你不信任它。

不一致代表什麼，不代表什麼

副檔名與位元組不一致時，頁面會直說。無害的常見原因：

• 有人把 .png 改名成 .jpg，好通過上傳限制。
• 下載時伺服器送錯 Content-Type，存下來的副檔名就跟著錯。
• 檔案其實是 .docx，而 .docx 本來就是 ZIP。位元組沒錯，是預期錯了。

比較不無害的原因：披著圖片副檔名的腳本或執行檔，或者刻意做成同時是兩種合法格式的 polyglot 檔案。 不一致是「值得看一下」的理由，不是判決。

而相符能證明的，比看起來少得多。 magic number 就只是開頭那幾個位元組。一個檔案可以用 %PDF- 開頭，而其餘幾乎全是別的東西。簽章檢查是一道快速的篩子，不是驗證器。

最容易搞錯的幾個情況

PK 不等於「一個 ZIP 檔」

50 4B 03 04——PK 加兩個控制位元組，取自 Phil Katz——是每一個 ZIP 壓縮檔的開頭。它同時也是 每一個 .docx、.xlsx、.pptx、.odt、.jar、.apk、.epub 的開頭，因為這些本來就是 ZIP，只是內部有約定好的結構。再怎麼讀開頭的位元組都分不出來，只能把壓縮檔打開看裡面有什麼。

RIFF 與 ftyp 要看第二段

有些格式先放一個通用的容器標記，真正的格式在後面幾個位元組：

ISO base media 也一樣：ftyp 在位移 4，品牌代碼在 8——所以 MP4、MOV、HEIC、AVIF 的前四個 位元組完全相同。任何「一個格式一個樣式」的對照表在這裡都會出錯。

CA FE BA BE 是兩種東西

它是 Java .class 檔的 magic number，1991 年選它是因為那是一個唸得出來的十六進位單字。它同時 也是 macOS 上 Mach-O universal binary 的 magic number。兩個都對；只挑一個講的工具是在猜。

tar 的簽章在第 257 個位元組

ustar 出現在位移 257，不在開頭，因為 tar 比「把標頭放在檔案最前面」這個慣例還早。只讀前十六個 位元組的話，每一個 tar 檔都會認不出來。

根本沒有簽章的格式

純文字、CSV、JSON、HTML、JavaScript、Markdown、大部分原始碼——一個都沒有，因為它們從來不是設計成 讓機器讀四個位元組就認出來的。頁面說「沒有已知的檔案簽章」時，那往往是正確答案，不是失敗。

例外是 byte order mark：文字檔開頭的 EF BB BF 是 UTF-8 BOM，也是 CSV 偶爾在第一格多出  的原因。

相關

全部在你的瀏覽器裡完成。若要驗證檔案的內容而不是類型， 雜湊產生器用同樣的方式做指紋。