Disponible la nueva versión "donationware" 7.3 de OrganiZATOR
Descubre un nuevo concepto en el manejo de la información.
La mejor ayuda para sobrevivir en la moderna jungla de datos la tienes aquí.

Notas sobre Internet

[Home]  [Inicio]  [Índice]


8.1.2  Configuración:  problema de los formatos

§1  Presentación del problema

Para entender cabalmente el asunto de la codificación y los formatos, es conveniente recordar que en la transmisión de correo confluyen varios conceptos y problemas distintos.  Hemos visto ( 8.1), que el sistema de correo empezó en USA, en máquinas UNIX (aunque incluso en estas existían mas de una versión de ASCII [1] ), de modo que la versión usada en el e-mail estándar, es la denominada US-ASCII, que utiliza palabras de 7 bits, por lo que estrictamente hablando, el e-mail solo es capaz de transmitir mensajes escritos con este juego de caracteres (texto Americano imprimible). Como justamente era esa su utilización inicial, el e-mail cumplía su cometido a la perfección y no existían problemas. Sin embargo, el sistema fue pronto utilizado para transmitir mensajes escritos en otras lenguas (utilizando otros sistemas de codificación distintos del US-ASCII). Además, aunque no había sido el objetivo inicial en el ánimo de su inventor, se hacía cada vez mas necesario poder transmitir ficheros binarios, porque la gente empezaba a querer utilizar el correo como medio de transmitir todo tipo de contenidos, además de texto.

Para ilustrar el problema en su situación actual, supongamos el caso en que un hipotético amigo árabe (Omar) desea enviarme por e-mail una felicitación que contiene un texto y un pequeño mensaje sonoro (suponemos que lo envía desde su PC, que está configurado para escribir texto en su lengua).

Evidentemente, el primer problema es el idioma; no conozco el árabe, así que voy a mostrar el mensaje a un vecino que s'i lo conoce, para que me lo traduzca). La segunda cuestión es el sistema de codificación utilizado.  En está escrito en árabe; los símbolos (extraños para mi) que él escribe, son codificados en su computadora mediante un sistema especial (por ejemplo Árabe de Windows), así que cuando Omar pulsa la letra d, su PC lo transforma en un código ASCII extendido (de 8 bits) que normalmente será mostrado en mi PC como el carácter Æ.  El tercer problema es el trozo sonoro del mensaje, es un fichero WAV codificado en binario (un tipo de fichero de audio de Microsoft).

Cuando Omar compone el mensaje y da la orden de enviar, IMAP debe componer un datagrama con la cabecera y el cuerpo ( 8.1),  pero recordemos que generalmente los MUAs solo conocen de transmisiones en US-ASCII (7 bits), por lo que en principio no habría forma de transmitir nada codificado en 8 bits ni en binario.  Además, sería conveniente incluir en el mensaje alguna indicación del sistema de codificación utilizado para el texto y el trozo sonoro.  Así mi PC podría ser capaz de mostrar el texto en su grafía original (caracteres árabes que debe leer mi vecino) y llamar al programa que será capaz de reproducir los sonidos del fichero WAV.

Por supuesto toda esta información es incluida junto con otros datos, en la cabecera del mensaje, así que (suponiendo que arbitremos una fórmula para enviarlo), una vez leída esta (la cabecera), es posible obtener información sobre la estructura del cuerpo mensaje.  Evidentemente nos enfrentamos a un problema circular.  ¿Como leer la cabecera sin saber como está codificada?.

Para resolver el problema, IMAP da un tratamiento distinto a la cabecera y al cuerpo de los mensajes.  Los datos de cabecera están escritos exclusivamente en US-ASCII, de forma que esta parte del mensaje puede circular libremente por los MUAs. Además, los clientes de correo pueden interpretar fácilmente su contenido.

Una vez resuelta esta parte del problema, solo quedaba el de la transmisión del cuerpo de los mensajes.  Es justamente el objeto del presente capítulo, pero adelantemos que la solución consistió en transformar cualquier contenido en US-ASCII antes de transmitirlo, y reconvertirlo de nuevo al formato original en el destino.

§2  La solución

Como hemos visto, el sistema de correo necesitaba poder transmitir ficheros binarios además de texto, pero el problema no se reducía a esto. Los creadores del protocolo SMTP habían establecido dos condiciones a los mensajes que empezaban a ser molestas: ni la longitud total de una línea ni del mensaje podían exceder de 1.000 caracteres.  Además, debido a que los textos pueden ser enviados y recibidos por usuarios de máquinas muy distintas (no hay porqué suponer que todo el mundo lo hará en Windows sobre un PC) y al conocido problema con los formatos (incluso ASCII), puede darse el caso que lo escrito por un noruego en un Apple lo reciba un hispano como sánscrito en un PC, y no digamos nada si está escrito en Ruso o Japonés.  Incluso utilizando código ASCII de 7 bits, el mensaje solo se transmitía bien (sin trastocar caracteres) si las máquinas origen y destino utilizaban la misma versión.

Para resolver el problema se inventaron varios procesos, todos basados en el mismo principio: transformar el fichero no ASCII en US-ASCII (de 7 bits);  transmitirlo en este formato, y reconvertirlo en el destino al formato original.  El proceso de transformar no ASCII en US-ASCII se denomina "codificar" (encode), el inverso "decodificar" (decode) reconstruye el fichero original en la máquina del destinatario. Aunque el sistema funcionaba bien, con la evolución del servicio empezó a verse que no era suficiente. Algunas redes y enrutadores que no utilizaban el protocolo UUCP [2], corrompían el contenido de las transmisiones. Usuarios y fabricantes ofrecieron soluciones, pero con frecuencia, las diversas parejas encoders/decoders de diversos fabricantes no coincidían exactamente, con el resultado de que no hacían bien el trabajo.

Para resolver este y otros problemas, en 1991 la IETF ( 2.1a) comenzó a desarrollar un sistema denominado MIME ("Multipurpose Internet Mail Extensions Encoding"). Se trata de un estándar con dos finalidades muy concretas: de un lado, normalizar el modo de intercambiar por Internet todo tipo de archivos de forma transparente para el usuario (texto, audio, vídeo, etc.). De otra, acabar con el problema de las transferencias de texto internacional (al que aludíamos al principio del párrafo) por correo electrónico. El estándar ha sido ampliamente aceptado y en la actualidad no solamente ha sido integrado en los programas de correo, de forma que ya aceptan cualquier juego de caracteres (incluso trozos multimedia en los mensajes), sino que se ha integrado en el protocolo HTTP de la Web. El resultado es que cuando se recibe una página, el navegador examina las cabeceras, identifica el tipo de archivo y lo abre o ejecuta según su tipo.

Desgraciadamente, a la fecha (1998) no es todavía la panacea universal, subsisten muchos clientes de correo que no lo tienen correctamente implementado o que utilizan codificaciones no compatibles.

El entandar MIME es muy amplio (su descripción ocuparía mas de 100 páginas), no obstante, podemos decir que la base del proceso está en especificar como se enviarán los ficheros según su clase (mediante unas tablas que el programa consulta y que le indican cual es la acción adecuada en función del tipo de contenido). En la nota adjunta ( Nota16) se amplían algunos detalles sobre este importante estándar para los lectores que quieran saber algo mas sobre las opciones de configuración que nos ofrece el programa de correo.

§3  Configurar el cliente de correo

Antes de enviar mensajes, se debe estar seguro que se tiene bien configurado el cliente de correo, sobre todo la configuración MIME.  A este respecto hay un procedimiento que permite ver como queda nuestro mensaje. Consiste en hacer una prueba, enviando un mensaje a la dirección: echo@rediris.es, que contestará automáticamente tal como lo veríamos. El sistema es válido para hacer una primera prueba de comprobación general, pese a que un destinatario real, distinto de nosotros mismos, podría recibirlo de forma distinta (por otros problemas de configuración).

Figura 1

Si utilizamos el español en la redacción de nuestros mensajes, no solo no hay inconveniente en puntuar bien (acentos diéresis, etc.), sino que "se debe" [3]. Para ello es necesario configurar el cliente de correo correctamente. En la nota antes señalada ( Nota16) se amplían algunos detalles al respecto, pues el tipo de codificación elegido tiene gran influencia. Para el español es mejor elegir la codificación MIME "Quoted-Printable".

En la figura adjunta (Fig.1) se muestra el cuadro de diálogo de configuración del cliente de correo MS Outlook Express 5.50.  Dentro de este programa, el cuadro de la figura es accesible en:  Herramientas Opciones Enviar.

Para los propósitos de este capítulo solo nos interesan las opciones Configuración internacional y las de configuración de envío de correo y de noticias.

La opción Incluir mensaje en la respuesta será comentada al tratar del envío y recepción de mensajes ( 8.1.4).

§3.1  Codificación de nuestros mensajes

Suponiendo que utilizamos MS Outlook 5.50, esta opción es accesible en el botón Configuración Internacional (Fig.1), que conduce al cuadro de diálogo de la figura 2.

Figura 2

Aquí decidimos que juego de caracteres que se usará al enviar mensajes internacionales. En nuestro caso, utilizamos el Europeo occidental.

Recordemos que la cabecera del mensaje se codifica en US-ASCII. Esto hace que los campos origen ("From"), destino ("To") y resumen ("Subject") sean codificados en este formato. La consecuencia para nosotros es que sea preferible no utilizar acentos al escribir estos campos, ya que es altamente probable que estos caracteres no sean correctamente interpretados por algunos agentes de correo.

En el cuadro de la figura 2, la marca Usar encabezados en inglés al responder a un mensaje, se refiere a utilizar las palabras inglesas To, From y Subject en nuestros mensajes, incluso aunque el idioma de la respuesta no sea inglés. Esto es conveniente, en especial cuando nuestros mensajes son atendidos por sistemas automáticos. Por ejemplo los que nos dan de alta y de baja las listas de correo y servicios análogos.

§3.2  Codificación de formato de envío de correo

Con el aumento de capacidad de los clientes de correo, comenzó a ser posible que estos mostrasen correctamente mensajes cuyo cuerpo estuviese escrito en HTML ( 5.2). Esta nueva capacidad ha extendió la costumbre de enviar e-mails que más parecen páginas Web que meros mensajes de texto.

Los clientes de correo Microsoft Outlook Express permiten utilizar ambas formas, tanto para los mensajes normales de correo como para los mensajes enviados a grupos de noticias ("News"). Mi consejo es utilizar en ambos casos texto sin formato ("Plain text"). En caso de mensajes normales se optimiza el ancho de banda. Además siempre podemos adjuntar como un atadillo ("attachment") cualquier fichero que deseemos enviar; documento, imagen, etc.

En cuanto a los mensajes enviados a grupos de noticias, generalmente es obligatorio enviarlos en formato de texto ASCII y sin ningún atadillo.

Nota:  Aunque el tema será tratado con más profundidad al tratar las normas de etiqueta en la red (Netiqueta), adelantemos aquí que los mensajes a grupos de noticias deben ser texto sin formato, lo más concisos posibles, y solo enviar un fichero adjunto si es solicitado expresamente. En estos casos es preferible no enviar la respuesta al grupo de noticias, sino responder particularmente al contertulio que lo solicitó.

  Inicio.


[1]  Para comprender cabalmente esta parte de la exposición, le recomendamos que leer una breve introducción a los ordenadores electrónicos digitales ( E0.1) y a los tipos que se utilizan para almacenar texto, los denominados caracteres ASCII (E2.2.1a).

[2]  UUCP  ("Unix to Unix Copy Program").  Protocolo de comunicaciones desarrollado en 1976 en los laboratorios AT&T Bell. Utiliza un esquema de codificación para los contenidos a transmitir denominado Uuencode, distinto del sistema MIME que es el más popular actualmente en Internet.

[3]  Es cierto que el correo electrónico permite un nivel de informalidad mucho mayor que el usual en el sistema de correo tradicional, pero nunca está de más prestar cierta atención a la forma (sintaxis y ortografía). Además de ser una deferencia hacia nuestro interlocutor y de mejorar y clarificar la comunicación, una correcta ortografía dice mucho en favor del que escribe.