En date de : Dim 15.3.09, Pi r <pierre.troller@gmail.com> a écrit :
La conversion en UTF-8 depuis fulltext a me semble t-il mis
le bazar dans la base, j'ai par exemple des champs titre
de spip_articles en latin1_swedish_ci et des champs titre de
spip_rubriques en utf8_general_ci
=> les champs latin swedish affichent des hieroglyphes
alors que les utf-8 étaient ok.
Ayant constaté que charset_sql_base et
charset_sql_connexion affichaient utf8, je les ai changé
pour utf-8.
Maintenant c'est le contraire, les latin1_swedish des
articles sont ok alors que les utf 8 affichent des points
d'interrogation,
que faire?
la conversion (et les problèmes qu'elle entraîne...) ne sont pas le fait du plugin fulltext puisque celui-ci ne fait qu'un lien vers les pages de conversions de SPIP... (mais j'imagine que ça vous fait une belle jambe de savoir que votre site à été flingué par le core de SPIP plutôt que par un plugin...)
Alors, en principe, vous devriez vous en sortir (?) avec le fichier /tmp/convert_utf8_backup.sql qui est une sauvegarde créée automatiquement lors du lancement de la conversion en utf8.
Ceci dit, ça montre bien le vaste b*** de MySQL en matière de caractères pour le stockage des données avec des tables ayant un charset par défaut mais des champs avec un autre charset!
En date de : Dim 15.3.09, Pi r <pierre.troller@gmail.com> a écrit :
La conversion en UTF-8 depuis fulltext a me semble t-il mis
le bazar dans la base, j'ai par exemple des champs titre
de spip_articles en latin1_swedish_ci et des champs titre de
spip_rubriques en utf8_general_ci
=> les champs latin swedish affichent des hieroglyphes
alors que les utf-8 étaient ok.
Ayant constaté que charset_sql_base et
charset_sql_connexion affichaient utf8, je les ai changé
pour utf-8.
Maintenant c'est le contraire, les latin1_swedish des
articles sont ok alors que les utf 8 affichent des points
d'interrogation,
que faire?
la conversion (et les problèmes qu'elle entraîne...) ne sont pas le fait du plugin fulltext puisque celui-ci ne fait qu'un lien vers les pages de conversions de SPIP... (mais j'imagine que ça vous fait une belle jambe de savoir que votre site à été flingué par le core de SPIP plutôt que par un plugin...)
Alors, en principe, vous devriez vous en sortir (?) avec le fichier qui est une sauvegarde créée automatiquement lors du lancement de la conversion en utf8.
Ceci dit, ça montre bien le vaste b*** de MySQL en matière de caractères pour le stockage des données avec des tables ayant un charset par défaut mais des champs avec un autre charset!
cdlaballe... sauf que j'ai pas de fichier /tmp/convert_utf8_backup.sql
mais j'ai fait un dump de la base avant de lancer la conversion
sauf que j'ai pas d'options de restauration dabs ?exec=admin_tech
alors que les dumps sont dans tmp/dump...???
mdr. bon je vais essayer par phpmyadmin...
le chat veut finir en botté
En date de : Dim 15.3.09, Pi r <pierre.troller@gmail.com> a écrit :
la conversion (et les problèmes qu'elle entraîne...) ne sont pas le fait du plugin fulltext puisque celui-ci ne fait qu'un lien vers les pages de conversions de SPIP... (mais j'imagine que ça vous fait une belle jambe de savoir que votre site à été flingué par le core de SPIP plutôt que par un plugin...)
Alors, en principe, vous devriez vous en sortir (?) avec le fichier /tmp/convert_utf8_backup.sql qui est une sauvegarde créée automatiquement lors du lancement de la conversion en utf8.
Ceci dit, ça montre bien le vaste b*** de MySQL en matière de caractères pour le stockage des données avec des tables ayant un charset par défaut mais des champs avec un autre charset!
Bon courage!
J'ai trouve plus simple de faire une sauvegarde SPIP de la base, puis la vider completement de toutes ses tables et faire une installation fraiche de SPIP 205. Cette installation a donne des tables et des champs en collation utf8_general_ci completement. Il n'y avait plus qu'a restaurer la sauvegarde.
En fait c'est ce que je vais faire avec mes autres sites en 192 pour le passage en 205. jene vais pas me contenter de la mise a jour.
En date de : Dim 15.3.09, Pi r <pierre.troller@gmail.com> a écrit :
la conversion (et les problèmes qu'elle entraîne...) ne sont pas le fait du plugin fulltext puisque celui-ci ne fait qu'un lien vers les pages de conversions de SPIP... (mais j'imagine que ça vous fait une belle jambe de savoir que votre site à été flingué par le core de SPIP plutôt que par un plugin...)
Alors, en principe, vous devriez vous en sortir (?) avec le fichier /tmp/convert_utf8_backup.sql qui est une sauvegarde créée automatiquement lors du lancement de la conversion en utf8.
Ceci dit, ça montre bien le vaste b*** de MySQL en matière de caractères pour le stockage des données avec des tables ayant un charset par défaut mais des champs avec un autre charset!
Bon courage!
J'ai trouve plus simple de faire une sauvegarde SPIP de la base, puis la vider completement de toutes ses tables et faire une installation fraiche de SPIP 205. Cette installation a donne des tables et des champs en collation utf8_general_ci completement. Il n'y avait plus qu'a restaurer la sauvegarde.
Oui, c'est vraiment le mieux à faire pour repartir sur une base propre, car avant la 2.0 les charset étaient vraiment gérés de manière .... hasardeuse.
Mais cela fait perdre les stats et autres revisions...
J'ai trouve plus simple de faire une sauvegarde SPIP de la base, puis la vider completement de toutes ses tables et faire une installation fraiche de SPIP 205. Cette installation a donne des tables et des champs en collation utf8_general_ci completement. Il n'y avait plus qu'a restaurer la sauvegarde.
Oui, c'est vraiment le mieux à faire pour repartir sur une base propre, car avant la 2.0 les charset étaient vraiment gérés de manière .... hasardeuse.
Mais cela fait perdre les stats et autres revisions...
Cédric
C'est vrai mais j'avais oublie de dire que pour la sauvegarde avant la suppression j'avais choisi toutes les tables.