Validador de MIME Type

MIME types: a etiqueta universal do conteúdo na internet

Um MIME type (Multipurpose Internet Mail Extensions) é o identificador padronizado que diz a um software que tipo de conteúdo está dentro de uma sequência de bytes. Criado em 1992 para permitir que mensagens de e-mail carregassem anexos mais ricos que o ASCII puro, o formato rapidamente virou a língua franca de todo servidor HTTP, navegador, formulário de upload e API REST em uso hoje. Sem MIME, um navegador que recebe bytes não teria forma confiável de decidir se renderiza HTML, toca um MP3, decodifica um PNG ou força download de um binário.

A especificação original cobre cinco RFCs: RFC 2045 (formato do corpo da mensagem), RFC 2046 (tipos de mídia), RFC 2047 (codificação de cabeçalhos), RFC 2048 (procedimentos de registro) e RFC 2049 (conformidade e exemplos). Ao longo dos anos o modelo foi generalizado bem além do e-mail: a RFC 6838 (2013) formaliza as regras atuais de registro, e o registro da IANA em iana.org/assignments/media-types é a fonte canônica da verdade.

Anatomia de uma string media type

Todo MIME segue o formato tipo/subtipo, opcionalmente seguido por parâmetros separados por ponto-e-vírgula. Por exemplo: text/html; charset=UTF-8 ou multipart/form-data; boundary=----abc123. O tipo de topo (top-level type) é um dos onze oficialmente registrados:

• text — texto legível por humanos (text/plain, text/html, text/css, text/markdown).
• image — imagens raster e vetoriais (image/png, image/jpeg, image/svg+xml, image/webp, image/avif).
• audio — som (audio/mpeg, audio/ogg, audio/wav).
• video — vídeo (video/mp4, video/webm).
• application — binário genérico ou dado estruturado (application/json, application/pdf, application/octet-stream).
• multipart — mensagens compostas (multipart/form-data, multipart/mixed).
• message, model, font, example, haptics — nichos, mas oficialmente registrados.

O subtipo pode ser um nome registrado (html), prefixado por vendor (application/vnd.ms-excel, application/vnd.api+json), experimental pessoal (application/x-custom) ou usar um sufixo estruturado combinando formato base e serialização: +json, +xml, +zip, +cbor. É por isso que image/svg+xml diz ao parser "isso é SVG transportado como XML".

Usos no mundo real: HTTP, e-mail e sistemas

MIME types aparecem muito além do óbvio cabeçalho HTTP Content-Type. Eles também alimentam o cabeçalho Accept usado em negociação de conteúdo; restringem o que o seletor de arquivo HTML mostra via <input type="file" accept="image/*,application/pdf">; rotulam partes dentro de uploads multipart/form-data; identificam anexos em multipart/mixed; e regem estratégias de cache em service workers. No macOS e iOS, todo UTType mapeia para um ou mais MIME; no Linux, shared-mime-info dirige a associação de arquivos do freedesktop.

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 87

{"ok":true,"user":"alice"}

Plataformas modernas inventam seus próprios subtipos: Web App Manifests usam application/manifest+json; binários WebAssembly usam application/wasm; Server-Sent Events usam text/event-stream; fontes WOFF2 usam font/woff2 (o top-level font só foi formalizado em 2017 pela RFC 8081). Markdown finalmente virou text/markdown na RFC 7763 (2016).

Validação: nunca confie no MIME enviado pelo cliente

Uma vulnerabilidade comum é confiar no MIME type que o navegador declara durante um upload. O agente do usuário envia o que o sistema operacional adivinhou a partir da extensão, e um atacante reescreve trivialmente o valor com um proxy. Pipelines robustos validam uploads em duas camadas: (1) confere sintaticamente se a string casa com um media type registrado, e (2) sniffing de magic bytes contra os primeiros bytes do arquivo real — PNG sempre começa com 89 50 4E 47, PDF com %PDF-, JPEG com FF D8 FF. Bibliotecas maduras como mime-types (npm), python-magic (bindings libmagic) e Apache Tika cobrem as duas camadas.

Navegadores também fazem content sniffing quando o servidor envia Content-Type ausente ou genérico. É conveniente, mas já causou XSS reais (arquivo enviado como text/plain sendo executado como HTML). A contramedida é o cabeçalho de resposta X-Content-Type-Options: nosniff, que proíbe o navegador de adivinhar.

Erros comuns e anti-padrões

• Esquecer charset=UTF-8 em text/html e text/plain — gera Mojibake com acentos.
• Usar application/octet-stream como fallback é aceitável, mas desativa preview no browser.
• Devolver text/html de uma API JSON — confunde clientes e quebra preflight CORS em alguns setups.
• Confundir application/x-www-form-urlencoded com multipart/form-data — só o segundo carrega arquivos.
• Inventar tipos como text/json em vez do registrado application/json.

FAQ

Devo validar uploads apenas pelo MIME type? Não. O MIME declarado pelo cliente é trivialmente forjável. Sempre confira magic bytes do stream real no servidor e idealmente reencode imagens por biblioteca segura.

Qual MIME usar em upload multipart? multipart/form-data; boundary=.... O parâmetro boundary é obrigatório e precisa ser único dentro da mensagem; bibliotecas geram automaticamente.

Como registrar um MIME novo? Envie um pedido à IANA seguindo a RFC 6838. Tipos pessoais ou experimentais usam prefixo x.; tipos de fornecedor vão sob vnd..

São case-sensitive? Não. Application/JSON e application/json equivalem pela RFC 2045, mas o lowercase é a forma canônica.

Por que meu navegador ignora o tipo que enviei? Ou você esqueceu o X-Content-Type-Options: nosniff e o browser fez sniffing, ou um proxy upstream reescreveu o header. Inspecione a resposta no DevTools.