Referencia de tipos MIME

Los tipos MIME (Extensiones de Correo de Internet de Propósito Múltiple) son un estándar para indicar la naturaleza y formato de documentos, archivos o flujos de bytes. Los navegadores y servidores usan tipos MIME para determinar cómo manejar el contenido. Por ejemplo, recibir image/jpeg indica al navegador mostrar una imagen. Los tipos MIME describen qué clase de contenido contiene un archivo o respuesta HTTP, como text/html, application/json, image/png o application/pdf. Afectan renderizado del navegador, descargas, parseo de APIs, validación de subidas, caché y comportamiento de seguridad. Extensión y MIME no siempre coinciden, por lo que conviene revisarlos al diagnosticar configuración de servidor, archivos desconocidos o problemas de carga. Por seguridad, no deben confiarse a ciegas; inspección de contenido, reglas de extensión y lista permitida deben usarse juntas.

Los tipos MIME (Multipurpose Internet Mail Extensions) son identificadores estandarizados para formatos de datos, definidos originalmente en RFC 2045/RFC 2046 para adjuntos de correo electrónico y adoptados posteriormente por HTTP (RFC 7231 §3.1.1.5) para la negociación de contenido web. Un tipo MIME tiene la estructura tipo/subtipo: el tipo declara la categoría general (text, image, audio, video, application, multipart, font, model) y el subtipo especifica el formato exacto (por ejemplo, text/html, image/png, application/json). Los parámetros opcionales siguen tras un punto y coma (text/html; charset=utf-8). La Internet Assigned Numbers Authority (IANA) mantiene el registro oficial de tipos MIME en iana.org/assignments/media-types. El registro sigue el proceso definido en RFC 6838, que requiere un documento de especificación, consideraciones de seguridad y notas de interoperabilidad. Los tipos no registrados pueden usar el prefijo x- (por ejemplo, application/x-tar) como convención para formatos experimentales o específicos de un fabricante, aunque RFC 6648 recomienda evitar el prefijo x- en favor de un registro adecuado. En HTTP, la cabecera Content-Type indica al cliente cómo interpretar el cuerpo de la respuesta. Un servidor que devuelve Content-Type: image/svg+xml activa el renderizador SVG del navegador; Content-Type: application/octet-stream provoca un aviso de descarga porque el navegador no puede determinar el formato. El navegador también usa la información de tipo MIME para el content sniffing: cuando el servidor omite Content-Type o envía un tipo genérico, el navegador puede inspeccionar los primeros bytes de la respuesta (magic bytes) para adivinar el formato real. Este comportamiento se controla con la cabecera X-Content-Type-Options: nosniff, que desactiva el sniffing y exige al servidor declarar el tipo correcto. Para subidas de archivos, la cabecera Accept indica al servidor qué tipos MIME espera el cliente en la respuesta, mientras que el atributo accept del elemento input restringe el selector de archivos a tipos específicos (por ejemplo, accept="image/png, image/jpeg"). En el servidor, los archivos subidos deben validarse tanto por su tipo MIME declarado como por su firma de archivo (magic bytes), ya que ninguno de los dos es fiable por sí solo: un archivo llamado image.png con Content-Type: image/png podría contener código ejecutable. La herramienta sirve como referencia para buscar el tipo MIME canónico de una extensión de archivo concreta, cubriendo más de 100 formatos comunes en ocho categorías.

• Estructura RFC 2046: tipo/subtipo — el tipo indica la categoría general del contenido y el subtipo el formato exacto; los parámetros opcionales siguen tras un punto y coma (text/html; charset=utf-8) y son insensibles a mayúsculas según la especificación, aunque por convención se escriben en minúsculas.
• Registro IANA (RFC 6838): los nuevos tipos de medios requieren un documento de especificación, una sección de consideraciones de seguridad y notas de interoperabilidad; el proceso de revisión garantiza que los tipos estén bien documentados y se eviten conflictos antes de entrar en el registro.
• Cabecera HTTP Content-Type: el servidor declara el tipo MIME del cuerpo de la respuesta; los navegadores lo usan para seleccionar el renderizador adecuado (analizador HTML, decodificador de imágenes, visor de PDF) o activar una descarga — un Content-Type incorrecto es la causa más frecuente de errores donde 'el archivo se descarga en lugar de mostrarse'.
• Content sniffing y X-Content-Type-Options: cuando Content-Type falta o es genérico, los navegadores pueden inspeccionar los magic bytes para adivinar el formato; X-Content-Type-Options: nosniff desactiva este comportamiento y exige una coincidencia exacta de Content-Type, lo cual es una buena práctica de seguridad.
• application/octet-stream: el tipo genérico de respaldo para binarios — los navegadores lo tratan como un flujo opaco y activan una descarga, convirtiéndolo en la opción más segura por defecto cuando el servidor no puede determinar el formato, pero impide la vista previa en el navegador de contenido que de otro modo sería visible.
• Validación de subida de archivos: el atributo accept del input filtra el selector de archivos en el cliente, pero la validación en el servidor debe comprobar tanto el Content-Type declarado como los magic bytes del archivo; una discrepancia entre extensión, tipo MIME y firma de archivo es una señal de alerta ante subidas maliciosas.
• Tipos específicos de fabricantes y experimentales: la convención del prefijo x- (application/x-tar, video/x-matroska) es anterior al proceso formal de registro; RFC 6648 recomienda migrar estos tipos a registros IANA adecuados siempre que sea posible, pero muchos siguen en uso generalizado.