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 &ntilde, 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 «&aacute;» 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 &euro 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.

http://malaciencia.blogspot.com/2007...nformtica.html



--
El día que Pablo Lleó Gárcia deje de hacer el imbécil en los foros técnicos
de MS y de falsificar a la gente, yo dejaré de cantaros las 40 aquí. Hasta
el momento soy comedido: solo pongo los mismos mensajes, copiados, que Pablo
ha puesto allí y segun los va poniendo. Por tanto, ya sabeis quien es el
culpable. Y por cierto, los pongo por ahora aquí sin hacer el crossposting
que él hace en MS. Y digo "por ahora".