Prefixos comuns de Base64: identifique o arquivo pelo início

Tabela de prefixos

Cada linha foi conferida codificando os bytes mágicos reais do formato. O prefixo listado é a parte que nunca muda naquele formato. Os caracteres seguintes dependem do resto do arquivo.

Algumas linhas merecem uma observação:

• RIFF é um contêiner. O nome do formato fica nos bytes 8 a 11, e os bytes 9 a 11 viram do 13º ao 16º caractere: RUJQ para WebP (EBP), QVZF para WAV (AVE), Vkkg para AVI (VI ). A primeira letra do nome do formato divide um grupo de 3 bytes com o tamanho do arquivo, então não gera um caractere estável.
• zlib não tem um prefixo único. O segundo byte registra o nível de compressão: eJ para o nível padrão, eN para os níveis 7 a 9, eF para 2 a 5, eA para 0 e 1 (como gravado pelo zlib do Python).
• JSON só começa com eyJ quando os dois primeiros caracteres são {" sem espaço. { "a": 1 } começa com eyAi, um { formatado seguido de quebra de linha começa com ewo, e um array [ começa com W.
• DER: as estruturas começam com a tag SEQUENCE 30, que sempre dá M. Um comprimento de dois bytes (30 82) dá MII, e o caractere seguinte acompanha o comprimento: uma chave pública RSA 2048 é MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA, um certificado típico é MIIC, MIID ou MIIE. Estruturas curtas usam comprimento de um byte: uma chave privada Ed25519 começa com MC4C, uma chave pública P-256 com MFkw.
• Chaves públicas SSH começam com um comprimento big-endian de 4 bytes, então o blob começa com AAAA. Os caracteres seguintes soletram o tipo da chave: AAAAC3NzaC1lZDI1NTE5 é ssh-ed25519, AAAAB3NzaC1yc2E é ssh-rsa, AAAAE2VjZHNh é ecdsa. Fora do SSH, uma sequência de A significa apenas bytes zero.
• MP3 sem tag ID3 começa direto com um cabeçalho de frame. Os bits de sincronização FF Fx geram um // inicial, por exemplo //uQ para FF FB 90.
• Base64URL substitui + e /, então o prefixo do JPEG vira _9j_. Os outros prefixos da tabela não contêm nenhum dos dois e ficam iguais nos dois alfabetos.

Por que o prefixo é estável

O Base64 trabalha com grupos de 3 bytes. Cada grupo de 3 bytes vira exatamente 4 caracteres, e esses 4 caracteres dependem só desses 3 bytes. Nada do restante do arquivo vaza para trás. Então, se um formato sempre começa com os mesmos 3 bytes, o Base64 dele sempre começa com os mesmos 4 caracteres.

bytes:   FF       D8       FF
bits:    11111111 11011000 11111111
groups:  111111 111101 100011 111111
index:   63     61     35     63
chars:   /      9      j      /

Quando o valor mágico fixo não tem um comprimento múltiplo de 3 bytes, o último grupo mistura bits conhecidos com bits do resto do arquivo. Veja o %PDF-, de 5 bytes. Os 3 primeiros bytes dão 4 caracteres estáveis (JVBE). Os 2 bytes seguintes dão mais 2 (Ri), e o sétimo caractere mistura os últimos 4 bits do - com os 2 primeiros bits do dígito da versão. Todo dígito começa com os bits 00, então na prática esse caractere é sempre 0. Depois de JVBERi0 a versão aparece: JVBERi0xLjQ é %PDF-1.4, JVBERi0xLjc é %PDF-1.7, JVBERi0yLjA é %PDF-2.0.

A assinatura PNG tem 8 bytes, o que dá 10 caracteres estáveis. O décimo primeiro mistura o último byte da assinatura com o primeiro byte do comprimento do chunk IHDR, que é sempre 0, então iVBORw0KGgo se mantém. Como todo PNG continua com esse chunk IHDR, os PNGs reais compartilham um prefixo ainda maior: iVBORw0KGgoAAAANSUhEUg.

Quando o prefixo se desloca

O prefixo só funciona quando os bytes mágicos estão no deslocamento 0, 3, 6 e assim por diante. Acrescente um byte na frente e todos os grupos se deslocam, então os caracteres mudam completamente:

Com 3 bytes extras o alinhamento volta e o prefixo conhecido reaparece 4 caracteres depois. Motivos comuns para um prefixo deslocado ou ausente:

• Uma marca de ordem de bytes (BOM). Texto UTF-8 com BOM começa com 77u/ (EF BB BF). O BOM tem 3 bytes, então um JSON depois dele ainda mostra eyJ: 77u/eyJ…. Texto UTF-16 com BOM começa com //4 ou //5 (little-endian) ou /v8 (big-endian).
• Texto UTF-16. Texto salvo como UTF-16LE coloca um byte zero depois de cada caractere ASCII, o que produz muitos A: Hello vira SABlAGwAbABvAA==. O -EncodedCommand do PowerShell tem essa cara. Use o decodificador de PowerShell ou Base64 para UTF-16.
• Compressão ou criptografia. Um PNG compactado com gzip começa com H4sI; um arquivo criptografado não tem prefixo reconhecível nenhum.
• Um data URI. data:image/png;base64, é um cabeçalho; o Base64 começa depois da vírgula. O parser de data URI separa as duas partes para você.
• Quebras de linha e espaços em branco. Eles não deslocam os bytes, mas uma busca de prefixo com startswith falha se a string começa com uma quebra de linha ou aspas. Remova-os antes, ou passe a string pelo Reparar Base64.

Verificando um prefixo no código

Dá para comparar os primeiros caracteres como strings, mas comparar os bytes decodificados é menos propenso a erro: os números mágicos vêm direto da especificação de cada formato, e você nunca precisa descobrir quais caracteres são estáveis. Decodificar só os primeiros 12 caracteres dá os primeiros 9 bytes, o suficiente para a maioria das assinaturas:

import base64

SIGNATURES = {
    b"\x89PNG\r\n\x1a\n": "png",
    b"\xff\xd8\xff": "jpeg",
    b"%PDF-": "pdf",
    b"PK\x03\x04": "zip",
    b"\x1f\x8b": "gzip",
}

def sniff(b64: str) -> str:
    head = base64.b64decode(b64.strip()[:12])
    for magic, name in SIGNATURES.items():
        if head.startswith(magic):
            return name
    return "unknown"

print(sniff("iVBORw0KGgoAAAANSUhEUgAAAAEAAAAB"))  # png
print(sniff("JVBERi0xLjcKJcfsj6IK"))              # pdf

A ferramenta Base64 para arquivo faz a mesma verificação com uma lista maior e mostra uma prévia quando o navegador consegue renderizar o formato. Para ver como os grupos de 6 bits viram caracteres, leia como o Base64 funciona e a tabela do alfabeto.

Perguntas frequentes