:: Verborrea Esporádica ::

Hace un par de días, me surgió un problema con el contenido de la base de datos sobre la que estoy trabajando. El script de carga, con el DDL de las tablas y relaciones, así como los insertsde todas ellas, fue generado en un servidor Linux -a través de una conexión SSH, supongo, porque los 150Mb que ocupaba no los genera el phpMyAdmin ni de coña-, comprimido en gzip y dispuesto para su descarga vía HTTP.

Al bajarlo y extraerlo, mi primera intención fue abrirlo, para cerciorarme de que el contenido es correcto y, de paso, añadirle un create database y su correspondiente use -para qué me voy a tirar el moco, hasta ayer no supe que al comando mysql se le puede pasar, como argumento, la base de datos sobre la que volcar el script xD- pero viendo que ese mamotreto, hasta al UltraEdit en un Pentium 4 a 3Ghz le costaba sudores manejarlo, decidí cargarlo “a pelo”, como un campeón

Así que nada,


gtmuser@gtmserver[~]# mysql -u gtmuser -p gtm < gtmnuevo.sql
Enter password: ********

Y a cargar…

Una hora después, tenía mi flamante modelo de datos cargadito en el servidor y listo para conectar. A ver, a ver…cargo mi SQLYog, me conecto, me voy a la tabla de idiomas, por ejemplo, y…¡mierda!

IdIdioma | Idioma
——————-
1…………….Inglás
2…………….CatalÃí¬n
3…………….Espaéol
…

¡ya estamos con el charset y los collations jodiendo!

A ver, repasemos:
El campo.
IdIdioma char(3) latin1
Pues nada, utf8 al canto. No funciona, pero al menos me deja ya meterle caracteres non-ascii.

La tabla.
recIdioma InnoDB latin1_swedish_ci.
Lo mismo, utf8. Sigue sin funcionar.

Y si llamo a…? Claro! Este en Coritel se ha pegao con SQL-Server y ASP.NET, seguro que sabe de charsets.

Conversación Gmail Talk
Usuario: Pabloooo mira lo que me pasa!! [...]
Pablo: xDDDD Pringao
Pablo: Espera que le pregunto a Ángel.
[...]
Pablo: Me dice Ángel que tendrás que subir el script de nuevo
Usuario: Me c*** en la vi**** pu** y en el cura con la sotana
Pablo: Me voy a comé

Pablo se ha desconectado…

Bueno, que no cunda el pánico. Sigamos el proceso anterior, ahora toca el servidor en sí. Puede ser que esté interpretando a su bola el texto. Y tiene su lógica, al fin y al cabo vim, emacs, joe, cat…todos me muestran por SSH los mismos caracteres extraños.
Revisando la documentación de MySQL, descubro una entrada del my.cnf que puede servir:

default-character-set=utf8

Con eso, todo lo que le entre y salga, será utf8. Es equivalente a cambiar el valor de la variable de sistema set names utf8.

Nada, a reiniciar MySQL.

root@gtmserver[~]# /etc/init.d/mysqld restart
Stopping MySQL service…..done
Starting MySQL service…..done

Miro la tabla y me dice que me peine. Desesperación, resoplidos. Abro el archivo con el UltraEdit y le hago una conversión a UTF8, función que lleva integrada el programa. Sorprendentemente, lo hace al instante, de lo que se deduce que no ha convertido nada, lo que ha hecho es cambiar la forma de interpretar el texto. ¿Y si hay algo así para el propio comando mysql?

PUES LO HAY xD

En la referencia de uso del comando, se puede encontrar el siguiente argumento:

--default-character-set

curiosamente igual que la directiva de la que hablamos antes. Pues nada. La definitiva:

gtmuser@gtmserver[~]# mysql -u gtmuser -p gtm < gtmnuevo.sql –default-character-set=utf8
Enter password: ********

Termina. Consulto. ¡¡¡E voilà!!!

IdIdioma| Idioma
—————–
1……………Inglés
2……………Catalán
3……………Español
…

Pero no todo el monte es orgasmo, como decía Cándida xD La consulta vía SSH o SQLYog funciona. ¿Pero qué hay de lo que nos interesa, nuestra aplicación web?
Pues con todo el tinglado montado, consulto un módulo que muestra una lista desplegable con los idiomas y veo, horrorizado, como siguen apareciendo los dichosos caracteres extraños.

Hete aquí, que los navegadores tienen una opción (En IE, en el menú Ver - Codificación / En Firefox, en el menú Ver - Codificación de caracteres) para seleccionar manualmente el charset con el que interpretar el código HTML. Pues bien, en este caso, veo que está usando por defecto la ISO-8839-1, así que la cambio desde el propio menú a utf8 y, en tiempo real, todo vuelve a la normalidad.

Esta es fácil. Al escribir HTML, en la cabecera de las páginas, se suele especificar un elemento META, con el charset que se debe usar para interpretarla. Así que basta con cambiar -en mi caso-:


<meta http-equiv="Content-Type" content="text/html; charset=iso-8839-1" />


…por…


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


Y listo. Dos horas y media de quebraderos de cabeza, pero por fin me puedo ir a comer tranquilo xD

Tags: Desarrollo aplicaciones, Desarrollo web, General, Tecnología