Assinaturas de ficheiro e números mágicos

O que é uma assinatura de ficheiro?

Uma assinatura de ficheiro, ou número mágico, é uma sequência curta e fixa de bytes no início de um ficheiro que diz de que tipo ele é. Todos os PNG começam pelos mesmos oito bytes; todos os arquivos gzip pelos mesmos dois. Os programas leem-nos porque o nome não é prova nenhuma: mudar o nome de uma folha de cálculo para .png não altera nada do que lá está dentro, e um ficheiro vindo da internet tem o nome que quem o enviou lhe quis dar.

A lista abaixo traz 33 formatos com os seus bytes, em que ponto do ficheiro esses bytes estão e o tipo de media quando existe registado. O que traz também, e que as tabelas copiadas umas das outras deixam de fora, é o documento que define cada assinatura. Essa coluna acaba por ser a interessante.

Porque a resposta não é uniforme. Algumas assinaturas estão fixadas no texto normativo de uma norma publicada. Outras apenas na documentação do próprio fabricante. Outras num documento que já não tem peso nenhum. E umas quantas — ICO, bzip2, 7-Zip — são implementadas de forma idêntica por todas as ferramentas do mundo e nunca foram escritas em lado nenhum como requisito.

Como usar

1. Largue um ficheiro, ou escolha-o. Só se lê o cabeçalho, e quem o lê é o seu navegador. Nada é enviado. Se alguma assinatura corresponder, obtém o formato, os bytes que corresponderam e onde estão definidos.
2. Ou cole os bytes que já tem. Se está a olhar para um despejo hexadecimal, cole os primeiros bytes. Aceitam-se espaços, prefixos 0x e minúsculas; só é preciso um número par de dígitos.
3. Procure na lista por qualquer coisa da linha. Servem o nome do formato, uma extensão, um tipo de media, um prefixo hexadecimal ou o nome de uma especificação. Escrever png põe o PNG em primeiro em vez de o enterrar debaixo de tudo o que contenha aquelas letras.

A assinatura do PNG, e a explicação que a norma deixou cair

O PNG é o formato que vale a pena ver de perto, porque os seus oito bytes são os mais bem desenhados da lista e a história deles não é a que se esperaria. São 137, 80, 78, 71, 13, 10, 26, 10 — em texto, um byte com o bit alto ligado, depois PNG, depois um retorno de carro, uma mudança de linha, um control-Z e outra mudança de linha.

Cada um está a fazer alguma coisa. O primeiro byte não é de propósito um caractere ASCII, para que um ficheiro de texto dificilmente seja confundido com um PNG e, sobretudo, para apanhar uma transferência que limpe o bit alto de cada byte. O retorno de carro e a mudança de linha apanham o problema oposto: uma transferência que converta amavelmente os fins de linha entre plataformas estraga esse par, e o ficheiro falha ao quinto byte em vez de falhar algures no meio da imagem. O control-Z impede o MS-DOS de despejar o resto de um binário no terminal quando alguém lhe faz type. A mudança de linha final apanha o inverso da conversão CR-LF.

E aqui está a parte que nos surpreendeu. Essa explicação não está na norma atual. A ISO/IEC 15948, que é o que normaliza o PNG hoje, enuncia os oito bytes e segue em frente, guardando uma única frase na sua cláusula de fundamentação a dizer que a assinatura deteta erros comuns de transmissão. O raciocínio byte a byte sobrevive apenas no RFC 2083 de 1997 — um documento marcado como Informativo, que a norma entretanto substituiu. Os bytes são normativos. As razões para serem aqueles bytes não são.

Limites honestos

Uma assinatura diz o que um ficheiro afirma ser, e é exatamente por isso que se verifica — mas é também o seu limite. Os bytes da frente são baratos de falsificar. Se está a decidir se algo é seguro de abrir, uma assinatura que corresponde diz-lhe que o ficheiro está suficientemente bem formado para ter um cabeçalho plausível e mais nada.

Nem todas as assinaturas começam no início. O marcador ustar que identifica um arquivo tar está no byte 257, e o CD001 do ISO 9660 no byte 32769, mais de 32 kilobytes lá para dentro. Tudo o que leia apenas os primeiros quatro bytes falha por completo os dois formatos de arquivo e de imagem de disco mais comuns, e é por isso que esta ferramenta lê mais longe.

Vários formatos são indistinguíveis no cabeçalho, e a ferramenta di-lo em vez de adivinhar. WebP, WAV e AVI começam pelos mesmos quatro bytes, porque os três são contentores RIFF e os bytes que os separam vêm depois. Um .docx, um .xlsx, um .jar, um .apk e um .epub são todos arquivos ZIP e levam a assinatura do ZIP; distingui-los obriga a descomprimir e ver o que está lá dentro, o que é outro trabalho. Nos dois casos mostram-se todas as correspondências em vez de se escolher uma.

Muitos formatos não têm assinatura nenhuma. CSV, texto simples, quase todo o código-fonte e SVG são apenas caracteres, e não há nada de fixo à frente com que comparar — o SVG em particular é XML, que pode começar ou não por uma declaração. Um ficheiro que não corresponde a nada daqui disse-lhe muito pouco.

Por fim, 33 formatos são uma seleção e não um censo, e a lista está limitada de propósito. A resposta completa de facto é a base de dados mágica que acompanha o comando file do Unix, com milhares de regras, lógica condicional e aritmética de bytes. O que está nesta página é o subconjunto cujos bytes se conseguem verificar contra um ficheiro real que os testes desta página constroem, portanto cada linha está verificada e não transcrita.

Porque é grátis

Porque não custa nada manter. A lista faz parte da página e a identificação acontece no seu navegador: quando larga um ficheiro, só se leem os primeiros bytes, e são lidos localmente. Nada é enviado, nenhum servidor vê o seu ficheiro e não há conta.

A tabela não está copiada de outra tabela. Cada linha que se consegue construir é verificada contra um ficheiro produzido por um codificador real, e cruzada com a identificação do próprio comando file, portanto um dígito trocado parte a compilação em vez de chegar à página. Onde um formato não pôde ser construído aqui, a página di-lo em vez de o deixar por verificar em silêncio.