Multipurpose Internet Mail Extensions

Multipurpose Internet Mail Extensions
Tipu	estándar d'Internet
Etiqueta de Stack Exchange	Stack Exchange

Multipurpose Internet Mail Extensions o MIME (n'español "estensiones multipropósito de corréu d'internet") son una serie de convenciones o especificaciones empobinaes al intercambiu al traviés d'Internet de too tipu d'archivos (testu, audiu, videu, etc.) de forma tresparente pal usuariu. Una parte importante del MIME ta dedicada a ameyorar les posibilidaes de tresferencia de testu en distintos idiomes y alfabetos. En sentíu xeneral les estensiones d'MIME van empuestes a soportar:

Testu en conxuntos de calteres distintos d'US-ASCII;
adxuntos que nun son de tipu testu;
cuerpos de mensaxes con múltiples partes (multi-part);
información d'encabezadures con conxuntos de calteres distintos de ASCII.

Práuticamente tolos mensaxes de corréu electrónicu escritos por persones n'Internet y una proporción considerable d'estos mensaxes xeneraos automáticamente son tresmitíos en formatu MIME al traviés de SMTP. Los mensaxes de corréu electrónicu n'Internet tán tan cercanamente acomuñaos col SMTP y MIME que usualmente llámase-yos mensaxe SMTP/MIME.^[1]

En 1991 la IETF (Grupu de Trabayu n'Inxeniería d'Internet, Internet Engineering Task Force n'inglés) empezó a desenvolver esta norma y dende 1994 toles estensiones MIME tán especificaes de forma detallada en diversos documentos oficiales disponibles n'Internet.

MIME ta especificáu en seis Request for Comments o RFC (n'español "solicitú de comentarios): RFC 2045, RFC 2046, RFC 2047, RFC 4288, RFC 4289 y RFC 2077.

Los tipos de conteníu definíos pol estándar MIME tienen gran importancia tamién fuera del contestu de los mensaxes electrónicos. Exemplu d'esto son dalgunos protocolo de rede tales como HTTP de la Web. HTTP rique que los datos sían tresmitíos nun contestu de mensaje tipo e-mail anque los datos pueden nun ser un e-mail puramente dichu.

Na actualidá nengún programa de corréu electrónicu o navegador d'Internet puede considerase completu si nun acepta MIME nes sos distintes facetes (testu y formatos d'archivu).

Introducción

El protocolu básicu de tresmisión de mensaxes electrónicos d'Internet soporta namái calteres ASCII de 7 bit (vease tamién 8BITMIME). Esto llinda los mensaxes de corréu electrónicu, yá que inclúin namái calteres abondos pa escribir nun númberu amenorgáu de llinguaxes, principalmente Inglés. Otros llinguaxes basaos nel Alfabetu llatín ye adicionalmente un componente fundamental en protocolos de comunicación como HTTP, el que rique que los datos sían tresmitíos como un e-mail anque los datos pueden nun ser un e-mail puramente dichu. Los veceros de corréu y los Servidor de corréu servidores de corréu converten automáticamente dende y a formatu MIME cuando unvien o reciben (SMTP/MIME) e-mails.

Nomenclatura de tipos

MIME asigna un nome a cada tipu de datos. Los nomes siguen el siguiente formatu:

tipu/subtipo (tipu como subtipo son cadenes de calteres)

El tipu define la categoría xeneral de los datos y el subtipo define un tipu más específicu d'esos datos. El tipu puede contener los siguientes valores:

text: Indica que'l conteníu ye testu planu. Exemplos de subtipos: html, xml
multipart: Indica que tien múltiples partes de datos independientes. Exemplos de subtipos: form-data, digest
message: Pa encapsular un mensaxe esistente. Por casu cuando queremos responder a un mensaxe de corréu incorporando'l mensaxe orixe. Exemplos de subtipos: partial, rfc822
image: Indica que ye una imaxe. Ej de subtipos: png, gif
audiu: Indica que ye un audiu. Exemplos de subtipos: mp3, 32kadpcm
video: Indica que ye un video. Exemplos de subtipos: mpeg, avi
application: Indica que se trata de datos d'aplicación los cualos pueden ser binarios. Exemplos de subtipos: json, pdf

MIME headers

MIME-Version

La presencia d'esta encabezadura indica que'l mensaxe utiliza'l formatu MIME. El so valor ye típicamente igual a "1.0" polo qu'esta encabezadura apaez como:

MIME-Version: 1.0

Tien De señalase que los implementadores intentaron camudar el númberu de versión nel pasáu y el cambéu tuvo resultancies imprevistes. Nuna xunta d'IETF realizada en xunetu 2007 decidió caltenese el númberu de versión en "1.0" anque se realizaron munches actualizaciones a la versión d'MIME.

Content-Type

Esta encabezadura indica'l tipu de mediu que representa'l conteníu del mensaxe, consiste nun tipu: type y un subtipo: subtype, por casu:

Content-Type: text/plain

Al traviés del usu del tipu multiparte (multipart), MIME da la posibilidá de crear mensaxes que tengan partes y subpartes entamaes nuna estructura arbórea na que los nodos fueya pueden ser cualquier tipu de conteníu non multiparte y los nodos que nun son fueyes pueden ser de cualesquier de les variedaes de tipos multiparte. Esti mecanismu soporta:

mensaxes de testu planu usando text/plain (este ye'l valor implícitu pa la encabezadura "Content-type:")
testu más archivos axuntos (multipart/mixed con una parte text/plain y otres partes que nun son de testu, por casu: application/pdf pa documentos PDF, application/vnd.oasis.opendocument.text para OpenDocument text). Un mensaxe MIME qu'inclúi un archivu axuntu xeneralmente indica'l nome orixinal del archivu con una encabezadura "Content-disposition:" o por un atributu name de Content-Type, polo que'l tipu o formatu del archivu indícase usando tantu la encabezadura MIME content-type y la extensión del archivu (usualmente dependiente del SO).

Content-Type: application/vnd.oasis.opendocument.text;
name="Carta.odt"
Content-Disposition: inline;
filename="Carta.odt"

reenviar col mensaxe orixinal axuntu (multipart/mixed con una parte text/plain y el mensaxe orixinal como una parte message/rfc822)
conteníu alternativo, un mensaxe que contién el testu tantu en testu planu como n'otru formatu, usualmente HTML (multipart/alternative col mesmu conteníu en forma de text/plain y text/html)
munches otres construcciones de mensaxe

Content-Transfer-Encoding

En Xunu de 1992, MIME (RFC 1341 queda obsoleta pola nueva RFC 2045) define un conxuntu de métodos pa representar datos binarios usando testu ASCII. La encabezadura MIME content-transfer-encoding: indica'l métodu que foi usáu. La RFC y la llista de IANA definen los siguientes valores, que nun son sensibles a mayúscules nin minúscules:

Fayadizos pa usar con SMTP:
- 7bit — soporta hasta 998 octetos per llinia de códigu; los calteres tán nel rangu ente 1..127 con CR y LF (códigos 13 y 10 respeutivamente) que namái pueden apaecer como parte d'un fin de llinia CRLF. Este ye'l valor implícitu pa esta encabezadura.
- Quoted printable — usáu pa codificar secuencies arbitraries de octetos de forma que satisfaiga les regles de 7bit. Foi diseñáu pa ser eficiente y na mayoría de los casos legible pa un humanu cuando ye usáu con datos de testu que consisten primariamente en calteres del conxuntu US-ASCII y que tamién contengan porciones de bytes con valores que tán fora d'esi rangu.
- base64 — usáu pa codificar secuencies arbitraries de octetos de forma que satisfaiga les regles de 7bit. Tien una sobrecarga fixa al executar l'algoritmu y tien el propósitu de ser usáu con datos que nun sían de testu o testos que contengan pocos valores dientro del rangu de ASCII.
Fayadizu pa usar con servidores SMTP que soporten 8BITMIME estensiones SMTP:
- 8bit — soporta hasta 998 octetos per llinia de códigu, los calteres tán nel rangu ente 1..256 con CR y LF (códigos 13 y 10 respeutivamente) que namái pueden apaecer como parte d'un fin de llinia CRLF.
Afechos namái pa usar con servidores SMTP que soporten la estensión SMTP BINARYMIME (RFC 3030):
- binary — cualquier secuencia de octetos.

Nun esiste una codificación definida explícitamente pa unviar datos binarios arbitrarios al traviés d'un tresporte SMTP coles estensiones 8BITMIME. Por tanto base64 o quoted-printable (coles sos ineficiencias acomuñaes) tienen que ser usaes entá. Estes restricciones nun s'apliquen a otros usos d'MIME como son Servicio Web con adxuntos MIME o MTOM

Encoded-Word

Dende la RFC 2822, los nomes y valores de les encabezadures MIME de mensaxes son siempres calteres ASCII; los valores que contengan otru tipu de calteres tienen qu'usar la sintaxis de pallabra codificada o encoded-word (RFC 2047) en llugar del testu lliteral. Esta sintaxis utiliza una cadena de calteres ASCII qu'indica'l conxuntu de calteres orixinal (el "charset") y el content-transfer-encoding usáu pa mapear los bytes del conxuntu orixinal a calteres ASCII.

La so forma xeneral ye:

=?charset?codificación?testu codificado?=

charset puede ser cualquier conxuntu de calteres rexistráu con IANA. Típicamente va coincidir col charset del cuerpu del mensaxe.
codificación puede ser: "Q" que denota Q-encoding que ye similar a la codificación quoted-printable, o "B" que denota la codificación base64.
testu codificado ye'l testu codificado con Q-encoding o base64.

Diferencies ente Q-encoding y quoted-printable

Los códigos ASCII del signu d'entruga (?) y el signu d'igualdá (=) nun pueden ser representaos direutamente yá que ellos son usaos como allindiadores del encoded-word. El códigu ASCII reserváu pal espaciu nun puede ser representáu direutamente porque puede causar qu'intérpretes antiguos estremen, de forma ensin deseyar, el encoded-word. Pa faer la codificación más pequeña y bono de lleer, el símbolu sorrayáu (_) utilizar en llugar del espaciu, creando l'efectu colateral qu'esti símbolu non pueda representase direutamente. L'usu de encoded-word en ciertes partes de les encabezadures impon otres restricciones sobre cuálos calteres pueden o nun ser representaos direutamente.

Por casu:

Subject: =?utf-8?Q?=C2=A1Hola,_se=C3=B1or!?=

ye interpretáu como:

Subject: ¡Hola, señor!

El formatu encoded-word nun s'utiliza pa los nomes de les encabezadures (por casu Subject). Estos nomes d'encabezadures son siempres n'Inglés. Cuando se llee'l mensaxe con un veceru de corréu n'otru idioma que nun sía Inglés, los nomes de les encabezadures son traducíos pol veceru.

Mensaxes multiparte

Un mensaxe MIME multiparte contién una frontera na encabezadura "Content-type:"; esta frontera, que nun puede apaecer en nenguna de les partes, ye allugada ente caúna d'elles, y al entamu y a la fin del cuerpu del mensaxe, como s'amuesa de siguío:

MIME-version: 1.0
Content-type: multipart/mixed; boundary="frontera"

This is a multi-part message in MIME format.
--frontera Content-type:
text/plain

Esti ye'l cuerpu del mensaxe --frontera Content-type:

application/octet-stream
Content-transfer-encoding: base64

PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+RXN0ZSBlcyBlbCBjdWVy
cG8gZGVsIG1lbnNhamU8L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cic=\
--frontera--

Cada parte consiste de la so propia encabezadura de conteníu (cero o más campos d'encabezadures Content-) y un cuerpu. El conteníu multiparte pue tar añeráu. L'encabezáu content-transfer-encoding d'un tipu multiparte tien siempres que ser "7bit", "8bit" o "binary" pa evitar los entueyos impuestos cola presencia de múltiples niveles de decodificación. El bloque multiparte, como un tou, nun tien especificación avera del conxuntu de calteres (charset); los calteres non ASCII nes encabezadures de la parte son remanaos al traviés d'Encoded-Word, y los cuerpos de les partes pueden tener conxuntos de calteres especificaos si aplicara pal so tipu de conteníu.

Notes:

Antes de la primer frontera hai una área que ye inorada por veceros de corréu electrónicu que soporten MIME. Esta área ye xeneralmente usada pa poner un mensaxe pa usuarios de veceros vieyos que nun soporten MIME.
Nun ye hasta'l momentu d'unviar el mensaxe que'l veceru de corréu escueye una cadena de calteres pa usar na frontera ente les partes, esto dexa buscar una cadena de testu que nun coincida con nenguna porción del cuerpu de nenguna de les partes. Esto típicamente ye implementáu usando una cadena llarga xenerada aleatoriamente.

Subtipos de Multiparte

L'estándar MIME define dellos subtipos pa mensaxes multiparte, estos especifiquen la naturaleza de la parte del mensaxe y la so rellación con otres partes. El subtipo ye especificáu na encabezadura "Content-type" pa tol mensaxe. Por casu, un mensaxe MIME multiparte qu'usa'l subtipo digest va tener un "Content-Type": "multipart/digest".

La RFC primeramente define 4 subtipos: mixed, digest, alternate y parallel. Una aplicación que cumpla mínimamente l'estándar tien de soportar siquier mixed y digest; el restu de los subtipos son opcionales. Otres RFCs definen subtipos adicionales como: signed y form-data.

Lo que sigue ye una llista de los subtipos más comúnmente usaos:

Mixed

Multipart/mixed ye usáu pa unviar mensaxes o archivos con distintos encabezaos "Content-Type" yá sía en llinia o como axuntos. Si unvien imáxenes o otros archivos fácilmente legibles, la mayoría de los veceros de corréu electrónicu van amosar como parte del mensaxe (nun siendo que se especifique de manera distinta la encabezadura "Content-disposition"). D'otra manera van ser ufiertaos como axuntos. El content-type implícitu pa cada parte ye "text/plain".

Definíu en RFC 2046, Seición 5.1.3

Message

Una parte message/rfc822 contién un mensaxe de corréu electrónicu, incluyendo cualesquier E-mail#Escritura del mensaxe encabezáu. Rfc822 ye un nome erróneu, yá que el mensaxe puede ser un mensaxe MIME completu. Ye usáu tamién pa resumenes el reenviar mensaxes.

Definíu na RFC 2046.

Digest

Multipart/digest ye una forma simple d'unviar múltiples mensaxes de testu. El content-type implícitu pa cada parte ye "message/rfc822".

Definíu en RFC 2046, Seición 5.1.5.

Alternative

El subtipo multipart/alternative indica que cada parte ye una versión "alternativa" del mesmu conteníu (o similar), caúna en formatos distintos denotados pola so encabezadura "Content-Type". Los formatos son ordenaos atendiendo a cuan fieles son al orixinal, col menos fiel al entamu. Los sistemes pueden escoyer la "meyor" representación qu'ellos son capaces de procesar; polo xeneral esta va ser la postrera parte que'l sistema entiende, nun siendo qu'otros factores puedan afectar esti comportamientu.

Yá que ye pocu probable qu'un veceru quiera unviar una versión que ye pocu fiel a la versión en testu planu, esta estructura alluga la versión en testu planu (si esiste) primeru. Esto facilita la xera de lleer los mensaxes pa los usuarios de veceros que nun entienden mensaxes multipartes.

Lo qu'asocede más comúnmente ye usar multipart/alternative pa mensaxes con dos partes, una como testu planu (text/plain) y una HTML (text/html). La parte en testu planu aprove compatibilidá con veceros vieyos que nun son capaces d'entender otros formatos, ente que la parte HTML dexa usar formatu de testu y enllaces. Munchos veceros de corréu ufierten al usuariu la posibilidá de preferir testu planu sobre HTML; esto ye un exemplu de como factores locales pueden afectar cómo una aplicación escueye cuál ye la "meyor" parte del mensaxe p'amosar.

Anque se pretende que cada parte represente'l mesmu conteníu, esto nun ye riquíu. Dellos filtros antispam esaminen namái la parte text/plain d'un mensaxe porque ye más bono d'analizar que les partes text/html. Pero los spammers al notar esto, empezaron a crear mensaxes con una parte text/plain qu'aparenta ser inocua ya inclúin la propaganda na parte text/html. Los mantenedores de programes anti-spam modificaron los sos filtros, penalizando a los mensaxes con testos bien distintos nun mensaxe multipart/alternative.

Definíu en RFC 2046, Seición 5.1.4

El subtipo multipart/related ye usáu pa indicar que les partes del mensaxe nun tienen de ser consideraes individualmente sinón como amestaos d'un tou. El mensaxe consiste d'una parte raigañu (implícitamente la primera) que fai referencia a otres partes, les que de la mesma pueden faer referencia a otres partes. Les partes son comúnmente referenciaes pola encabezadura: "Content-ID". La sintaxis de la referencia nun ta especificada sinón que ta dictada pola codificación o'l protocolu usáu na parte que contién la referencia.

Un usu común d'esti subtipo ye pa unviar páxina web completes con imáxenes nun únicu mensaxe. Partir raigañu contendría'l documentu HTML, qu'usaría etiquetes HTML pa imáxenes, pa referise a les imáxenes almacenaes en partes subsiguientes.

Definíu en RFC 2387

Report

Multipart/report ye un tipu de mensaxe que contién datos formateados por que un servidor de corréu interpretar. Ta ente un text/plain (o dalgún otru tipu de conteníu fácilmente legible) y un message/delivery-status.

Definíu en RFC 3462

Signed

El subtipo multipart/signed ye usáu p'axuntar una firma dixital al mensaxe. Esta tien dos partes, una parte cuerpu y una parte robla. La parte del cuerpu completa, incluyendo les encabezadures MIME, ye usada pa crear la parte de la firma. Esisten munchos tipos de firmes, como application/pgp-signature y application/x-pkcs7-signature.

Definíu en RFC 1847, Seición 2.1

Encrypted

Un mensaxe multipart/encrypted tien dos partes. La primera contién información de control que ye necesaria pa descifrar la segunda parte, de tipu: application/octet-stream.

Definíu en RFC 1847, Seición 2.2

Form Data

Como'l so nome indicar, multipart/form-data ye usada pa espresar valores unviaos al traviés d'un formulariu. Orixinalmente definíu como parte de HTML 4.0, ye mayormente utilizáu pa unviar archivo vía HTTP.

Definíu en RFC 2388

Mixed-Replace (Esperimental)

El tipu de conteníu multipart/x-mixed-replace foi desenvueltu como parte d'una teunoloxía pa emular server push y streaming sobre HTTP.

Toles partes d'un mensaxe mixed-replace tienen el mesmu significáu semánticu. Sicasí, cada parte invalida - "reemplaza" - a la parte previa asina ye recibida dafechu. Los veceros tienen de procesar la parte individual al momentu de la so llegada y nun tienen d'esperar a que termine'l mensaxe completu.

Desenvueltu orixinalmente por Netscape, entá ye soportáu por Mozilla, Firefox, Safari (pero non en Safari pa iPhone) y Opera, pero tradicionalmente inorada por Microsoft.

Ver tamién

Referencies

↑ [1]

RFC 1847: Multiparte Seguro para MIME: Multipart/Signed y Multipart/Encrypted
RFC 2045: MIME Parte Unu: Formatu y Cuerpu de Mensaxes d'Internet.
RFC 2046: MIME Parte Dos: Tipos de Medios. N. Freed, Nathaniel Borenstein. Payares 1996.
RFC 2047: MIME Parte Trés: Estensiones pa Encabezadures de Mensaxe pa testu non ASCII. Keith Moore. November 1996.
RFC 4288: MIME Parte Cuatro: Especificación de Tipos de Medios y Procedimientos de Rexistru de los mesmos.
RFC 4289: MIME Parte Cuatro: Procedimientos de Rexistru. N. Freed, J. Klensin. December 2005.
RFC 2049: MIME Parte Cinco: Criteriu de Conformidá y Exemplos. N. Freed, N. Borenstein. November 1996.
RFC 2231: Valores de Parámetros MIME y Estensiones Encoded Word : Conxuntos de Calteres, Llinguaxes, y Continuaciones. N. Freed, K. Moore. November 1997.
RFC 2387: El Content-type MIME Multipart/Related
RFC 1521: Mecanismos pa Especificar y Describir el Formatu de los Cuerpos de los Mensaxes d'Internet.

Enllaces esternos

[1] [1]

[1]