mailRe: [Galette-discussion] MAJ galette 8


Others Months | Index by Date | Thread Index
>>   [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Header


Content

Posted by laperdrix on October 17, 2014 - 12:14:
bonjour,

voici, ma solution qui à marché plusieurs fois, surtout pour les
sauvegarde en SQL.
1) Export de la base galette 0.78 en SQL ( partielle si très
volumineuse)
2) Ouvrir avec le logiciel bluefish (logiciel libre)
3) et utiliser dans menu : outils/conversion/ entités en caractères
4) import dans galette 0.8

après 2 semaines d'utilisation, je n'ai pas trouvé d'erreurs.

Cette solution me paraît simple, est-elle universelle ?

Le mercredi 15 octobre 2014 à 10:43 +0200, Geguce a écrit :
Bonjour

Comme indiqué , en V0.7 si vous allez ds phpmyadmin et si dans les 
tables vous voyer les é s'afficher en tant que  é alors la procédure 
doit fonctionner.

Vous allez à Exporter "Personnalisée - afficher toutes les options 
possibles" et vous indiquez ISO-8859-1 ou Windows-1252 comme jeu de 
caratères, cocher "Désactiver la vérification des clés étrangères" et 
"Ajouter un énoncé|DROP TABLE"
Dans la liste des tables exclure éventuellement la table _pictures et les 
tables des plugins ayant des BLOBS (qui ont parfois besoin de rester en 
UTF8 lors de l'export, c'est à tester).

Vérifier avec un éditeur comme notepad+ ou mieux avec un éditeur HEXA que 
le fichier obtenu code bien vos é par|é.

Importer maintenant ds la version 0.8 (la ligne 125 ne doit pas être 
commentée) votre fichier SQL et vous devriez voir vos é correctement dans 
galette ET dans Phpmyadmin.
Vérifier dans la table des pictures depuis phpMyadmin que vous pouvez 
ouvrir les blobs dans une visionneuse de photos. Si ils sont codés 
correctement la photo doit s'afficher, sinon il faut faire des essais 
d'export avec des codages différents depuis phpmyadmin ou essayer un export 
avec mon plugin savemysql

Une autre solution consiste à changer le codage d'un export "plugin 
savemysql"
  avec notepad+ ou autre (après décompression en SQL et hors BLOBS)
Tenez nous au courant des résultats.



Le 14/10/2014 23:35, François-Régis a écrit :
Salut,

Chez moi (serveur Debian wheezy, mysql 5.5.38-0+wheezy1 et galette 0.8)
je rencontre le même problème.
En fait j'ai l'impression que les champs des tables mysql ne sont pas
enregistrés en utf8 mais en latin1 dans la version 0.7.8 de galette
(alors que ces champs sont déclarés avec un interclassement
utf8_unicode_ci).
Donc en commentant la fameuse ligne 125, on retrouve en 0.8 le
comportement de la 0.7.8 mais ce n'est pas satisfaisant.

Si l'on considère que la version gérait mal les jeux de caractère de
mysql, il faudrait proposer une méthode pour faire la transition.

Malheureusement, j'ai essayé tout ce que je pouvait (export depuis
galette, phpmyadmin, mysqldump ...), j'arrive parfois à obtenir un
fichier utf-8 qui me semble correct mais l'import rétablis les erreurs
de feu de caractère...

Si quelqu'un a une idée ?

Le 11/10/2014 10:56, geguce@xxxxxxx a écrit :
Salut
Supprimer la ligne 125 va sans doute faire en sorte que la base migre de 
la version 7 à la 8 correctement MAIS voilà que maintenant et à nouveau 
les enregistrements dans la base sont mal codés,  é apparait sous é ds 
phpMyadmin (comme ds la v 7) alors qu'en laissant la ligne 125 tout 
semble se faire en UTF8 et ds galette et ds la base, é est affiché é ds 
PhpMyAdmin. J'opterai donc pour conserver cette ligne 125 qui rend le 
tout cohérent. Aussi les exports depuis phpMyAdmin en UTF8 puis imports 
en UTF8 fonctionnent sans problème ce qui n'est pas le cas en commentant 
la ligne 125.(vérifié avec éditeur Hexa)  Donc OUI à galette .8 qui gère 
correctement UTF8 d'après ce que je constate.
Pour les utilisateurs qui auraient des pb de ce genre, la solution de 
l'import/ export reste un passage obligé.
Solution préconisée: Exporter depuis phpMyadmin toutes les tables en ISO 
et les importer en UTF8 sauf pour les tables contenant des images 
(galette_pictures sans oublier le cas échéant celle des plugins) qui 
doivent être exportées à part en UTF8 et importées en UTF8 pour ne pas 
détruire les données binaires qui elles, sont codées correctement dans 
la base.

François


----- Mail original -----
De: "Johan Cwiklinski"<johan@xxxxxxxx>
À: galette-discussion@xxxxxxx
Envoyé: Samedi 11 Octobre 2014 08:55:20
Objet: Re: [Galette-discussion] MAJ galette 8

Salut,

Le 05/10/2014 17:02, Geguce a écrit :
Idem ici, en version mysql 5.1.73 et php 5.4.30 chez OVH.
Des essais en local avec les dernières versions de Wamp et Xamp donnent
des résultats identiques.
Le fichier en import est bien en UTF-8 (é = é confimé par éditeur hexa
en C3 A9).
Dans phpmy admin c'est bien un é qui est affiché mais galette 8
l'affiche non décodé.

Dans la version .7.8 galette affichait bien é  mais dans phpmyadmin on
voyait é.
Une chose est certaine, le comportement des 2 versions n'est pas le même
vis à vis du codage ! Lequel a tout juste, je l'ignore en tout cas pour
la migration c'est galère.  Comme solution transitoire j'exporte
iso8859-1 et j'importe en UTF-8 (sauf pour les blobs).
François
Ce qui m'intéresserait, c'est de savoir si la correction que je
proposais fonctionne dans ce cas (et aussi si cette correction pose des
problèmes à ceux qui n'ont actuellement pas de problèmes !).

Cette modification fait suite à une demande concernant un problème de
migration depuis une Galette 0.63. À priori, ça pose plus de problèmes
que ça n'en résout (je n'ai quant à moi pas de soucis d'encodage) ; je
pense à supprimer la modification, mais je voudrai être certain que ça
ne va pas tout casser non plus...

++


_______________________________________________
Galette-discussion mailing list
Galette-discussion@xxxxxxx
https://mail.gna.org/listinfo/galette-discussion


_______________________________________________
Galette-discussion mailing list
Galette-discussion@xxxxxxx
https://mail.gna.org/listinfo/galette-discussion





Related Messages


Powered by MHonArc, Updated Fri Oct 17 14:40:09 2014