viernes, 12 de octubre de 2007

La pesadilla de los “encoding” (2ª parte)

Decíamos en la anterior entrada que cuando un fichero puede codificarse con UTF-8. Existen dos variantes del formato UTF-8: con BOM y sin BOM. BOM son dos bytes (FE FF) al principio de un fichero que, simplificando mucho, indican el orden de los bytes.
Guárdese un fichero codificado en UTF-8 con el BOM y tendrá problemas con la mayoría de sus scripts en PHP o ficheros XML, ya que el fichero realmente no comenzará como "<?php" o "<?xml".

Imaginen ahora el siguiente entorno de trabajo: un servidor web más o menos moderno que sirve los documentos por defecto con la codificación UTF-8, un desarrollador con una estación de trabajo Windows o Linux y un diseñador con la estación de trabajo Mac. Si el desarrollador y el diseñador no vigilan el "encoding" con el que guardan sus ficheros habrá problemas con seguridad. Muchas herramientas de desarrollo y/o diseño Web guardan por defecto los ficheros codificados con ISO-8859-1, otras lo guardan en UTF-8 con BOM.

Por supuesto, existen soluciones, a nivel servidor (ficheros .htaccess con la directiva AddDefaultCharset) y a nivel estación de trabajo utilizando herramientas competentes que puedan lidiar con las diferentes codificaciones.

Esta es la típica página que se ve mal porque el servidor sirve en ISO-8859-1 y el fichero está codificado como UTF-8:
Captura de un navegador mostrando caracteres UTF-8 como Latin-1

Se puede ver cómo los caracteres acentuados (ocupan 2 bytes en Unicode) son interpretados como 2 caracteres sencillos.

En el blog de Juque hay más ejemplos y se amplía más la información.

La conclusión final que obtengo es la siguiente: si no se puede garantizar una uniformidad en las plataformas de trabajo (que todo el mundo trabaje con el mismo "encoding"), lo más seguro es utilizar las entidades HTML de toda la vida (á en vez de á, ñ en vez de ñ, ...)

1 comentario: