Forum GLPI-Project

moi

Member

Registered: 2007-01-25

Posts: 21

Encodage encore...

Bonjour,

Je dois surement être stupide, mais je ne capte pas les problèmes d’encodage :

Par défaut ma base Mysql, est en « latin1_swedish_ci »… (Version 5.0.27), configuration de base lors de l’installation de MYSQL…

J’ai installé directement (pas de mise à jour) la version 0.68.1 de GLPI.

Dans GLPI, nous avons saisi des caractères accentués (Je sais c’est très con, mais bon…)

Donc dans l’interface de GLPI pas de problème. Si j’exporte ces données les mots avec des caractères accentués ne ressemblent plus à rien :

'Brevet France N° 93/0' au lieu de ‘Brevet France N°93/0’

J’ai donc cherché dans le forum, et j’ai trouvé ce topic :
http://glpi-project.org/forum/viewtopic.php?id=1132

J’en ai conclu que l’encodage utilisé dans GLPI était UTF8, j’ai bon là ?

Deuxième question : qu’est ce que j’ai raté lors de l’install pour que ma base ne soit pas en UTF8 ?

Comme il est dit dans le topic sus mentionné, j’ai dumpé la base l’ai converti en UTF8 avec la commande ‘iconv -f ISO-8859-1 -t UTF-8 -o glpi_utf8.sql 2005-09-21-11-05.sql’ puis réinjecté dans une base sandbox. Et là c’est encore pire :

‘'Brevet France N°93/0'’ alors qu’avant j’avais 'Brevet France N° 93/0' au lieu de ‘Brevet France N°93/0’.

Je crois donc avoir raté encore autre chose…

Pour résumer :

GLPI --> UTF8 ou pas ?
Mysql --> UTF8 ou latin1_swedish_ci ?
Et client mysql sous windows --> quel encodage ?
(n’importe quel browser sql sous windows donne le même résultat…)

Merci par avance de bien vouloir éclairer ma lanterne

moi

Member

Registered: 2007-01-25

Posts: 21

Re: Encodage encore...

Quelques info suplémentaires :

PARAMETRES MYSQLD :

character set client utf8
(Valeur globale) latin1
character set connection latin1
character set database latin1
character set filesystem binary
character set results utf8
(Valeur globale) latin1
character set server latin1
character set system utf8
character sets dir /usr/share/mysql/charsets/
collation connection latin1_general_ci
(Valeur globale) latin1_swedish_ci
collation database latin1_swedish_ci
collation server latin1_swedish_ci

Dois je modifier certains de ces paramètres ? ou peut être recompiler Mysql pour accorder son fonctionnement à GLPI ?

Autre info :
Sur un serveur de test (sandbox), j'ai transformé toutes les tables GLPI en UTF8 avec ALTER TABLE `glpi_peripherals` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci, commande proposé par phpmyadmin (Mais ce n'est peut être pas une bonne idée ?)
j'ai contrôlé que tous les champs sont bien en UTF8 également. J'ai réimporté toutes les données depuis le fichier converti en UTF8 (voir post précédent).
j'ai mis à jour de la version 0.68.1 vers 0.68.3.
Et j'ai toujours le même problème :

Les accents sont illisiblent lorsque je fais une requête depuis phpmyadmin ou n'importe quel browser SQL sous windows...

moi

Member

Registered: 2007-01-25

Posts: 21

Re: Encodage encore...

Autres précisions :

Je repart de zéro :

Je modifie le fichier /etc/my.cnf pour y rajouter ces lignes :

[mysqld]
default-character-set=utf8
init-connect=SET NAMES utf8

et

[client]
default-character-set=utf8

Je redémarre mysqld (of course !)
Ce qui donne maintenant dans les variable de mysqld :

character set client  utf8  utf8 
character set connection  utf8  utf8 
character set database  utf8  utf8 
character set results  utf8  utf8 
character set server  utf8  utf8 
character set system  utf8  utf8 
character sets dir  /usr/share/mysql/charsets/  /usr/share/mysql/charsets/ 
collation connection  utf8_general_ci  utf8_general_ci 
collation database  utf8_general_ci  utf8_general_ci 
collation server  utf8_general_ci  utf8_general_ci 

Je refais une nouvelle base GLPI en m'assurant que c'est bien en UTF8...

Je réinstalle la version 0.68.3, l'install me reconstruit les tables, je m'assure que tout est en UTF8
Donc là normalement je suis en droit d'avoir quelques espoirs non ?

Ben non ... :
Première connection, avant même de touvher à quoi que se soit je saisie un périphérique :
Dans nom je rentre : 'périphérique à partir d'un modèle' et si je fais une requête dans phpmyadmin ou dans le client mysql de linux (en local) ou le client sous windows j'ai toujours ça : ''périphérique à partir d'un modèle''. Alors que dans l'interface j'ai 'périphérique à partir d'un modèle'

Quelqu'un a une idée ?

meuced

Member

From: CH du Val d'Ariège

Registered: 2007-01-23

Posts: 157

Re: Encodage encore...

Ben non ... :
Première connection, avant même de touvher à quoi que se soit je saisie un périphérique :
Dans nom je rentre : 'périphérique à partir d'un modèle' et si je fais une requête dans phpmyadmin ou dans le client mysql de linux (en local) ou le client sous windows j'ai toujours ça : ''périphérique à partir d'un modèle''. Alors que dans l'interface j'ai 'périphérique à partir d'un modèle'

c'est parce que :
- ton terminal linux n'est pas en utf8 donc interpréte mal ce que le client mysql lui envoie.
- idem pour le client mysql sous windows
- et pour phpmyadmin et il faut le modifier pour que l'export qu'il fasse soit "lisible" sous windows, càd dans un jeu de caractères iso-latinchaisplukoi. par contre l'injection d'un tel dump dans la base d'origine en utf8 sera pas bon... et même le dump généré avec le phpmyadmin aussi...
dans mon phpmyadmin l'interclassement pour la connexion MySQL est en utf8_unicode_ci (page d'accueil) par contre, et les accents s'affichent bien dans phpmyadmin.

par contre si en local sous linux tu fait un mysqldump, tu peux réinjecter ce dump sans aucun problème même si un more t'affiche mal les accents.
c'est ce moyen que j'utilise pour faire les sauv et restore si besoin. au moins, je suis pas embêté.

enfin bref, c'est quand même encore un peu flou pour moi, tout ça, je l'avoue...
sous mon linux, l'interclassement des tables est en latin1_swedish_ci par défaut... mais ça marche...

en gros, faire des tests d'export, import dans tout les sens, avec plusieurs clients, et voir quel résultat est bon... ainsi on peut finir par en déduire certaines choses...

bon courage

meuced

Member

From: CH du Val d'Ariège

Registered: 2007-01-23

Posts: 157

Re: Encodage encore...

je viens de faire un tas de tests.

en gros ce qui en ressort :

Environnement sous windows avec XAMPP
d'abord, créer une base vide avec interclassement utf8_unicode_ci
installer glpi, lui indiquer la base créée à la main.
=> la base et les tables sont en utf8

rentrez une info (genre le domaine dans les imprimantes) avec des accents => tout est bien affiché dans glpi.

les accents seront mal affichés dans phpmyadmin.
les accents dans le fichier de dump généré seront aussi mal affichés.
CEPENDANT si vous importez ce dump à nouveau dans une autre base créée en utf8_unicode_ci, les accents seront toujours ok dans glpi.
Ainsi vos export/import à partir de phpmyadmin seront tour OK.
par contre, pour les inserts d'infos à la main dans phpmyadmin, ça marche pas...

en fait c'est assez complexe comme problème, y'a le charset, l'interclassement, dans la base, dans les tables, dans les fichiers produits, et les charset que le client comprend....
si un jour j'ai une journée à perdre, je me pencherais dessus pour faire une vrai doc à ce propos...

meuced

Member

From: CH du Val d'Ariège

Registered: 2007-01-23

Posts: 157

Re: Encodage encore...

ajout : voir la page http://www.developpez.net/forums/showth … ost1222765
ça peut aider pour l'affichage dans phpmyadmin et peut-être l'insert, mais je crois que ça fout en l'air les histoires d'export/import....
à tester.

Last edited by meuced (2007-02-15 13:00:57)

meuced

Member

From: CH du Val d'Ariège

Registered: 2007-01-23

Posts: 157

Re: Encodage encore...

je viens de faire un tas de tests.

tests sur un environnement serveur windows mais qui logiquement doivent donner des résultats identiques sur un environnement serveur linux.

moi

Member

Registered: 2007-01-25

Posts: 21

Re: Encodage encore...

Je confirme que quelque soit l'environnement le résultat est le même.

Sinon, je te remerci de te pencher sur le problème, mais en fait je n'ai pas de soucis avec les exports/imports. Je l'ai déjà fait plusieurs fois pour 'bouger' ma base d'un serveur à un autre et pour ça tout va bien. (mis à part pour OCS...)

Mon soucis était sur comment exporter une requête sql sur mesure dans un fichier genre excel de façon lisible. sous forme d'état personnalisé pour mes patrons quoi

Quelques glpiens furieux m'ont aidé à trouver une solution dans ce post :
http://www.glpi-project.org/forum/viewtopic.php?id=5516

Il s'agit d'utiliser oOo avec base et calc et ensuite d'exporter vers n'importe quels formats de fichier en fonction des besoins.

J'avais ouvert un autre post sur le même sujet pensant avoir mal formulé mon problème dans celui-ci

MoYo

GLPI - Lead

From: Poitiers

Registered: 2004-09-13

Posts: 14,513

Website

Re: Encodage encore...

et pourquoi ne pas faire des raports / stats pour GLPI directement en php ?
vous n'aurez aucun problème d'encodage et au final cela pourrait servir a toute la communauté.

---

MoYo - Julien Dombre - Association INDEPNET
Contribute to GLPI :    Support     Contribute     References     Freshmeat