Búsqueda

jueves, febrero 22, 2007

La nueva versión de Blogger, incumple aún más los estándares W3C

Pues sí. Lamentablemente, es así. Hoy me he visto obligado a migrar a la nueva versión de Blogger, ya que hasta que no lo hiciera no se me permitía editar ni crear nuevos artículos. Tras una moderada tranquilidad al ver que el blog seguía en su sitio tras el proceso, y una agradable sopresa al comprobar que había migrado todo el contenido a UTF-8, observé con horror que al validar el XHTML, salían más de 40 errores. ¿Por qué? Pues por dos motivos:

El primero es que la barra de navegación de Blogger, de la que alguna vez he hablado, ha cambiado totalmente. Ahora se carga mediante una etiqueta <iframe>. Esta etiqueta permite referenciar otra página HTML distinta, de forma que se incrusta dentro de un espacio determinado en la página original. Aparentemente es una buena idea, ya que así el código de la barra es mucho menos intrusivo, y no interferirá con el de la página original. Aparentemente. Resulta que la etiqueta <iframe> se considera obsoleta y no ha sido incluida en la variante Strict de XHTML 1.0 ni en la de HTML 4. Así que ni dicha etiqueta ni ninguno de sus atributos son válidos, lo que nos da de entrada 9 errores por ello.

¿Y por qué no usar la variante Transitional? pensaréis algunos. ¿Para qué ser tan estricto? Bueno, ya expliqué en su día por qué me parece importante utilizar la variante Strict. Pero aunque decidiera utilizar Transitional, quedarían aún varios errores más.

En el envío anterior, expliqué qué eran las entidades HTML. Recordaréis que básicamente consistían en un código encerrado entre los símbolos «&» y «;». El carácter «&» define el inicio de una entidad HTML, y si lo que sigue no es una entidad válida, se está cometiendo un error. ¿Y si necesitamos poner en nuestro texto dicho caracter, como en «D&D»? Pues para eso existe precisamente una entidad HTML, &amp;, de forma que un navegador muestra el caracter «&» al encontrarla. Por tanto, siempre que queramos especificar un «&» en nuestro texto, tendremos que escribir &amp;. Siempre.

¿Siempre? Sí, siempre. Incluso en los parámetros de los enlaces. ¿Lo cualo? Veréis, al acceder a una página web (aunque deberíamos generalizar y decir recurso web), se le pueden pasar diversos parámetros, que el servidor en cuestión interpretará (la realidad es algo más complicada, pero de momento esta explicación nos vale). Una forma de pasar esos parámetros es en el propio texto correspondiente a la dirección del enlace (atributo href), separados precisamente por el caracter «&». Si pasáis el puntero del ratón por encima del enlace relativo a los comentarios en este blog, veréis a lo que me refiero. Pues bien, esos «&» deberían aparecer en el código de la página como &amp;, y así lo hacían en la versión anterior de Blogger. Sin embargo, en la nueva versión se están poniendo tal cual, lo que nos da varios errores por cada & que aparece. Y hay varios en cada enlace para abrir la ventanita de comentarios. Lo peor de todo es que aquí sí que no hay solución, ya que ese código es generado automáticamente por Blogger, y es inválido en todas las variantes de XHTML y HTML.

Así que vamos hacia atrás, como los cangrejos. Para más risa, el conocido error en los comentarios, consistente en generar la etiqueta <BR/> por cada salto de línea (y que no es válido ni en XHTML ni en HTML), sigue ahí. Así que tenemos ahora dos errores sencillísimos de corregir por parte del equipo de Blogger, pero que parece que les da un poco igual.

jueves, febrero 15, 2007

Nuestra querida Ñ y la informática

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 &Ntilde; (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.

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.

jueves, febrero 08, 2007

Pruebas de ADN para detectar alcohol en sangre

Hace ya más de un mes, recibí un correo electrónico , con un recorte de prensa de La Nueva España (escaneado, claro), publicado el 10 de diciembre (del año pasado), con el titular Las pruebas de ADN confirman que el chófer de Lady Di estaba ebrio en el mortal accidente (gracias David). Obviamente, me pongo a leer toda la noticia, en la que cabe destacar el primer párrafo:

Unas nuevas pruebas de ADN parecen indicar que Henri Paul, el conductor del automóvil en el que viajaba Diana de Gales el día de su muerte en 1997, estaba ebrio la noche del trágico accidente en París, afirmó este sábado la cadena británica BBC. Estas pruebas, hechas en el último año por las autoridades francesas, vienen a confirmar los exámenes originales, de que Paul estaba por encima del límite de alcohol permitido a los conductores en Francia, según el programa «Cómo murió Diana: los archivos de la conspiración», que será emitido hoy por la BBC.

Las pruebas de ADN confirman que el chófer de Lady Di estaba ebrio en el mortal accidente (...)

Podéis pinchar en la imagen para leer toda la noticia. Buscando un poco con el Google, veo que no es el único sitio donde se publica esta información.

¿Pruebas de ADN para averiguar el alcohol en sangre? Veamos, el ADN mantiene nuestra información genética y normalmente no varía con el tiempo o con estímulos externos. Digo normalmente porque no es totalmente inmutable. Una dosis elevada de determinados tipos de radiaciones puede alterar nuestro ADN en algunas zonas, y producirnos un cáncer. Sin embargo, la ingesta de alcohol no afecta al ADN. El pensar que con una prueba de ADN se puede detectar si la persona ha bebido o no, supone creer que el consumo de alcohol sí altera el ADN, y además, que una vez hemos eliminado el alcohol de nuestro cuerpo, nuestro ADN vuelve a su estado original. Algo que desde luego no se aproxima a la realidad.

Leyendo entre líneas, me da la impresión que la verdadera historia es que se hicieron pruebas de ADN a las muestras de sangre que dieron positivo en el control de alcoholemia, y comprobaron que eran de Henri Paul y no de otra persona. Esto puede intuirse en siguiente párrafo:

Los resultados de ADN vienen a demostrar, además, que las pruebas de sangre originales del conductor no fueron cambiadas, como han sugerido algunas teorías de conspiración.

Pero sólo intuirse. El uso de la palabra además, sugiere que no, que las pruebas demostraron dos cosas: que el conductor estaba ebrio, y que las muestras no fueron cambiadas. Sin embargo eso no es posible. Lo lógico sería que las pruebas de ADN simplemente demostraran que las pruebas originales no fueron cambiadas, y esto, a su vez demuestra que el conductor estaba ebrio.

Parece más un error de redacción, digno de Malaprensa, pero algo así debería llamar inmediatamente la atención de todo aquel que tenga un mínimo de idea de qué es el ADN. Si lo que se cuenta fuera cierto, hace varios años que yo mismo sería un mutante.