Hace ya varios meses, al leer una noticia en 20 minutos sobre el anuncio acerca del uso de la letra Ñ en los dominios terminados en «.es», me sorprendió comprobar cómo la inmensa mayoría de gente que comentaba dicha noticia, además de tomárselo como una novedad técnica, criticaba que dichos dominios no serían accesibles desde teclados extranjeros que no tuviesen la tecla Ñ, o que serían ignorados por los buscadores. Algo totalmente erróneo, ya que el uso de la Ñ (y vocales acentuadas, y la cedilla, y un largo etcétera), es técnicamente posible en un nombre de dominio desde hace algún tiempo, se puede acceder a ellos desde teclados sin dicha letra, y son tenidos en cuenta por algunos buscadores (como Google).
Bueno, seguro que la mayoría de gente que comentaba la noticia no eran informáticos (algunos, incluso eran simplemente trolls, como suele ocurrir en el 20 minutos). Sin embargo, un tiempo después me sorprendió aún más un artículo del blog Batch4J sobre un tema similar (la discriminación de la Ñ), puesto que se trata de un blog técnico, cuyo autor y lectores son profesionales del mundo de la informática. Y si bien la Ñ, las vocales acentuadas y demás grafías características de nuestro idioma estuvieron discriminadas hace mucho tiempo, hace ya algunos años que la situación ha cambiado.
Veamos, una letra (o dígito, o símbolo) no es más que un número para un ordenador. La «traducción» de esos números a los caracteres que vemos en la pantalla, y viceversa, se conoce como codificación de caracteres. En los inicios de la informática se crearon varias codificaciones de caracteres, de las cuales la más conocida y utilizada durante mucho tiempo, y que incluso ha sobrevivido hasta nuestros días, es la ASCII. En esta codificación, cada carácter es representado mediante 7 bits, lo que nos da un total de 128 (27) símbolos posibles (aunque no todos imprimibles). ¿Por qué 7 y no 8, que sería un byte completo? Pues porque originalmente esta codificación estaba pensada para transmision de datos, y el bit restante se utilizaba como bit de paridad (una forma sencilla de detectar algunos errores). Pero lo importante es que el ASCII es un estándar estadounidense, por lo que codificaron únicamente los símbolos utilizados en la lengua de Shakespeare. Así, tenemos la letra W, y no la Ñ, y tenemos el símbolo «#» (utilizado en ingles como abreviatura de número) y no nuestra «ª».
Posteriormente, cuando dejó de tener sentido el mantener ese bit de paridad, se crearon tablas ASCII extendidas, con 128 caracteres más (256 en total, es decir, 28), de forma que se incluyeron las distintas vocales acentuadas y demás grafías de otros idiomas europeos. Fijaos que he utilizado el plural, y es que durante esa época surgieron más de una variante, con símbolos diferentes, dependiendo de la compañía o comunidad que creara la tabla, por lo que para garantizar una interoperabilidad entre distintas plataformas, era más que conveniente limitarse a los primeros 128 caracteres en determinado ámbitos, es decir, seguir prescindiendo eñes y demás.
Uno de esos ámbitos era la Web. Las páginas web estan escritas en un lenguaje de etiquetas conocido como HTML (y desde hace algún tiempo, también XHTML; hablé de ello en una ocasión). Inicialmente, puesto que una página podría ser accedida desde cualquier parte del mundo, había que limitarse al uso de la codificación ASCII de 7 bits en ellas. Si no, era muy posible que la página en cuestión no se viera correctamente en todos sitios. Para poder representar más símbolos de lo que nos permitía esa codificación, se crearon las llamadas entidades HTML, que efectos prácticos eran una serie de códigos entre los símbolos «&» y «;», que eran interpretados por los navegadores. Así, para poner una Ñ era necesario escribir Ñ (la ñ minúscula era ñ), para una A acentuada (Á) había que poner Á (á para la minúscula), y un largo etcétera, entre los que se incluían grafías de otros idiomas occidentales (como la e con acento circunflejo: ê) y símbolos matemáticos (como el de infinito: ?).
Es obvio que escribir un texto en castellano en estas condiciones, es bastante molesto. Uno debe recurrir a algún tipo de aplicación que genere esos códigos de forma automática, o bien recordarlos y teclearlos si necesitamos escribir el HTML «a pelo». Afortunadamente, hace años que la situación ha cambiado. Veréis, el protocolo HTTP (que es el que se utiliza en la Web para acceder a las páginas) permite entre otras cosas que se le especifique la codificación de caracteres que utiliza la página. Además, en el propio HTML se puede especificar esa misma información en lo que se conoce como «metatag» (etiqueta <meta>), en caso de que no venga en la cabecera HTTP (si se especifica en ambos sitios, la cabecera HTTP tiene preferencia sobre la etiqueta HTML). Esto no sería demasiado útil si utilizamos una codificación que no implementen todos los navegadores, y aquí es donde los estándares vienen al rescate.
La ISO comenzó a definir allá por los 90 unas codificaciones estándar conocidas como ISO 8859, en las que los 128 primeros caracteres coincidían con los del ASCII de 7 bits, y los 128 restantes codificaban distintos símbolos o letras, dependiendo de la tabla (a día de hoy, hay 15). La más utilizada es la ISO 8859-1, llamada también Latin 1, que incluye los caracteres necesarios para escribir en la mayoría de idiomas de Europa occidental, entre los que se encuentra el español. Esta página que leeis utiliza esa codificación, y si veis el código HTML (al seleccionar la opción «Ver código fuente…» o similar de vuestro navegador) comprobaréis que ahí están las eñes, las vocales acentuadas y los signos de apertura de interrogación y exclamación, tal cual, sin utilizar las entidades HTML. Yo puedo teclear directamente el código HTML del artículo, sin la molestia de tener que escribir «á» en vez de «á».
La codificación ISO 8859-1 tiene algunas peculiaridades que no me resisto a comentar. Al ser anterior al euro, no incluye el símbolo €. Si lo necesitamos (y no queremos teclear €) debemos utilizar la codificación ISO 8859-15 (también conocida como Latin 9) que sí lo incluye, junto con algunos caracteres no contemplados en la ISO 8859-1 (y necesarios para los idiomas que se supone que cubre). Aunque al hacerlo, excluye el símbolo «|» (barra vertical), que es muy utilizado en el mundo de la informática. No podríamos hacer un manual de Unix, por ejemplo. Otro detalle interesante es que incluye las llamadas comillas latinas (o francesas, o españolas) « » y no las comillas inglesas (a veces llamadas tipográficas) “ ”. Una curiosidad sobre ellas, es que al imprimir textos en castellano, son precisamente las comillas latinas las que, desde un punto de vista formal, se deberían utilizar, mientras que las inglesas son utilizadas en textos en inglés. Sin embargo, en la Web se utilizan más las inglesas, supongo que por el extendido uso del Word, que sustituye automáticamente las comillas «planas» (”, que suelen estar en la tecla del 2, y por tanto son las más cómodas de utilizar) por aquellas. Lo gracioso es que si utilizamos la codificación ISO 8859-1, necesitamos utilizar entidades HTML para las comillas inglesas, y no para las latinas.
Bueno, sigamos, porque la cosa de las codificaciones de caracteres no acaba aquí. Las codificaciones ISO 8859 están muy bien, pero tienen sus limitaciones, como hemos visto. Hay tablas para muchos idiomas y alfabetos (incluidos el griego y el cirílico), pero no están incluidos otros, como el chino o el japonés. Por ello, surgió el llamado Unicode, que es una codificación que pretende incluir todos los alfabetos y símbolos existentes. De momento, ya tiene varios miles de caracteres, e incluye alfabetos de lenguas muertas, y multitud de símbolos matemáticos o musicales. Conviene hacer notar que Unicode no es realmente una codificación de caracteres, sino un conjunto o repertorio de caracteres. Para su uso real por parte de las aplicaciones, es necesario definir una codificación concreta, es decir, cómo se van a representar en el mundo de los bits. Las codificaciones más conocidas y utilizadas para ello son UTF-8 y UTF-16. En UTF-8, cada caracter se representa con 1, 2, 3 ó 4 bytes, dependiendo del caracter en cuestión. Los caracteres representables con 1 byte coinciden con la codificación ASCII de 7 bits (por aquello de la compatibilidad), pero letras como la Ñ, o las vocales acentuadas, se representan con 2 bytes. En UTF-16, en cambio, los caracteres siempre se representan con 2 bytes.
La mayoría de navegadores modernos soportan UTF-8, y su uso se está extendiendo mucho en la Web, convirtiéndose casi en obligado. Con UTF-8 podemos utilizar cualquier símbolo Unicode, y utilizar tanto nuestro alfabeto latino, como el cirílico, el griego, o el japonés, mezclados en el mismo texto. Un ejemplo es la misma Wikipedia, y podéis ver que en sus artículos se pueden combinar todos los alfabetos. Fijáos por ejemplo en la lista de enlaces a otros idiomas, que están con el alfabeto de cada uno (aunque no conviene olividar que, aunque el navegador entienda UTF-8, necesitaremos tener instaladas las tipografías adecuadas).
Así que utilizando alguna de esas codificaciones, nuestra querida Ñ no tiene nada de particular, y podemos utilizarla sin problemas. Vale, pero ¿qué ocurre con los nombres de dominio? Bueno, para eso tenemos el estándar IDN, del que ya expliqué algo en uno de mis primeros envíos. ¿En qué consiste? Pues básicamente, el IDN nos permite utilizar Unicode en los nombres de dominio, de forma que podemos crear dominios como www.ñandú.cl, o räksmörgås.josefsson.org (ambos reales), y que sean perfectamente accesibles. Bueno, accesibles si el navegador soporta IDN, cosa que el Microsoft Explorer no hace, en sus versiones anteriores a la 7 (mientras que otros llevaban más de un año haciéndolo).
El acceder a una dirección de ese tipo para alguien sin los caracteres necesarios en su teclado, no es problema. Primero, porque pocas veces tecleamos una dirección a mano, sino que accedemos a las páginas a través de enlaces en otras, o en nuestros marcadores. Segundo, porque si tuvieramos que hacerlo, en algunos sistemas operativos disponemos de una pequeña herramienta que nos permite seleccionar cualquier caracter de una tabla Unicode (en Windows, es el «Mapa de caracteres»). Y tercero, porque para mantener la compatibilidad con navegadores sin soporte IDN, existe algo llamado Punycode, que es una representación en ASCII de un texto Unicode, de forma que cualquiera podría teclearlo (eso sí, hay que conocerlo, y es de suponer que una web con esos dominios, publicitará tanto su nombre como su representación en Punycode).
Estos dominios tampoco son problema para los buscadores. Al menos para los más populares. Yo he probado a buscar las palabras «ñandú» y «räksmörgås» en Google y en Yahoo, y los dominios que he mencionado antes, aparecen en los resultados de búsqueda. Y en la primera página, salvo en el caso de buscar ñandú en Yahoo (que aparece en la 5ª).
Ha llevado su tiempo, pero en muchos ámbitos, nuestra Ñ ya es una letra como las demás, en el mundo de la informática. Sólo es cuestión de tiempo que las aplicaciones y sistemas que aún no soporten esos estándares, vayan adoptándolos.
Actualización 22 de febrero de 2007: Al migrar a la nueva versión de Blogger, la codificación de este blog ha pasado de ISO 8859-1 a UTF-8.
![](bp1.blogger.com/_hS7JC7hfz9A/ReYPnTfEwFI/AAAAAAAAABI/Y5uJjbu8JHg/s200/whiresark.JPG")
fundamental para la solución de problemas de una red y también muy útil para el estudio de las redes de datos. También es una herramienta muy usada en seguridad ya que posee muchas herramientas de filtrado de paquetes.![](bp3.blogger.com/_n6u9TikA1qU/ReNhslwoqkI/AAAAAAAAALU/WK5fJzwVerw/s320/pequena-miss-sunshine-poster05.jpg")
![](bp2.blogger.com/_hS7JC7hfz9A/RdnWQ2CYKUI/AAAAAAAAAA8/qM0X2REcXk0/s200/correo_basura.jpg")
![](bp0.blogger.com/_n6u9TikA1qU/Rcn4vNGFhpI/AAAAAAAAAIo/iEjL5zzM9aA/s320/Real%2520Indiana%2520Jones.jpg")