ISO 8859

ISO 8859. Sopa de caracteres
Página 1 de 3
ISO 8859
Sopa de caracteres
Copyright 1995 by Carles Bellver Torlà <[email protected]>
Universitat Jaume I
BELLVER, C. (1995). ISO 8859. Sopa de caracteres. Information World en Español. Num. 32 abril
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,
http://tecnologiaedu.us.es/revistaslibros/a4.htm
09/06/02
ISO 8859. Sopa de caracteres
Página 2 de 3
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 MSWindows.
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
http://tecnologiaedu.us.es/revistaslibros/a4.htm
09/06/02
ISO 8859. Sopa de caracteres
l
l
Página 3 de 3
Michael Gschwind (1994). ISO 8859-1 National Character Set FAQ .
André Pirard (1992). Guidelines to use 8-bit character codes
http://tecnologiaedu.us.es/revistaslibros/a4.htm
09/06/02