Este post es el último que publicaremos en esta plataforma, y estará online hasta el 30 de enero de 2009, fecha en la que apagaremos la luz, y Vive la ciudad | Madrid dejará de estar accesible.

Lo primero que pensé al ver esa nota fue que se producirá otro caso de enlace roto. Y se que es muy frecuente que haya sitios que cambien las direcciones o incluso que desaparezcan, a veces es inevitable, pero en otras muchas otras ocasiones creo que habría que intentar evitarlos. Creo que es lógico pensar que a medida que los contenidos generados dependan más de cómo puedan ser rentabilizados, más ocurrirá que habrá direcciones que dejan de funcionar y la Interweb se irá transformando en algo más temporal y efímero.

Si ya hace 10 años en un artículo de Nielsen sobre enlaces rotos se indicaba el grave problema que suponía ¿qué podemos esperar hoy en día? Cada vez que veo un elblockbusteractual-themovie.com pienso cuánto tiempo existirá esa dirección ¿merecerá la pena enlazarlo sabiendo que dentro de uno, dos, quizás tres años ese enlace dejará de funcionar?.

Proyectos como The Internet Archive y su Wayback Machine pueden ayudar a que algunos enlaces puedan rescatarse para poder comprender el contexto, pero no siempre es así y no estoy seguro de que sea la solución. Creo que sería mejor intentar mantener alojado el contenido, en la mayoría de casos no serían necesarios muchos recursos si se planea un poco, y hay muchas posibilidades para solucionar los problemas que se producen si se reestructura la web (¡mod_rewrite al rescate!), así que me parece bastante pecaminoso dejar que esas ocurran.

Una parte de la web 2.0 parece que eran las URL amigables, ¿quizás haya que esperar a la web 3.0 para que además sean permanente? ¿o sólo sirven para técnicas SEO y aumentar la rentabilidad? Espero que algún día podamos enlazar una dirección con la tranquilidad de que pasados los años seguirá allí, por ahora me temo que no es así.

Entiendo que no son serias al 100% pero creo que le dan más importancia de la que se debe a algo como una crisis financiera: efectivamente para todos esos que se quedan en paro sin recursos la cosa es una putada, pero lo sería aunque resultara que estuvieramos en el mejor momento de la historia económica. Además, un momento como este nos hará ser más ingeniosos y no creo que sea bueno dejar de disfrutar y pasar un mal año por algo que no nos toca de pleno. Si las cosas se han complicado, pues habrá que hacer más cena con los amigos y jugar a juegos en vez de tanto restaurante y cine. A lo mejor hay que usar menos coche y comprar otras cosas, pero estoy seguro de que todos podemos intentar disfrutar de todo esto.

Y a los que realmente estén pasandolo mal ¡mucho ánimo! Y que tengan un feliz 2009.

Podemos remontarnos a ASCII-7, una tabla de caracteres de 7 bits que representaba los carácteres más usuales del mundo anglosajón. Sin embargo ¿qué pasaba con los carácteres extranjeros? Para solucionarlo se creó ASCII extendido, esta vez con 8 bits y 256 carácteres disponibles, pero aún así no era suficiente para contentar a todo el mundo, porque entre tildes, letras raras, signos y demás no podiamos meter todos los caracteres no-ingleses que necesitabamos en 128 carácteres que eran lo que nos dejaba ASCII extendido. Así que la solución fué crear distintos ASCII
extendidos, las famosas iso-8859. Cada tabla de carácteres iso-8859 especificaba distintos carácteres, así cada país podía utilizar el juego de carácteres que mejor se adaptara a su grafía. En el caso español usábamos iso-8859-1 que incluía la mayoría de carácteres europeos occidentales.

Problema resuelto ¿no? Pues puede que sí, al menos parcialmente. A menos que necesites escribir un texto con ñ (iso-8859-1) y un carácter arábico (iso-8859-6) pero tampoco es para tanto, vamos digo yo. Aunque ahora que lo pienso, si alguien me envía un texto con carácteres extendidos ¿cómo se que tabla está usando? Vaya, no puedo descubrirlo… pero tampoco es tan grave, ya lo resolverán las aplicaciones: los servidores web envían la codificación del fichero, y lo mismo ocurre en casi todas las demás cosas. Aunque todavía me queda saber cómo hace el servidor web para saber qué tipo de codificación utiliza un fichero HTML o .txt determinado. ¿Quizás no puede adivinarlo? Vaya, entonces tenemos un problema. Empiezo a pensar que esto de ASCII no es tan buena idea… 128 carácteres fijos y 128 que pueden cambiar y no se cuándo se usa cual no me parece divertido.

Ya hemos descubierto el problema, ahora la solución

Nos ha quedado claro que el problema que nos encontramos es que no podemos limitarnos a tener 128 carácteres fijos y luego que cada documento tenga un juego de 128 carácteres extendidos, porque no soluciona el problema del intercambio de documentos ni permite usar los carácteres que necesitemos en cada momento, nos vemos limitados a un juego.

Así que como solución surge Unicode. Un juego de carácteres universal capaz de identificar 2^32 carácteres (4.294.967.296), y en tantos carácteres pueden codificarse todas las grafias del mundo (incluso se intentó codificar la grafía Klingon :) ), presentes y pasadas. Así que genial, ahora tenemos un sistema de codificación que nos permite utilizar cualquier carácter y nuestros documentos podrán ser leidos por cualquiera. Si es que ya les pasó cuando hicieron ASCII extendido para ampliar ASCII-7, que se conformaron con duplicar las opciones y tendrían que haber ido a lo grande, pero nunca es tarde si la dicha es buena.

Los peros

Así que tenemos claro que usaremos Unicode para representar cadenas de texto, con sus 32 bits nos permiten codificar cualquier texto imaginable aunque esto tiene 2 graves consecuencias. El primero y más obvio es el tamaño de las cadenas. Este texto tiene unos 6.700 carácteres, lo que codificado como ISO-8859-15 son 6.700 bytes, sin embargo en Unicode eso serían casi 27.000 bytes, y aunque el ancho de banda y el espacio en memoria cada vez es menos problemático para almacenar texto, sigue siendo multiplicar por cuatro.

El otro inconveniente viene de utilizar un sistema de codificación nuevo y totalmente distinto. Hay que reescribir todas las funciones que estén relacionadas con las cadenas: medir el tamaño de una cadena, representarla, leerla, partirlas, unirlas, ordenaralas…. nada de lo que teniamos sirve y todo hay que reescribirlo.

Y a todo esto podemos tener una idea de lo engorroso que es mantener al mismo tiempo texto en Unicode y otros formatos, aunque tampoco es demasiado distinto a tener que trabajar con distintas codificaciones.

Así que como solución a parte de los problemas se crearon UTF-16 y UTF-8. El primero es una representación en palabras de 16 bits de los carácteres, de forma que la mayoría de carácteres puedan ser representados en 16 bits. Pero sigue teniendo la pega de que nos es necesario tener código capaz de trabajar, representar y leer esas cadenas. El otro invento fue UTF-8, que codifica los carácteres más utilizados en 8 bits y ahorra mucho espacio, y la realidad nos demuestra que vino para quedarse.

Y el enemigo número 1: UTF-8

UTF-8 no es tan malo: nos permite utilizar Unicode y ahorramos espacio ¿no? Sí, eso es verdad. Pero eso son efectos colaterales del verdadero objetivo del uso de UTF-8 que podemos descubrir recurriendo a un poco de historia.

Se supone que el primer email de la historia fue un texto de prueba, algo como QUERTYIOP y que tras
esa prueba se enviaron otros mensajes. Ese primer mail se envió en 1971 y podriamos apostar a que estaba escrito en ASCII (que se presentó en 1967). Así que imaginad que cogemos todos esos mails que se enviaron hace más de 30 años en ASCII y que causaron tantos problemas de intercomunicación entre distintos idiomas, que dieron tantos quebraderos de cabeza (todo el que haya tenido que configurar consolas sabe de que estoy hablando) y de repente por arte de magia ¡son textos internacionales¡ ¡bendigamos a UTF-8!

Unicode pretende ser la respuesta a un problema complejo que se vió acentuado por el intercambio de información en a las redes informáticas. Solucionar el problema es engorroso: durante un periodo se producirán incompatibilidades entre programas y usuarios de Unicode y aplicaciones y usuarios que siguieran con juegos de caráceteres variados e incompatibles.

Si Unicode y todos los iso-8859 conviviesen existirían problemas en los que los textos serían totalmente incompatibles: una herramienta que no soporte Unicode mostrará un montón de basura ilegible y no podrá hacer nada con él, y lo mismo ocurriría en el caso contrario. Sin embargo UTF-8 surge como un intento de camuflar ese problema, de repente la solución es “compatible hacia atrás” y todos los textos escritos en ASCII-7 son también Unicode (UTF-8, pero Unicode a fin de cuentas). Y las rutinas de clasificación, de partir cadenas, los filtros, todo funciona perfectamente. Siempre y cuando sea ASCII-7, suficiente para los anglosajones.

En resumen, con UTF-8 se consigue adaptar una solución y degradarla para que no resulte demasiado molesta. Para que sólo “los que tienen el problema” tengan que lidiar con ella, con una solución intermedia, para no tener que saltar todos al tren del Unicode.

Por eso odio UTF-8. Porque es el mal menor y lo han hecho a posta.

PS: Un excelente artículo sobre esta historia es “Characters vs. Bytes“.