Publicaciones


[Home] [Index]

ISO 8859

Sopa de caracteres

Copyright 1995 by Carles Bellver Torlà <bellverc@si.uji.es>
Universitat Jaume I

La información es cosa de bits. Todos los datos (texto, imágenes, voz) que se guardan en las memorias y en los discos de ordenadores, y que se transmiten por las líneas de comunicación, se han codificar en forma digital como secuencias de bits: señales que pueden ser sólamente unos o ceros. Los bits van en paquetes de ocho; son los llamados octetos o bytes. Ocho bits dan para representar exactamente 256 valores distintos, valores numéricos que van del 0 al 255. Pero eso son números, claro. Cuando lo que hay que representar es texto, los sistemas utilizan tablas que establecen la equivalencia entre los caracteres y los códigos de caracteres: los números utilizados convencionalmente para representar aquellos símbolos. Estas tablas son lo que se denomina conjuntos de caracteres (character sets). Dado un character set, cualquier texto se puede codificar electrónicamente como una serie de bytes que representan los carácteres (y los finales de línea, pero esa otra historia y debe ser contada en otra ocasión).

En los días antiguos, la informática nació y creció por iniciativa del complejo militar-industrial norteamericano. Cuando hubo que definir un conjunto de caracteres estándar, común para los distintos fabricantes, sólo se tuvieron en cuenta los símbolos más usuales del inglés. Quedaron fuera, por lo tanto, las vocales acentuadas y muchos caracteres utilizados en otros idiomas occidentales. Este conjunto es el famoso American Standard Code for Information Interchange (ASCII; norma ANSI X3.4; norma ISO 646).

ASCII consituye, en palabras de André Pirard, "un insulto al octeto". Es cierto, ya que sólo aprovecha los primeros 7 bits, la mitad de los 256 códigos posibles: del 0 al 127. Del 128 al 255 quedaba media tabla vacia. Eso era espacio suficiente para muchos más carácteres, pero no se podia pedir a los sesudos técnicos americanos que anticipasen nuestras necesidades y se preocupasen por nuestras peculiares y simpáticas eñes. Este trabajo nos correspondía a los europeos, y no lo hicimos.

Más adelante, la expansión de la industria informática y la internacionalización de los mercados obligó a los fabricantes a ampliar por su cuenta el conjunto ASCII para dar respuesta a las exigencias de la clientela francesa, alemana, española, etc. Desgraciadamente, a falta de un estándar cada uno hizo con esa segunda mitad de la tabla de caracteres lo que le vino en gana. Los mismos caracteres recibían distintos códigos en sistemas comercializados por IBM, DEC, Apple, Atari, Commodore, etc. Ahí comienza la torre de Babel del texto electrónico.

En este punto, el estándar llegó un poco tarde, cuando gran parte del daño ya estaba hecho. Pero más vale tarde que nunca. Instituciones oficiales y fabricantes se pusieron de acuerdo en una norma ratificada por la International Standardisation Organisation (ISO). Es la norma ISO 8859, que aprovecha el espacio vacio dejado por el conjunto ASCII para acomodar los símbolos de otros idiomas. En realidad, como los 128 valores númericos de la segunda mitad de la tabla no bastan para representar los caracteres de todos los idiomas del mundo, la norma ISO 8859 prescribe conjuntos de carácteres distintos para distintos grupos de idiomas. La primera mitad coincide siempre con la tabla ASCII, y en la segunda aparecen los caracteres especiales. A las lenguas españolas, así como a la mayor parte de las europeas occidentales, les corresponde el conjunto ISO 8859-1, también conocido como ISO Latin-1.

Los fabricantes acogieron el estándar con distintos grados de adhesión. DEC no tuvo que hacer nada, ya que ISO 8859 es casi idéntico a las tablas usadas en sus terminales VT. IBM implantó una nueva code page (así llaman ellos a los conjuntos de caracteres) para sus PCs, la 850, que corresponde al estándar. Microsoft lo adoptó para Windows (aunque lo llama "ANSI code" en su documentación). Apple, por su parte, guarda silencio sobre el tema, y los Macintosh continuan usando su conjunto de caracteres propio, distinto del estándar.

En realidad, que cada sistema (MS-DOS, Macintosh, etc.) utilice sus propios códigos, sus propios conjuntos de caracteres, no es en principio problemático. Mientras no salgamos de nuestro sistema, no ocurrirá nada. El problema surge cuando se transmiten textos entre sistemas distintos, por ejemplo por correo electrónico. La solución: utilizar ISO 8859-1 como lingua franca, como código intermedio de traducción. La idea es sencilla. Cuando uno escribe un texto en su ordenador o terminal los caracteres se codifican según el conjunto propio de su sistema, sea cual sea. Cuando lo transmite a otro sistema, el software de comunicaciones (el programa de correo electrónico, por ejemplo) lo debe traducir al conjunto ISO 8859-1 utilizando tablas de traducción. Finalmente, cuando el texto llegue a su destinatario, su software deberá traducir los caracteres desde ISO 8859-1 a su conjunto propio, sea cual sea.

Pero, si todo es así de fácil, ¿por qué a veces no funciona? La explicación está en los dos requerimientos técnicos del asunto:

  1. El software de comunicaciones debe respetar los 8 bits de los caracteres que se transmiten.
  2. El software de comunicaciones debe realizar la traducción de los códigos entre su conjunto propio y ISO 8859-1.

El primer requerimiento no siempre se ha cumplido. Como el estándar ASCII original sólo empleaba los 7 primeros bits de cada octeto, se suponía que cualquier valor transportado en el último bit podía ser espúreo, y las primeras versiones del software de comunicaciones usual se encargaban de limpiar este último bit. De hecho, la primera especificación del correo electrónico de Internet (RFC 821) sólo consideraba legal la transferencia de 7 bits. Aunque esto se corrigió después (RFC 1428), algunos sistemas continuan operando como en los días antiguos y cortan el último bit. Cuando esto ocurre, nuestros caracteres acentuados se transforman en otros carácteres de la primera mitad de la tabla; información, por ejemplo, se transforma en informacisn. Es tarea del administrador del sistema informático asegurarse de que el software de comunicaciones sea respetuoso con todos nuestros bits y nuestros acentos.

El segundo requerimiento se atiende cada vez más. En los últimos años, casi todos los programas de comunicaciones para ordenadores personales (compatibles con MS-DOS y Apple Macintosh) se han adaptado para realizar la traducción de códigos. Este es el caso de los programas de correo electrónico (Eudora, por ejemplo) y transferencia de ficheros, y de los clientes del Gopher y el World-Wide Web. El usuario, o el administrador del sistema, deberían también asegurarse de que se usen programas que efectuan la traducción. Si no, los carácteres especiales aparecerán desfigurados; información, escrito en un Macintosh, se leerá informaci?n en la pantalla de un PC con MS-Windows.

En el caso del correo electrónico puede haber una complicación añadida. Las Multi-purpose Internet Mail Extensions (MIME; RFC 1521), una extensión estándar del correo de Internet, definen un método de codificación de caracteres de 8 bits para su transferencia a sistemas que se empeñan aún en ver solamente 7 bits. El problema es que este método sólo funciona cuando tanto el programa de correo del remitente como el del destinatario son compatibles con MIME, y todavía hay muchos programas que no lo son. Si el remitente usa esta codificación especial y el destinatario no la puede decodificar, información se leerá como informaci=F3n. El problema se soluciona desactivando la opción May use QP (Quoted Printable) en el programa de correo.

Referencias


Carles Bellver Torlà <bellverc@si.uji.es>
Universitat Jaume I