文件签章检查

副档名是说法，字节才是证据

档名结尾是 .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 偶尔在第一格多出  的原因。

相关

全部在你的浏览器里完成。若要验证文件的内容而不是类型， 杂凑产生器用同样的方式做指纹。