Referência de Tipos MIME

Tipos MIME (Extensões de Correio da Internet Multipropósito) são uma forma padrão de indicar a natureza e formato de documentos, arquivos ou byte streams. Navegadores e servidores usam tipos MIME para determinar como lidar com conteúdo. Por exemplo, receber image/jpeg diz ao navegador para exibir uma imagem. Tipos MIME descrevem que tipo de conteúdo um arquivo ou resposta HTTP contém, como text/html, application/json, image/png ou application/pdf. Eles afetam renderização do navegador, downloads, parsing de APIs, validação de upload, cache e comportamento de segurança. Extensão e MIME nem sempre coincidem, então verificá-los ajuda ao diagnosticar servidor, arquivos desconhecidos ou problemas de envio. Por segurança, tipos MIME não devem ser confiados cegamente; inspeção de conteúdo, regras de extensão e allowlist explícita devem trabalhar juntas.

Tipos MIME (Multipurpose Internet Mail Extensions) são identificadores padronizados para formatos de dados, originalmente definidos no RFC 2045/RFC 2046 para anexos de e-mail e posteriormente adotados pelo HTTP (RFC 7231 §3.1.1.5) para negociação de conteúdo web. Um tipo MIME é estruturado como tipo/subtipo — o tipo declara a categoria ampla (text, image, audio, video, application, multipart, font, model) e o subtipo especifica o formato exato (por exemplo, text/html, image/png, application/json). Parâmetros opcionais seguem um ponto e vírgula (text/html; charset=utf-8).

A Internet Assigned Numbers Authority (IANA) mantém o registro oficial de tipos MIME em iana.org/assignments/media-types. O registro segue o RFC 6838, que define um processo de revisão exigindo um documento de especificação, considerações de segurança e notas de interoperabilidade. Tipos não registrados podem usar o prefixo x- (por exemplo, application/x-tar) como convenção para formatos experimentais ou específicos de fabricantes, embora o RFC 6648 recomende evitar o prefixo x- em favor do registro adequado.

No HTTP, o cabeçalho Content-Type informa ao cliente como interpretar o corpo da resposta. Um servidor que retorna Content-Type: image/svg+xml aciona o renderizador SVG do navegador; Content-Type: application/octet-stream aciona um prompt de download porque o navegador não consegue determinar o formato. O navegador também usa informações de tipo MIME para MIME sniffing — quando um servidor omite o Content-Type ou envia um tipo genérico, o navegador pode inspecionar os primeiros bytes da resposta (magic bytes) para adivinhar o formato real. Esse comportamento é controlado pelo cabeçalho X-Content-Type-Options: nosniff, que desabilita o sniffing e exige que o servidor declare o tipo correto.

Para uploads de arquivos, o cabeçalho Accept informa ao servidor quais tipos MIME o cliente espera na resposta, enquanto o atributo accept do elemento input restringe o seletor de arquivos a tipos específicos (por exemplo, accept="image/png, image/jpeg"). No lado do servidor, arquivos enviados devem ser validados tanto pelo tipo MIME declarado quanto pela assinatura do arquivo (magic bytes), pois nenhum dos dois isoladamente é confiável — um arquivo chamado image.png com Content-Type: image/png pode conter código executável. A ferramenta serve como referência para consultar o tipo MIME canônico de uma determinada extensão de arquivo, cobrindo mais de 100 formatos comuns em oito categorias.

• Estrutura RFC 2046: tipo/subtipo — o tipo indica a categoria ampla de conteúdo e o subtipo o formato exato; parâmetros opcionais seguem um ponto e vírgula (text/html; charset=utf-8) e são case-insensitive por especificação, embora minúsculas seja a convenção.
• Registro IANA (RFC 6838): Novos tipos de mídia exigem um documento de especificação, seção de considerações de segurança e notas de interoperabilidade — o processo de revisão garante que os tipos sejam bem documentados e que conflitos sejam evitados antes de entrarem no registro.
• Cabeçalho HTTP Content-Type: O servidor declara o tipo MIME do corpo da resposta; os navegadores o usam para selecionar o renderizador apropriado (parser HTML, decodificador de imagens, visualizador de PDF) ou acionar um download — um Content-Type incorreto é a causa mais comum de bugs de 'download em vez de exibição'.
• MIME sniffing e X-Content-Type-Options: Quando o Content-Type está ausente ou é genérico, navegadores podem inspecionar magic bytes para adivinhar o formato — X-Content-Type-Options: nosniff desabilita esse comportamento e exige uma correspondência exata do Content-Type, o que é uma boa prática de segurança.
• application/octet-stream: O tipo genérico de fallback binário — navegadores o tratam como um fluxo opaco e acionam um download, sendo a opção mais segura quando o servidor não consegue determinar o formato, mas impede a visualização no navegador de conteúdo que poderia ser exibido.
• Validação de upload de arquivos: O atributo accept do input filtra o seletor de arquivos no lado do cliente, mas a validação no servidor deve verificar tanto o Content-Type declarado quanto os magic bytes do arquivo — uma incompatibilidade entre extensão, tipo MIME e assinatura do arquivo é um sinal de alerta para uploads maliciosos.
• Tipos específicos de fabricantes e experimentais: A convenção do prefixo x- (application/x-tar, video/x-matroska) é anterior ao processo formal de registro — o RFC 6648 recomenda migrar esses tipos para tipos registrados na IANA sempre que possível, mas muitos permanecem em uso amplo.