En tecnología de la información y las comunicaciones , un tipo de medio , [1] [2] tipo de contenido [2] [3] o tipo MIME [1] [4] [5] es un identificador de dos partes para formatos de archivo y formatos de contenido . Su propósito es comparable a las extensiones de nombre de archivo y los identificadores de tipo uniforme , en el sentido de que identifican el formato de datos previsto. Se utilizan principalmente en tecnologías que sustentan Internet y también en sistemas de escritorio Linux .
La Autoridad de Números Asignados de Internet (IANA) es la autoridad oficial para la estandarización y publicación de estas clasificaciones. Los tipos de medios se definieron originalmente en Request for Comments RFC 2045 (MIME) Part One: Format of Internet Message Bodies (Nov 1996) en noviembre de 1996 como parte de la especificación MIME (Multipurpose Internet Mail Extensions) , para denotar el tipo de contenido de mensajes de correo electrónico y archivos adjuntos; [6] de ahí el nombre original, tipo MIME . Los tipos de medios también son utilizados por otros protocolos de Internet como HTTP , [7] formatos de archivos de documentos como HTML , [8] y las especificaciones XDG implementadas por entornos de escritorio Linux , [5] para fines similares.
Diferentes estándares de Internet o organismos de estandarización web difieren en el término preferido para este tipo de identificador.
La IANA y la IETF utilizan el término "tipo de medio" y consideran que el término "tipo MIME" está obsoleto, [1] ya que los tipos de medios se han utilizado en contextos no relacionados con el correo electrónico, como HTTP. Por el contrario, el WHATWG sigue utilizando el término "tipo MIME" y desaconseja el uso del término "tipo de medio" por considerarlo ambiguo, ya que se utiliza con un significado diferente en relación con la función CSS @media
. [4]
El encabezado de respuesta HTTP para proporcionar el tipo de medio es Content-Type
. [2] El W3C ha utilizado ContentType
como nombre de tipo de datos XML para un tipo de medio. [3] Las especificaciones XDG implementadas por los entornos de escritorio Linux continúan utilizando el término "tipo MIME". [5]
Un tipo de medio consta de un tipo y un subtipo , que a su vez se estructura en un árbol . Un tipo de medio puede definir opcionalmente un sufijo y parámetros :
mime-type = tipo "/" [ árbol "." ] subtipo [ "+" sufijo ] * [ ";" parámetro ];
Por ejemplo, un archivo HTML podría tener la denominación text/html; charset=UTF-8
. En este ejemplo, text
es el tipo, html
es el subtipo y charset=UTF-8
es un parámetro opcional que indica la codificación de caracteres.
Los tipos, subtipos y nombres de parámetros no distinguen entre mayúsculas y minúsculas. Los valores de los parámetros suelen distinguir entre mayúsculas y minúsculas, pero pueden interpretarse de forma que no distingan entre mayúsculas y minúsculas según el uso previsto. [6]
La parte "tipo" define el uso amplio del tipo de medio. A partir de noviembre de 1996, los tipos registrados eran: application
, audio
, image
, message
, y . [6]multipart
Para julio de 2024, los tipos registrados incluían los anteriores, además de , , y . [1]text
video
font
example
model
haptics
Un tipo de nivel superior no oficial de uso común es chemical
, utilizado para formatos de archivos químicos . [9] [10] [11] En el contexto de los entornos de escritorio Linux , se utilizan los tipos de nivel superior no oficiales inode
( inodos distintos de archivos normales, como directorios del sistema de archivos , archivos de dispositivos o enlaces simbólicos ), [12] x-content
( medios extraíbles , como cámaras digitales DCFx-content/image-dcf
) , [13] ( paquetes de administrador de paquetes ) [14] y (categorías genéricas de documentos de software de productividad de oficina ) [14] . package
x-office
Un subtipo normalmente consta de un formato de medio, pero puede o debe contener también otro contenido, como un prefijo de árbol, un productor, un producto o un sufijo, según las diferentes reglas de los árboles de registro.
Todos los tipos de medios deben registrarse utilizando los procedimientos de registro de la IANA. Para la eficiencia y flexibilidad del proceso de registro de tipos de medios, se pueden registrar diferentes estructuras de subtipos en árboles de registro que se distinguen por el uso de prefijos de árbol. Actualmente se crean los siguientes árboles: estándar (sin prefijo), proveedor ( vnd.
prefijo), personal o vanidad ( prs.
prefijo), no registrado ( prefijo). Estos árboles de registro se definieron por primera vez en noviembre de 1996 (RFC 2048 obsoleto - actualmente RFC 6838). IETFx.
Standards Action puede crear nuevos árboles de registro para el registro externo y la gestión por parte de organizaciones permanentes reconocidas (por ejemplo, sociedades científicas).
El árbol de estándares no utiliza ningún prefijo de árbol. Algunos ejemplos son text/javascript
, image/png
. [15]
Los registros en el árbol de estándares deben estar asociados con especificaciones IETF aprobadas directamente por el IESG o registrados por una organización relacionada con estándares reconocida por IANA.
El árbol de proveedores incluye tipos de medios asociados con productos disponibles públicamente. Utiliza el vnd.
prefijo de árbol. Algunos ejemplos son: application/vnd.ms-excel
, application/vnd.oasis.opendocument.text
.
Los términos "proveedor" y "productor" se consideran equivalentes en el contexto. Los consorcios industriales, así como las entidades no comerciales, pueden registrar tipos de medios en el árbol de proveedores. Cualquier persona que necesite intercambiar archivos asociados con algún producto de software o conjunto de productos puede crear un registro en el árbol de proveedores. Sin embargo, el registro pertenece al proveedor u organización que produce el software que utiliza el tipo que se está registrando, y ese proveedor u organización puede, en cualquier momento, optar por afirmar la propiedad de un registro realizado por un tercero.
El árbol personal o de vanidad incluye tipos de medios asociados con productos no disponibles públicamente o tipos de medios experimentales. Utiliza el prs.
prefijo de árbol. Algunos ejemplos son audio/prs.sid
, image/prs.btif
.
El árbol no registrado incluye tipos de medios destinados exclusivamente a su uso en entornos privados y solo con el acuerdo activo de las partes que los intercambian. Utiliza el x.
prefijo de árbol. Algunos ejemplos son application/x.foo
, video/x.bar
. Los tipos de medios de este árbol no se pueden registrar.
Este tipo se definió originalmente en el RFC 1590 (publicado en septiembre de 1993) utilizando el prefijo x-
o X-
. El RFC 2048 (publicado en noviembre de 1996) introdujo el x.
prefijo, pero desaconsejó el uso del árbol no registrado, ya que ahora hay disponibles nuevos árboles personales y de proveedores con requisitos de registro más flexibles. El RFC 6838 actual (publicado en enero de 2013) mantiene la misma recomendación, pero los subtipos con el prefijo x-
o X-
ya no se consideran miembros de este árbol.
Los tipos de medios que se han implementado ampliamente (con un subtipo prefijado con x-
o X-
) sin estar registrados, deben, si es posible, volver a registrarse con un subtipo prefijado adecuado. Si esto no es posible, el tipo de medio puede, después de una aprobación tanto del revisor de tipos de medios como del IESG, registrarse en el árbol de estándares con su subtipo sin prefijo. application/x-www-form-urlencoded
es un ejemplo de un tipo ampliamente implementado que terminó registrado con el x-
prefijo. [16]
El sufijo es una ampliación de la definición del tipo de medio para especificar adicionalmente la estructura subyacente de ese tipo de medio, lo que permite un procesamiento genérico basado en esa estructura e independiente de la semántica particular del tipo exacto. Los tipos de medios que utilizan una sintaxis estructurada con nombre deben utilizar el IANA registrado apropiado "+"suffix
para esa sintaxis estructurada cuando se registran. No se deben utilizar sufijos no registrados (desde enero de 2013). Los procedimientos de registro de sufijos de sintaxis estructurada se definen en RFC 6838. [15]
El sufijo +xml se ha definido desde enero de 2001 (RFC 3023 [17] ) y se incluyó formalmente en el contenido inicial del Registro de sufijos de sintaxis estructurada junto con +json
, +ber
, +der
, +fastinfoset
, +wbxml
, y +zip
en enero de 2013 (RFC 6839). Las adiciones posteriores incluyen +gzip
, +cbor
, +json-seq
, y +cbor-seq
. [18]
Del registro de la IANA: [1]
application/json
application/ld+json
( JSON-LD )application/msword
(.doc)application/pdf
application/sql
application/vnd.api+json
application/vnd.microsoft.portable-executable
(.efi, .exe, .dll)application/vnd.ms-excel
(.xls)application/vnd.ms-powerpoint
(.ppt)application/vnd.oasis.opendocument.text
(.odt)application/vnd.openxmlformats-officedocument.presentationml.presentation
(.pptx)application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
(.xlsx)application/vnd.openxmlformats-officedocument.wordprocessingml.document
(.docx)application/x-www-form-urlencoded
application/xml
application/zip
application/zstd
(.zst)audio/mpeg
audio/ogg
image/avif
image/jpeg
(.jpg, .jpeg, .jfif, .pjpeg, .pjp) [19]image/png
image/svg+xml
(.svg)image/tiff
(.tif)model/obj
(.obj)multipart/form-data
text/plain
text/css
text/csv
text/html
text/javascript
(.js)text/xml
Mailcap (que deriva de la frase "capacidad de correo") es un tipo de archivo meta que se utiliza para configurar la forma en que las aplicaciones compatibles con MIME, como los clientes de correo y los navegadores web, procesan archivos de diferentes tipos MIME. El formato mailcap está definido en la RFC 1524 "Un mecanismo de configuración del agente de usuario para la información de formato de correo multimedia", pero no está definido como un estándar de Internet. La mayoría de los sistemas Unix lo admiten.
Las líneas pueden ser comentarios que comiencen con el carácter # o un tipo MIME seguido de cómo manejar ese tipo MIME.
Un archivo asociado es el archivo mime.types , que asocia las extensiones de nombre de archivo con un tipo MIME . Si el tipo MIME está configurado correctamente, esto no es necesario, pero los tipos MIME pueden estar configurados incorrectamente o configurados con un tipo genérico como application/octet-stream
, y mime.types permite recurrir a la extensión en estos casos. De manera similar, dado que muchos sistemas de archivos no almacenan información de tipo MIME, sino que dependen de la extensión del nombre de archivo, los servidores web utilizan con frecuencia un archivo mime.types para determinar el tipo MIME.
Al visualizar un archivo, estos dos trabajan juntos de la siguiente manera: mime.types
asocia una extensión con un tipo MIME, mientras que mailcap
asocia un tipo MIME con un programa.
En sistemas tipo UNIX, el archivo mime.types se encuentra normalmente en y/o y el formato es simplemente que cada línea es una lista delimitada por espacios de un tipo MIME, seguida de cero o más extensiones. Por ejemplo, el tipo HTML se puede asociar con las extensiones y mediante la siguiente línea:/etc/mime.types
$HOME/.mime.types
.htm
.html
texto/html htm html
El archivo mime.types data de Netscape , donde se utilizaba un formato diferente; [20] utilizaba pares clave-valor y una lista de extensiones separadas por comas, junto con un encabezado estándar que consistía en un comentario específico que identificaba el archivo como un archivo mime.types, de la siguiente manera:
#--Información MIME de Netscape Communications Corporation# No elimine la línea anterior. Se utiliza para identificar el tipo de archivo.tipo=texto/html exts=htm,html
[RFC2046] especifica que los tipos de medios (antes conocidos como tipos MIME) y los subtipos de medios serán asignados y listados por la IANA.
HTTP utiliza tipos de medios [RFC2046] en los campos de encabezado Content-Type (Sección 8.3) y Accept (Sección 12.5.1) para proporcionar una negociación de tipos y tipificación de datos abierta y extensible.
ContentType: Un tipo de medio, según [RFC2045].
Se recomienda a los estándares que utilicen de forma coherente el término tipo MIME para evitar confusiones con el uso del
tipo de medio
, como se describe en
Consultas de medios
.