Bueno, pues ésta es una de las cositas que he descubierto en el proceso de migración de Proyecto Isla. Ya había realizado alguna que otra migración, y lo cierto es que nunca me había encontrado con algo como esto: al exportar las bases de datos desde Hostgo a phi:hosting, los caracteres de todos los textos perdían el formato. Me refiero, como debes suponer, a acentos, ñ y signos especiales. ¿Qué ocurría? Simple (pero delicado): hostgo trabaja con MySQL 4.1.13, mientras que phi:hosting, por razones de seguridad (consideran que la versión 4.1. es aún inestable en algunos puntos), lo hace aún con MySQL 4.0.25. Es decir, que me encontraba trasladando mis bases de datos desde una versión reciente a otra más antigua, justamente lo contrario de lo que resulta normal: cambiar a una versión más avanzada.
Pues bien, el problema radicaba, fundamentalmente, en que las nuevas versiones de MySQL incorporan un nuevo atributo, Collation, que afecta a la codificación de caracteres y que se integra al final de cada tabla en el proceso de exportación. Al intentar importar en la versión 4.0, lógicamente da un error. Y no se puede importar. Lo grave: Hostgo tenía configurado el servidor en latin1; y phi:hosting en UTF-8.
Esta primera alegría en mi mudanza fue rápidamente resuelta al percatarme de que el menú de exportación de la versión 4.1.13 incorpora la posibilidad de exportar en formato 4.0. Y no me lo pensé dos veces. Exporte. Importé. Y voilá… los caracteres al carajo. ¿Callejón sin salida? Probablemente. Lo único que hace la exportación en formato 4.0 es suprimir la cadena en la que se integra el famoso Collation, pero al mismo tiempo impide que se salven los textos con los caracteres adecuados.
Tras recorrer como un poseso la red en busca de soluciones, llegué al convencimiento de que sólo había tres salidas:
a) Que phi:hosting actualizara de la versión 4.0 a la 4.1
b) Que phi:hosting formateara el servidor en latin1
c) Que Manolito Almeida se buscara la vida.
¿Cuál prosperó? Efectivamente, has acertado: la c). Las dos primeras opciones requerían, respectivamente, que o bien phi:hosting dejara sin servicio durante un buen tiempo a sus usuarios y se arriesgara en una versión en la que no confían, o bien se cargaran el formato de caracteres de todos los sitios alojados en sus máquinas con el único, pero noble fin, de que Proyecto Isla se viese lo bonito que es.
Además de recurrir a los manuales específicos de MySQL y de cuanto a Character Set y Collation encontré en Google, la gente de phi:hosting me recomendó un tópic del foro de WordPress. Lo probé todo, pero nada. Y justo cuando estaba a punto de arrojar la toalla (probablemente para recogerla poco después), se me encendió una lucecita.
Y esto fue lo que hice:
a) Llegué a la conclusión de que la conversión de caracteres se producía en algún punto de la exportación, porque al abrir el archivo .sql, ya aparecían los signos mal dibujados. Es decir, descartaba que tuviera algo que ver con la importación.
b) Observé cómo la conversión de caracteres se producía sólo al exportar a archivo (fichero que te descargas en el ordenador), pero no cuando se exportaba en formato 4.0 a pantalla (se te abre un frame en la pantalla), siempre y cuando tuviera la codificación del ordenador en UTF-8.
c) ¿Y si recurro al viejo copio y pego de toda la vida, copio de la pantalla y pego en un fichero de texto previamente creado? Ahí me habría saltado el mecanismo de configuración de la exportación y, con un poco de suerte, la versión 4.0 lo reconocería al importar. ¿Tan fácil? Hmmm…
d) ¡Dicho y hecho! Un éxito y una alegría que no podría describir, más que nada porque podría volver a saturar el servidor. Y tampoco es plan, oshe.
Seguramente habrá quien piense: “pues vaya tontería”, y quien ya conociera el remedio antes que la enfermedad, pero les puedo asegurar que, si bien la solución ha sido fácil, el camino para llegar hasta ella ha sido complicado y angustioso, entre tanta página suspendida, tanta migración paralizada, y tantas ganas de volver a la Red. Ni siquiera en Hostgo o en phi:hosting sabían darme una solución.
Simplemente lo cuento por si alguien más se ve en la tesitura. La necesidad aviva la imaginación, y la mía andaba ya un tanto desbordada.
Quizás también te interese:
|
|
|
|
|
{ 6 comentarios }
Al menos tantos esfuerzos sirvieron de algo, Manuel.
A ver si ahora te llega la compensación al trabajo realizado y ya no hay más problemas.
¡Suerte!
Lo primero, enhorabuena por estar otra vez online
Hay otra forma de hacer esas conversiones que he utilizado en algunas ocasiones, cuando los exports de las bases de datos son tan grandes que directamente eliminan algunas soluciones, como la que al final utilizaste (simplemente porque acaba dando un timeout el PHP por mucho que lo subas antes de terminar de mostrarte todo el “dump”).
Este otro truquito consiste en usar iconv en lo siguientes pasos:
- Exportas la base de datos a un fichero de texto SQL
- lanzas iconv instruyendolo con el conjunto de caracteres de entrada, el que quieres de salida, fichero de entrada y fichero de salida.
- Importas el fichero que has conseguido en el paso anterior, ya convertido al “character set” que quieras.
Aunque a estas alturas ya no te sirva, al menos que valga también como otra solución.
Gracias, Wizard. Esperemos que así sea. Lo cierto es que noto el blog bastante más ligerito. A ver si al final va a ser el servidor de Hostgo
Un saludo.
Gracias, Marino. La verdad que pinta muy bien. Ya lo sé para la próxima.
Un saludo.
Lo mejor de este tipo de cosas en las que piensas y repiensas tanto buscando una solución es que cuando la encuentras piensas para tus adentros… soy la ostia de listo, acompañado muchas veces de un… ¿y ahora a quien se lo cuento que lo entienda?
Ya me he enfrentado en el pasado con mambos de Latin1/UTF8 y sus EseCuEles, alguna vez (para un amigo) llegué a hacer un Replace de chinitos por sus caracteres castellanos
(un horror); te felicito por haberlo logrado.
Los comentarios están cerrados.