El temita de la internacionalización (i18n para los amigos) en una aplicación web puede dar para largo y tendido, yo voy a hablar aquí concretamente de la forma de guardar y utilizar las cadenas de texto del site en varios idiomas utilizando el framework de templates Smarty.

Hay muchas formas de hacerlo, se pueden encontrar varias alternativas en este post de best way to build a multi-language site with smarty, que empezó en el ¡2003! (el frenético ritmo que lleva la tecnología hace que no me crea nada que no sea de ayer…). Todas tienen sus ventajas e inconvenientes, y dado que no hay nada en el core de Smarty para ésto ni una solución popularmente aceptada como la estándar, cada uno debe analizar lo que necesita para su proyecto y tener unas preferencias subjetivas, que en mi caso son:

• Que no implique PHP: obviamente hay opciones mucho más sofisticadas, eficientes, etc… para solucionar el tema del i18n con programación (por ejemplo smarty-gettext), pero precisamente el uso de Smarty es para separar la lógica de la aplicación de la de presentación, y dado que considero que ésto es problema de front-end puro, yo quiero resolverlo únicamente con Smarty.
• Que sea sencillo y eficiente: con el tiempo me estoy conviertiendo en un talibán del código, en el sentido bueno (creo) de intentar que las cosas se hagan de la forma más clara posible (KISS power!) y que note un pinchazo en el corazón con cada ciclo de reloj que se consume en código prescindible.

Por ejemplo, hay una solución muy buena y que he utilizado en otros proyectos, SmartyML, pero es una clase más en PHP (una capa más para procesar) y viendo tanto código pienso que debe haber una forma mejor de hacerlo.

Pero vamos al turrón. Al final encontré en el foro antes mencionado la solución que me parece más sencilla y adecuada para lo que necesito. Se trata de utilizar archivos de configuración (1ª ventaja: es una funcionalidad core de Smarty, con lo que no hay que añadir más complejidad). En estos ficheros se definen variables globales para los templates y se pueden aplicar de varias formas:

// desde el PHP
$smarty->config_load('fichero.conf');
 
// desde el template
{config_load file='fichero.conf'}

Yo prefiero hacerlo desde PHP porque la gestión del idioma de la web es lógica de aplicación y hay que poner cada cosa en su sitio. El directorio donde se almacenan estos ficheros debe ser definido en el código:

$smarty = new Smarty();
$smarty->config_dir   = '/path/al/directorio/';

Crearemos un archivo por idioma, en los que tendremos todas las cadenas de texto que vamos a utilizar traducidas, por ejemplo:

# /path/al/directorio/es.conf (español)
saludo = hola!
enviar = Enviar
cancelar = Cancelar

# /path/al/directorio/en.conf (inglés)
saludo = hi!
enviar = Send
cancelar = Cancel

Utilizar estas variables en los templates es tan sencillo como usar la sintaxis {#variable#}, por ejemplo:

<strong>{#saludo#}</strong>
<input type="button" name="enviar" value="{#enviar#}" />
<input type="button" name="cancelar" value="{#cancelar#}" />

¡Y ya está! desde el PHP se puede controlar qué archivo de configuración de idioma cargar y de esta manera tener montada nuestra web multilenguaje. Unos últimos apuntes:

• Las cadenas también pueden llevar texto variable, como por ejemplo un saludo del tipo Hola Fernando, bienvenido! Ésto se puede solucionar de dos formas:

  # forma CUTRE: en el tpl
  <strong>{#saludo1#}{$nombre_usuario}{#saludo2#}</strong>
   
  # en el archivo de configuración de idioma
  saludo1 = Hola
  saludo2 = bienvenido!

  # forma CORRECTA: en el tpl
  <strong>{eval var=#saludo#}</strong>
   
  # en el archivo de configuración de idioma
  saludo = Hola {$nombre_usuario}, bienvenido!

• En lo que entiendo es una optimizacion (supongo que a nivel interno se controlará), se pueden utilizar secciones (referenciadas así [seccion]) en el archivo de configuración, de manera que si se especifica una en el config_load sólo esas variables se cargarán (la que estén fuera de una sección estarán siempre disponibles). Ésto nos puede servir para organizar las cadenas de texto por página y suponer que Smarty lo manejará mejor que el chorro completo de variables. Quedaría así:

  # cadenas globales
  saludo = Hola!
  enviar = Enviar
   
  # página de login
  [login]
  titulo = Introduce tu usuario y contraseña

  Y desde el PHP:

  $smarty->config_load('es.conf','login');
  $smarty->display('login.tpl');

• Una desventaja es que no maneja de manera nativa los plurales como otras soluciones, de forma que hay que controlarlo a manubrio, por ejemplo:

  # en el tpl
  {eval var=#subida_fotos#}{if $num_fotos > 1}s{/if}
   
  # en el archivo de configuración de idioma
  subida_fotos = Has subido {$num_fotos} foto

Compártelo

La filosofía del single sign-on ha terminado imponiéndose por pura lógica de saturamiento 2.0, con los grandes jugadores vendiendo sus nuevas propuestas (OpenID lo intentó y no lo consiguió…) y los usuarios cansados de procesos de registro y contraseñas varias. Darles a éstos la oportunidad de usar sus credenciales de alguno de los servicios top para utilizar tu sitio debería ser ya a estas alturas planteado como una funcionalidad primaria de cualquier proyecto web.

Lo que viene a continuación es una guía para implementar en tu web la funcionalidad de “login externo” usando las APIs de tres de los grandes: Facebook, Yahoo y Windows Live (Google y OpenID vendrán en otro post). El proceso es similar en todos los casos, y el objetivo es acabar teniendo para utilizar en nuestro código el id único externo (la variable $id_unico en los ejemplos) que nos sirva para identificar y validar al usuario en nuestro sistema local.

Facebook

La integración más sencilla de todas ¡5 líneas de código!

La documentación para desarrolladores de Facebook es de las mejores, con muchos ejemplos prácticos y una comunidad muy activa. Vamos a hacer la implementación más sencilla, sin meternos en Facebook Connect, que será chicha para otro post. Los pasos serían los siguientes:

1. Logueado en tu cuenta de Facebook debes añadirte la aplicación para desarrolladores.
2. Creamos una nueva aplicación, y rellenamos lo básico para que funcione (el resto es para configuraciones más avanzadas)

   

3. Nos bajamos la librería cliente de PHP.
4. ¡Y a picar!

Resumiendo, tenemos una api key, otra key privada, hemos especificado una URL propia de retorno de Facebook, y tenemos su clase de PHP (nos sobraría con los ficheros facebook.php y facebookapi_php5_restlib.php). Pues el script para loguearse con Facebook sería tan sencillo como esto:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

<?php
 
	// cargamos la clase que nos proporcionan
	require_once('apis_externas/facebook/class_facebook.php');
 
	// datos de la aplicación que se nos facilitan cuando la registramos en Facebook 
	$appapikey = '000000000000';
	$appsecret = '111111111111';
 
	// inicializamos el objeto de la clase
	$facebook = new Facebook($appapikey,$appsecret);
 
	// si el usuario no está logueado en Facebook le redirigirá allí
	$id_unico = $facebook->require_login();
 
	if(empty($id_unico))
	{
		// si a estas alturas no tenemos el id único algo ha salido mal
		$error_api = true;
	}
 
?>

Hay varias formas de hacer esto en Facebook, y no digo que esta sea la más correcta, pero seguro que la más sencilla. La importante es la línea 14, en la que si el usuario está logueado nos devolverá su id único, y sino le enviará a la página de login de Facebook.

Yahoo

Otra API con integración no traumática gracias a la tecnología BBAuth de Yahoo. Aquí también se pueden elegir varias implementaciones (OAuth, OpenID), pero de nuevo vamos a optar por la más sencilla y rápida de desarrollar. Los pasos son los siguientes:

1. Vamos a la página de alta de aplicaciones (se necesita usuario de Yahoo).
2. Creamos una nueva Browser-Based Authentication Protected Application

   

3. Nos pedirán confirmar el dominio subiendo un fichero determinado a nuestra web.
4. Nos bajamos la librería cliente de PHP.
5. ¡Y a picar!

Resumiendo de nuevo, tenemos la aplicación creada, apuntadas las dos keys que necesitamos y la clase para comunicarnos con Yahoo (usaremos el fichero ybrowserauth.class.php4 o ybrowserauth.class.php5 dependiendo de nuestra versión de PHP). El código final quedará así:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

<?php
 
	// datos de la aplicación que se nos facilitan cuando la registramos en Yahoo
	define('APPID','000000000000');
	define('SECRET','111111111111');	
 
	// cargamos la clase que nos proporcionan (en este caso tenemos PHP 5 en el servidor)
	require_once('apis_externas/yahoo/ybrowserauth.class.php5');
 
	// inicializamos el objeto de la clase
	$authObj = new YBBauthREST(APPID,SECRET);
 
	if(empty($_GET['token'])) 
	{
		// si no tenemos token mandamos a la página de login
		$url = $authObj->getAuthURL('',true);
		header('Location: '.$url);
		exit;
	}
 
	if($authObj->validate_sig()) 
	{
		// si validamos el token ya podemos sacar el id único
		$id_unico = $authObj->userhash;
	}
	else
	{
		// el token recibido no es correcto
		$error_api = true;
	}
 
?>

Es muy importante recordar que esta API es especial en el sentido que el id que se recibe finalmente es un hash del id único real del usuario en Yahoo y el id de la aplicación, es decir, si el mismo usuario de loguea con otra aplicación recibiremos un hash distinto, por lo que tenemos que tener en cuenta qué significa exactamente este id único que recibimos de la API.

Windows Live

Haciendo honor a su fama, y con mucha diferencia, la API de Windows Live es la más complicada de implementar, tanto por su horrenda documentación (lo de msdn es terminal…) como por el engorro general que supone lidiar con sus múltiples archivos y su extraño flujo de información.

Los pasos iniciales son similares a las anteriores APIs, la diversión viene después…

1. Vamos a la página de alta de aplicaciones (se necesita usuario de Windows Live).
2. Creamos un proyecto de Live Services: Existing APIs

   

   Es en este formulario cuando nos enfrentamos al primer problema absurdo, y es que el campo Return URL permite un máximo de 50 caracteres wtf?? cualquier ruta que no vaya a la raíz va a tener más de 50 letras! la única solución es tener una herramienta tipo firebug para poder editar online el HTML y cambiar el atributo maxlength del campo para poder enviar una URL en condiciones (lo que confirma lo absurdo de la limitación es que la página no te comprueba si has escrito más de esos 50 caracteres, se envía sin problemas…)
   Y atención también que la URL de retorno no es la misma que el resto de las APIs, es a un script que nos bajaremos luego con el SDK.

3. Nos bajamos el Web Authentication SDK para el lenguaje que vayamos a utilizar.
4. ¡Y a picar!

De nuevo tenemos una api key, otra key privada, hemos especificado una URL de retorno nueva, y tenemos su SDK con varios archivos. Lo primero es poner las keys en el fichero Application-Key.xml (debe ser innaccesible desde internet, bien limitándolo con un htaccess o colocándolo fuera del document root):

1
2
3
4
5

<windowslivelogin>
	<appid>000000000000</appid>
	<secret>111111111111</secret>
	<securityalgorithm>wsignin1.0</securityalgorithm>
</windowslivelogin>

Ahora en el directorio sample tenemos una implementación de ejemplo a la que podemos quitarle bastante paja. Lo primero es editar el fichero settings.php:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

<?php
 
	// por si las cosas no salen y se necesita consultar logs de errores 
	$DEBUG = false;
 
	// path completo al XML de configuración de la aplicación
	$KEYFILE = '/home/usuario/Application-Key.xml';
 
	// nombre de la cookie que almacena el token de usuario que manda la API
	$COOKIE = 'webauthtoken';
 
	// URL a la que tiene que redirigir cuando todo termine
	$INDEX = '/login_externo.php';
 
	// páginas a las que tiene que llevar cuanto se haga login o logout
	$LOGIN = $INDEX;
	$LOGOUT = $INDEX;
 
	// la URL de la API ¡no tocar!
	$CONTROLURL = 'http://login.live.com/controls/WebAuth.htm';
 
?>

En el fichero webauth-handler.php (recordar que es éste el que hemos puesto como URL de retorno al crear la aplicación) tenemos que poner la rutas correcta al fichero de configuración y a la librería de la API (el fichero windowslivelogin.php en el directorio lib):

1
2
3
4
5
6
7
8
9

<?php
 
	require('/home/usuario/dominio/windows_live/settings.php');
 
	require('/home/usuario/dominio/windows_live/lib/windowslivelogin.php');
 
	....
 
?>

Y finalmente el código que implementa la autenticación con Windows Live:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

<?php
 
	// el fichero de configuración de la API
	require('/home/usuario/dominio/windows_live/settings.php');
 
	// la librería del SDK
	require('/home/usuario/dominio/windows_live/lib/windowslivelogin.php');
 
	// inicializamos las variables
	$wll = WindowsLiveLogin::initFromXml($KEYFILE);
	$wll->setDebug($DEBUG);
	$APPID = $wll->getAppId();
	$userid = null;
 
	// comprobamos si el token de usuario está en la cookie
	$token = @$_COOKIE[$COOKIE];
	if(!empty($token))
	{
		$user = $wll->processToken($token);
		// tenemos token, intentamos sacar de él el id único del usuario
		if(!empty($user))
		{
			$userid = $user->getId();
		}
	}
 
	if(!empty($userid))
	{
		// guardamos el id único
		$id_unico = $userid;
	}
	else
	{
		// si no tenemos token, redirigimos al usuario a la página de login de Windows Live
		header('Location: http://login.live.com/wlogin.srf?appid=0000000040009631&alg=wsignin1.0');
		exit;
	}
}
 
?>

Quedaría, como en el resto de APIs, hacer una gestión eficiente de los errores que se pueden dar, aunque eso ya son detalles de implementación de cada aplicación.

Tampoco comento nada sobre los módulos de PHP que es necesario tener activados en el servidor para hacer funcionar las APIs. En principio los únicos que considero pudieran salirse de una configuración básica son curl y mhash. Curl se utiliza en la librería de Yahoo y es complicado buscarle una alternativa. Mhash se utiliza en la de Windows Live, y en este caso, siendo una extensión mucho menos común, se puede puentear su uso parcheando el fichero windowslivelogin.php, en concreto la línea:

1515

$key = mhash(MHASH_SHA256, $key);

Cambiándola para utilizar funciones del core de PHP5 que también realizan el hash binario SHA256:

1515

$key = pack("H*", hash('sha256', $key));

Compártelo

Estoy viciado a tumblr, enganchado a su sencillez, encantado con su filosofía y alucinando con su comunidad.

• Es sencillo como pocas cosas compartir lo que quieras en tu tumblr. Tienes un dashboard con enlaces según el tipo de contenido que quieres publicar y poco más. Rellenas un campo (dos si eres pro) y de las al botón de Create post. Hay extensiones de firefox que lo hacen tan trivial como arrastrar el contenido a un icono de tu barra de estado. Y sí, la sencillez crea adicción (¿he oído twitter?)
• tumblr es la quintaesencia de la filosofía del tumblelog, el término medio entre el blog de toda la vida y el nuevo microblogging, un espacio sin necesidad de temática fija, sin los rigores de un post más trabajado y con ese plus multimedia que a veces se echa en falta en el nanoblogging. No hay comentarios, no hay categorías ni tags… es una servilleta de papel de un bar en la que apuntas lo que te viene a la cabeza, lo que encuentras, lo que te gusta… y es tu servilleta, porque las posibilidades de personalización son totales (ver ejemplos).
• Y sin duda lo que más me ha sorprendido es la comunidad. Me recuerda la sensación que tengo cuando navego por Vimeo, todo parece de tanta calidad y veo tan poca morralla que me da que pensar si estas comunidades se forman de manera espontánea o la supuesta navegación por el portal es en realidad una visita guiada a través de un filtro anti-shit. Una muestra en el Radar y el Directorio.

  Otro plus es que es una comunidad activa (cosa que no me extraña). En tu dashboard puedes ver las actualizaciones de los tumblrs que sigues (otro vicio), y continuando con la sencillez, puedes rebloguear ese contenido o guardártelo como favorito. Todo esto para comentar que he visto como un usuario (que digo yo será bastante popular) ha colgado una foto y al minuto tenía más de 20 reblog/likes. Lástima que en castellano hayan tan pocos (bueno, tampoco me he puesto a buscar, me vale con las joyitas que voy encontrando) tumblrs…

En definitiva, para mi tumblr ha supuesto el complemento perfecto a este blog y mi tuiter. La puntilla ha sido cuanto el otro día lanzaron la integración oficial con twitter, justo en el clavo, es exactamente uno de los usos que me gusta darle al microblogging, compartir cosas que me voy encontrando en las navegaciones a la deriva… ahora por fin tengo la perfecta servilleta de papel para apuntarlos y que no se pierdan en la niebla de mi historial!

Para terminar, unos cuantos tumblrs: yimmyayo, hipstertracks, graphiceverywhere, kari-shma… y por supuesto el mio!! micro usuario de internet!!

Compártelo

Durante estos días uno no hace más que ver en Internet referencias al nuevo killer service, venerado por la blogosfera y los early adopters (frikis para los profanos), Spotify, o como dar un vuelco al negocio de la música en Internet por la patilla.

Y es que el temita promete. El otro día conseguí una invitación (ahora mismo está en beta semi-pública) sin saber qué leches iba a probar, y sin ser usuario de servicios tipo last.fm, pandora, etc… vamos, yo soy de los del género vago, de abrir la radio online a las 9:00 y no cerrarla hasta las 19:00. Pero es que ésto está tan bien hecho, es tan sencillo, tan fluido, que crea adicción, incluso en analfabetos musicales de mi calaña. Primer logro.

El servicio va de: A. Registrarse B. Instalarse su aplicación C. ¡Música! (it’s easy as 1,2,3!). La herramienta es una maravilla, un iTunes fibrado y ligero, diseño minimalista y usabilidad cuidada. Cualquier camino dentro de la aplicación termina siempre en escuchar música. Haces click en el nombre de un artista, vas a su ficha, ves toda su discografía, clickeas el track 9 del CD2 de su disco de hace 7 años y lo escuchas. TODA canción que aparezca en la aplicación simplemente haces click y la escuchas. Música gratis bajo demanda.

No voy a analizar sus pros y contras, para eso ya sabéis que hay otras webs temáticas, sólo comentar lo que me siguen sorprendiendo algunos modelos de negocio en Internet. En algo como la música, con unos proveedores que odian y desprecian al medio, y unos márgenes pírricos (creo recordar que si en iTunes una canción costaba 0.99 €, las majors se llevaban 0.70 €), no me parece muy sostenible la apuesta de Spotify, con un modelo freebie totalmente funcional (si el modelo premium lo único que me ofrece es que no me salgan ads sonoros, poco van a sacar por ahí), unos ingresos por publicidad tipo radio (¿éso lo sigue contratando alguien?) y un coste asociado al ancho de banda de servir las canciones (aunque utilicen un modelo híbrido P2P). Tal vez sea lo que se comenta por ahí, que es un torpedo con el que la industria discográfica (¿tal vez hayan aceptado menos trozo de la tarta por el compromiso de los responsables del proyecto de que algo va a cambiar?) quiere atacar a la línea de flotación de la piratería musical: “Tú, alma triste, si te pongo un programita con el puedes escuchar cualquier canción como si la tuvieras descargada ¿pa que leches quieres seguir dándole al emule?”

Y bueno, no tendrán la parte social muy desarrollada, pero en Twitter por ejemplo no paran ya de llover los enlaces para escuchar canciones. Comparto un temazo: http://open.spotify.com/track/40ThmAgDduNcjwkypLe0Dj

Por cierto, tengo unas cuantas invitaciones para probar Spotify, aunque no se si es una puerta trasera dejada abierta disimuladamente aposta o están en la parra, pero por ahora te puedes registrar sin invitación aquí. ACTUALIZACIÓN: parece ser que dicha puerta ha sido cerrada, de todas formas yo sigo teniendo unas cuantas invitaciones, si lo necesitas escribe un comentario.

su vídeo promocional

Compártelo

adoremos al pixel

Compártelo

Compártelo

En un mercado con muchos medios tradicionales aferrándose a un papel que cada vez huele más a muerto, el QUÉ se lanza en bomba a la piscina con una estrategia innovadora y apostando con fuerza por el usuario.

En líneas generales, la primera fase, el core del proyecto, es una plataforma de single sign-on que permite al usuario tener su perfil en Gente QUÉ y utilizar dichas credenciales para acceder a cualquiera de los servicios que se integren con la plataforma, de manera que cuando te logueas en uno, la sesión se mantiene durante toda la navegación por el “ecosistema” que se está montando alrededor del QUÉ.

Dejando de lado el análisis pseudo-gurú, desde el punto de vista del desarrollo yo destacaría las siguientes funcionalidades:

• ID ÚNICO. Con la facilidad de uso para el usuario en mente se ha integrado el logueo a través de sistemas externos, en concreto, con Facebook, Windows Live, Yahoo y OpenID, de manera que una vez autenticado en uno de ellos se puede registrar una cuenta en Gente que quedará ligada a dicho ID, pudiendo a partir de entonces utilizar todos los servicios del QUÉ accediendo a través de tu usuario de Facebook, por ejemplo ¡no más contraseñas desperdigadas por Internet!

  Una de las mayores complicaciones de esta parte era implementarlo de forma que el usuario lo entendiera, que no se mareara cuando de repente se le redirige a una página externa, y que pudiera darse cuenta de los beneficios que tiene esta funcionalidad. Considero que lo hemos conseguido simplificando el proceso al máximo, aunque es verdad que debemos pulirlo en las fases que vendrán.

  Lidiar con las APIs de cada servicio ha sido una de cal y otra de arena. Para variar, hacer algo con Windows Live es un picor constante en busca de documentación decente e intentando resolver comportamientos demenciales. El resto chapó. También las hemos utilizado para obtener los contactos de las cuentas e invitar a nuevos amigos. En breve haré un post explicando con detalle cómo integrar cada uno de ellos.

  
• LIFESTREAMING. Tal vez la característica más diferenciadora respecto a iniciativas de otros medios sea ésta de registrar la actividad que generan los usuarios en los servicios integrados en la plataforma. Cuando se llega al punto en que hasta los de Windows Live salen del caparazón, era un paso lógico para el QUÉ, ya que tenían centralizado el login, hacer lo mismo para la actividad del usuario.

  En gran parte relacionada con esta funcionalidad está la de comunidad, con la posibilidad de seguir a usuarios y por lo tanto, su actividad. En esta primera fase las relaciones quedan limitadas a ésto, pero habrá muchas novedades en este sentido en breve.

  
• BARRA DE USUARIO. Los servicios que se integran con Gente QUÉ debían tener alguna marca que así los identificara, y también con la necesidad de ofrecer un acceso rápido a las funcionalidades de la plataforma, se desarrolló esta barra inspirada en la de Facebook. Ahora mismo ofrece simplemente eso, accesos directos, pero es una de las partes del proyecto que más añadidos y atención va a recibir en los próximos meses, estoy seguro. Podéis verla por ejemplo desde la misma portada del QUÉ.

  Para nosotros el mayor reto fue implementar todo el tinglado con javascript, con pequeñas pijaditas como los tooltip informativos y grandes brownies como controlar si hay una sesión iniciada en Gente QUÉ desde servicios externos o idear una forma de sincronizar dicha sesión con la local, pero vamos, esto es material para otro post.

  
• APIs. Desde el principio teníamos claro que estábamos haciendo una plataforma de servicio, así que todas las funcionalidades son accesibles a través de APIs propias, de manera que cualquier servicio externo se puede integrar de forma prácticamente transparente con la plataforma de forma sencilla y rápida. Un total de más de 15 APIs y 30 páginas de documentación dan fe de lo grande que es este proyecto y la casi total flexibilidad que ofrece para futuras integraciones y cambios.
  

Para nosotros ha sido un proyecto complicado, pero con el que sobre todo hemos aprendido mucho. Cuando te metes en desarrollos de este tipo, tan dinámicos y con programadores de todos los niveles, se descubren enseguida las carencias en la metodología de trabajo que puedas tener. Ahora es cuando nos vamos a plantear implantar cosas de esas que usan los profesionales con carrera (framework, subversion, gestión avanzada de bugs…), hasta ahora hemos podido pasar sin ellas, pero la cosa se pone seria!

Compártelo

Compártelo

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.

Compártelo

Compártelo