"Incompatibilidad de caracteres" o "cómo escribo las comillas bajas con ALT+n"

A raíz de una consulta de @Ronronia en Twitter, sobre cómo escribir la comillas que se usan en Alemania („ “) mediante la tecla ALT más un código (como siempre se ha podido hacer en MS-DOS), pensé en escribir este artículo para aclarar ciertas cuestiones relativas a la visualización de texto en un ordenador. No voy a centrarme en los teclados, ya que eso requeriría todo un artículo aparte sobre la introducción de datos mediante teclados no occidentales, y carezco de experiencia en el tema. Simplemente supondré que el usuario dispone del teclado adecuado, o bien que lee un fichero ya existente.

Lo que cuento está basado en mi propia actividad laboral y particular, así que si cometo algún error o doy información incompleta, cualquier comentario será bienvenido.

Introducción

Desde que los ordenadores disponen de métodos más amigables que las tarjetas perforadas para introducir la información, el usuario se ha encontrado ante el desafío de escribir texto para que la máquina lo interprete, y luego visualizarlo, ya sea en una pantalla o imprimiéndolo en un papel. Cada pulsación del teclado debe transformarse, de alguna manera, en una letra (más exactamente, en un caracter, o sea, un signo) que también debe poder guardarse en la máquina, para poder recuperar más tarde signo que se tecleó. Ahora bien, los ordenadores no guardan trazos, sino bits agrupados en códigos, de manera que es necesario establecer una correspondencia entre el código que guarda el ordenador y el carácter a dibujar. ¿Cómo realizar esta correspondencia?

Escribiendo en inglés: Tabla ASCII

El método más clásico lo establecieron, cómo no, los norteamericanos, mediante su organización de estándares, ANSI. Ésta propuso una tabla de códigos llamada ASCII (American Standard Code for Information Interchange).

La tabla contiene 128 códigos (del 0 al 127), para cada uno de los cuales se establece un significado. En realidad, sólo los que van del 32 al 126 son imprimibles, es decir, caracteres propiamente dichos. El resto corresponde a códigos de control.

Para poder identificar de manera fácil cada código con su caracter, la empresa Microsoft hizo que desde su sistema operativo MS-DOS el usuario pudiera escribir cualquier caracter de la tabla, simplemente manteniendo pulsada la tecla ALT y escribiendo el código. Al liberar la tecla ALT, se imprimía el caracter correspondiente al código introducido.

Del inglés a las lenguas occidentales: ASCII extendido

Cualquier persona no anglosajona que mire la tabla ASCII, notará en seguida algunas deficiencias. Por ejemplo, no existen las letras con acento o diéresis. Esto es así porque los norteamericanos definieron, lógicamente, los caracteres que les hacían falta, y no los que se usan en francés, español, griego o chino.

Para subsanar esta deficiencia, diversas empresas de informática (en particular IBM, que era la que comenzó a fabricar los primeros PC's) decidieron extender la tabla al doble, del 0 al 255, de manera que cada byte de información hiciera referencia exactamente a un caracter. Aquí podéis ver cómo quedó la tabla ASCII extendida.

Ahora bien, 128 posiciones adicionales no son muchas. Nos pueden permitir algunos caracteres más, como los acentos; pero ¿qué ocurre si queremos escribir letras griegas? ¿O cirílicas? ¿O caracteres chinos? Resultó que no había espacio para todos, y las máquinas de entonces no podían tratar fácilmente codificaciones muy extensas; convenía que sólo hubiera un byte para cada letra. Para solucionarlo, se decidió crear varias extensiones de la tabla ASCII, no una sola. Cada extensión estaba orientada a las necesidades de una determinada cultura. Por ejemplo, la extensión 737 de IBM contenía las letras griegas. Las más usadas, sin embargo, fueron las que de alguna manera recogían los caracteres que se consideraban más útiles en las lenguas occidentales (español, francés, alemán...), como la extensión 437, y una extensión especial creada por Microsoft llamada Windows-1252 (o CP-1521, ya que normalmente las tablas se designan como CP-xxx, de code page). También ciertas organizaciones de estándares internacionales, como ISO, establecieron ciertas reglas. Así surgió la tabla ISO-8859-1, que es casi calcada a la Windows-1252, la cual a su vez tiene bastantes caracteres en común con la extensión 437. Estas han sido las tablas estándares en los ordenadores occidentales hasta hace poco, y de hecho aún se usan mucho.

Entonces, ¿ya puedo escribir las comillas bajas con ALT+código?

No. Resulta que las comillas alemanas no se consideraron en su momento caracteres útiles, por lo que ninguna de las extensiones ASCII ni tampoco otras tablas comunes la contienen (quizás haya alguna, pero desde luego no es de las habituales). Es más, aunque alguna extensión la contenga, ni siquiera puede uno estar seguro de que pueda escribir una letra con acento o una letra griega: dependerá de la tabla de caracteres que use la aplicación en concreto (en este caso el intérprete de comandos de Windows, heredero del antiguo intérprete de MS-DOS). Si el intérprete usa la extensión 737, sí que podrás escribir una letra griega, por ejemplo una xi minúscula (ξ) mediante ALT+código; pero si usa el Windows-1521 (como probablemente ocurra si estás en España) no podrás.

Os estaréis preguntando cómo se cambia de tabla de caracteres. Pues bien, en Windows se usa el comando chcp (change code page). Por ejemplo, chcp 737 cambiaría a la tabla CP-737, en la que tendríamos las letras griegas.

Entonces, ¿sólo tengo que cambiar la tabla y ya podré obtener el símbolo que quiera?

Tampoco XD Es muy triste, pero los obstáculos a superar para conseguir tu símbolo son numerosos. Resulta que aún hay un elemento más que no he explicado: la fuente. Y es que no basta con asociar un código a un carácter, sino que luego ese carácter debe dibujarse, y existen diferentes maneras de hacerlo, como todos sabemos (no es lo mismo una letra dibujada en Arial que en Courier o en Times New Roman).

Por defecto, el intérprete de comandos de Windows usa la fuente Lucida Console. Si esa fuente no tiene definidos todos los dibujos para los posibles caracteres de las tablas, de nada servirá cambiar de una a otra si justamente falta el que queremos. Es más, aunque la fuente tuviera definido el caracter en alguna posición, haría falta que fuera justamente la posición que especifica la tabla con la que trabajas en ese momento. Pero volveremos a eso cuando hable de Unicode.

Si os interesa saber qué caracteres soporta una fuente y qué aspecto tienen, os recomiendo una utilidad llamada BabelMap, que resulta muy útil.

¿Podemos cambiar la fuente del intérprete de comandos? Sí, aunque no resulta fácil, y además, si se hace, hay que tener cuidado con seleccionar siempre una fuente equiespaciada. Aquí explican el porqué.

De las lenguas occidentales a todas: Unicode

La globalización de la sociedad en la que vivimos y el auge de Internet, han hecho que el mundo esté cada vez más intercomunicado a través de ordenadores. El clásico aislamiento que uno esperaba tener cuando trabajaba con sus aplicaciones ya no es cierto. Cada vez es más común que un mismo documento contenga caracteres de diferentes culturas, o que un programa deba aceptar que lo utilicen usuarios de países muy distintos. En los 80 daba igual que un documento no pudiera contener texto en chino. Ahora sería inadmisible.

Notepad nos muestra texto unicode sin problemas

Para poder ampliar la lista de caracteres posibles, se decidió crear una ampliación de ASCII llamada Unicode, donde el código pasara de uno a dos bytes, es decir, que en lugar de 256 combinaciones, ahora tenemos 65536. En realidad, algunos caracteres se sitúan más allá de los dos bytes (se puede llegar hasta la posición 0x10FFFF), pero se trata de casos un tanto especiales; prácticamente todo se puede resolver en el rango de los dos bytes. Eso da para mucho; por eso Unicode no sólo contiene letras y números de todo tipo, sino cualquier signo de puntuación imaginable. Podéis consultar la tabla en diferentes sitios de Internet, como este.

El intérprete de comandos, en cambio, no

Aunque al principio costó que las aplicaciones informáticas adoptasen la nueva codificación y abandonasen las viejas extensiones de ASCII, ya empieza a ser habitual trabajar con él. Cualquier usuario de Windows, por ejemplo, puede arrancar típicas aplicaciones como el bloc de notas o el Word, y escribir caracteres de todo tipo, sin preocuparse de nada, puesto que la aplicación ya se encargará de guardarlo en una codificación adecuada para Unicode (generalmente, UTF-8). Incluso los intérpretes de comandos pueden llegar a mostrar el contenido de ficheros que usan Unicode.

Vale, pero no consigo obtener el caracter que quiero con ALT+código. ¿Qué está ocurriendo?

La utilidad del intérprete de comandos para dibujar un caracter mediante ALT+código fue una facilidad que tuvo su sentido en su momento, cuando ASCII o CP-1521, pero que hoy en día, con la complicación de tener que cambiar de tabla, resulta más un rollo que otra cosa.  Sin embargo, a alguna gente le puede funcionar, y realmente es posible sacar las comillas alemanas si se tiene la configuración adecuada, según algunos testimonios. Todo esto gracias a ciertos juegos entre las tablas, según se haga comenzar el número por 0 o no. Aquí tenéis una explicación del tema.

Aún así, parecería razonable que Microsoft se haya interesado en permitir escribir un código Unicode tras el ALT, en lugar de seguir obligándonos a preocuparnos de las tablas. Y así es: si mientras se mantiene ALT pulsado se teclea el signo + seguido del código hexadecimal del carácter, en principio debería aparecer el símbolo correspondiente de Unicode.

Por cierto, que lo mismo es posible hacer en la consola de Linux pulsando a la vez Shift+Ctrl, la letra u y, a continuación, el código hexadecimal del caracter.

¿UTF-8 es Unicode?

No. UTF-8 es una de las posibles codificaciones de Unicode. Y es que si miramos los caracteres de los primeros códidos de Unicode (por debajo de 128) veremos que son... justamente los de ASCII. No es casualidad: ya desde el principio se pensó en que los códigos de un solo byte fuesen compatibles y, en todo caso, si alguien quería escribir otro caracter, que usase dos bytes, o tres (o incluso cuatro para algunos caracteres algo especiales). Por contra, UTF-16 usa dos bytes de entrada. Tanto UTF-8 como UTF-16 tienen sus ventajas e inconvenientes, que no voy a discutir aquí. Basta con saber que UTF-8 es la más extendida en Occidente, y por eso a menudo se usan como si fueran sinónimos, de manera que si una aplicación nos pregunta si deseamos guardar el texto en UTF-8, en el fondo nos está preguntando si usamos Unicode. 

El BOM

Si intentáis crear un fichero en UTF-8 con el bloc de notas de Windows y abrirlo luego en Linux, es posible que veáis que el texto está bien, pero que hay algo extraño al comienzo del texto, unos pequeños símbolos. Por el contrario, a veces un fichero de texto UTF-8 creado en Linux o mediante una aplicación java y luego enviado a ciertas aplicaciones de Microsoft o implementadas con algún lenguaje de esta empresa, producen problemas, como si Windows no fuese capaz de usar Unicode. ¿Qué está ocurriendo? Todo esto es culpa del BOM.

BOM significa Byte Order Mark, y son tres byte que se pueden incluir antes de un texto UTF. En realidad, sólo tiene utilidad para la codificación UTF-16, ya que ésta, al usar dos bytes, plantea la duda de si el que viene primero es el de más peso o el de menos peso (es un clásico problema de la informática: los little-endian y los big-endian). En UTF-8 no existe ese dilema, y el estándar unicode desaconseja su uso. Por eso muchas aplicaciones y librerías de programación no lo incluyen. Sin embargo, Microsoft decidió ponerlo siempre en cualquier texto unicode, tanto si era UTF-8 como si era UTF-16, y usarlo de paso para que la aplicación que lee el texto sepa si éste es unicode o alguna tabla habitual de Windows, como CP-1521.

Conclusión

Si quieres escribir las comillas alemanas y no tienes un teclado que contenga esos caracteres, búscalos por Internet y pégalos en tu texto ;)

Algunas imágenes están sacadas de: 

http://josejuandom.wordpress.com/2012/07/03/c-lenguaje-de-programacion-3a-parte/

http://informaticaencaude.wordpress.com/2011/10/16/codigo-ascii-extendido-2/