Error en la codificación con AJAX

Pelearse con la codificación de los caracteres en una aplicación web es pan nuestro de cada día. En un desarrollo sencillo uno puede olvidarse de ese detalle y dejar el trabajo de cloacas al navegador y el PHP. Pero en el momento en que entran en juego javascript y fuentes externas de datos, es entonces cuando la posibilidades de cagarla se multiplican.

Una de las formas más sencillas de prevenir problemas con la codificación es utilizar siempre UTF-8 para el desarrollo completo de la aplicación. Ésto incluye la base de datos, una línea al principio de todo script:

header('Content-type: text/html; charset=utf-8');

También en los HTML:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

Y por supuesto, que el fichero esté físicamente codificado en UTF-8, cosa que cada uno deberá hacer con el editor de código correspondiente (mi experiencia con Ultraedit en este sentido es inmejorable).

El horror comienza cuando no has hecho los deberes, y a una aplicación sencilla se le quiere empezar a meter AJAX y datos de diversas fuentes. Por defecto tu tinglado estará utilizando seguramente ISO 8859-1, la codificación del alfabeto latino, y éso es lo que va a estar esperando el navegador a no ser que le indiques lo contrario…

Estos problemas de codificación se pueden deber a múltiples razones, sería imposible cubrirlas todas en un post, así que me centraré en las dos con las que he tenido que lidiar estos días:

• API EXTERNA. Aquí no queda otra, Si la API no ofrece un parámetro para especificar la codificación, va a venir en UTF-8 prácticamente seguro y tocará hacer en el código, por ejemplo en PHP, un utf8_decode de lo que devuelva.
• AJAX. La diversión con la codificación de caracteres cuando entra en juego el javascript puede no llegar a tener límite. Si, para más inri, utilizamos AJAX para comunicar con un script pongamos de PHP, entonces tenemos todos los ingredientes para la empanada de caracteres raros.

  Obviando detalles de bajo nivel como que el objeto XMLHttpRequest que se encarga de esta comunicación utiliza siempre UTF-8, o que dependiendo de si utilizas GET o POST e Internet Explorer o Firefox se usará una codificación u otra, vemos que las combinaciones pueden marear hasta la náusea, así que hay que buscar una solución que funcione independientemente de la codificación origen-destino, el navegador o el protocolo utilizado.

  Tras varios intentos, dí con una combinación que parece comerse cualquier barbaridad que se pueda poner en un formulario (una caja de texto que acepte código de programación, textos chinos o búlgaros… es un reto). El flujo sería el siguiente:

  1. Desde el javascript mandamos los datos codificados con la función encodeURIComponent (utilizar otra nos dará problemas con los caracteres & y +), por ejemplo:

     ajax.open('get','url_script.php?datos='+encodeURIComponent(datos),true);

  2. Dependiendo del lenguaje de programación que se utilice en el script que recibe los datos habrá que hacer una decodificación o no de los mismos. PHP automáticamente lo realiza para lo que recibe por GET, como en este ejemplo.
  3. Para devolver la respuesta, con PHP utilizamos rawurlencode para codificarla (esta función lo realiza de forma más estricta que urlencode). Por ejemplo:

     echo rawurlencode($respuesta);

  4. Finalmente, de vuelta a javascript, decodificamos la respuesta con decodeURIComponent, y ya tenemos una bonita cadena de caracteres lista para utilizar sin problemas de codificación. Por ejemplo:

     var respuesta = ajax.responseText;
     div.innerHTML = decodeURIComponent(respuesta);

En definitiva, hay que utilizar UTF-8, hay que dejarle al navegador muy claro que lo estamos haciendo, y tenemos que usar una serie de métodos para que en el trasiego de la información entre distintos lenguajes y scripts no se pierda la codificación.

Advernet Somos Todos

Una pequeña muestra de contenido propio grabado en nuestras oficinas :D

Semana 2 / El Cerebro de la Bestia

Y como el último enlace a mi me trajo muy buenos recuerdos de aquellos tiempos de las primeras consolas, me puse a regodearme en la nostalgia y encontré esta joyita, yo todavía tengo el VHS y la Hobby Consolas original en casa :_)

“y porque su memoria es ¡ojo! de 256k…”

Chunda² / Doggie Style

Plantilla personalizada para las Páginas de WordPress

Los que hayan utilizado WordPress para crear un blog saben que en él se pueden escribir Posts (Entradas) y Páginas. Los Posts son el núcleo del blog, y van a tener el diseño del tema que estés utilizando. Las Páginas por su parte son entidades estáticas, o más bien atemporales, que puedes añadir a la estructura de tu blog.

El tema es que si ves un Post y una Página de un blog no se puede diferenciar a simple vista qué es cada cosa. Mi problema era que quería tener Páginas que cuando estuvieran publicadas no mostraran elementos propios de los Posts, como la fecha de publicación, comentarios, tags, categoría… así como la posibilidad de tunear si fuera necesario un poco la estructura que me impone el tema que utilizo.

Indagando un poco descubrí una funcionalidad que ofrece WordPress para las Páginas, los Page Templates. Al final es todo tan sencillo como añadir la siguientes líneas al principio de un fichero php que debes tener en la carpeta del tema que utilices:

<?php
  /*
  Template Name: pagina limpia
  */
?>

Lo que yo hice fue coger el fichero page.php, que es el que se utiliza por defecto para las Páginas, renombrarlo a page-limpia.php, añadirle al principio las líneas arriba mencionadas, y quitar lo que me sobraba (comentarios, fechas…). Al ir a crear una nueva página, WordPress detectará esta nueva plantilla y aparecerá una nueva opción avanzada en el editor: