passage UTF-8

christophe · 2005-09-20 09:38:29

Bonjour,

Je viens de mettre à jour en version 0.6, tout est OK sauf l'affichage des caractères accentués du contenu de la base. Si je mets mon navigateur en encodage normal (pas UTF-8), les données s'affichent OK mais pas les menus de l'interface GLPI.

Je pense que je dois indiquer UTF-8 quelque part, mais où ? dans apache ? dans php ? dans mysql ?

Version GLPI : 0.6
Versions LAMP : dernière release de RedHat ES3 (php 4.3.2, mysql 3.23.58, apache 2.0.46)

MoYo · 2005-09-20 09:47:32

Non GLPI indique UTF-8 dans le header normalement.
Quel navigateur utilisez vous ?
Est-ce que les données sotn bien en UTF-8 dans la DB ?

christophe · 2005-09-20 10:03:39

Le problème est pésent sur mes 2 navigateurs : IE6 et FF1.6

non, mysql est en latin1, les données GLPI existantes ne sont pas en UTF-8

Ma base partage d'autres applis php qui ne sont pas en UTF-8, je ne peux donc pas migrer son charset.

J'ai vu sur un forum comment convertir une base en UTF-8 : on fait un dump, on applique un iconv du dump vers UTF-8 et on réinjecte.

Mais ensuite à l'utilisation, est-ce GLPI fait des encode/decode UTF-8 dans les requêtes ? Sinon les nouvelles données seront encodées dans le charset par défaut de mysql.

Netman · 2005-09-20 10:44:48

Je suis dans le meme cas au sujet des bases latin et utf8.
Je viens d'installer glpi 0.6 , je n'ai pas de problème pour l'instant.

Last edited by Netman (2005-09-20 11:28:56)

MoYo · 2005-09-20 12:24:14

c'est que la mise a jour vers la 0.6 n'a pas été complete.

A la mise à jour les données de la DB doivent etre transformées en UTF8.

christophe · 2005-09-20 12:42:27

la procédure de MAJ en 0.6 s'est déroulée sans msg d'erreur, sans problème jusqu'au bout.

Quelle procédure me recommandez-vous pour régler mon pb ?

MoYo · 2005-09-20 13:44:37

depuis quelle version avez vous fait la mise a jour ?

christophe · 2005-09-20 16:15:13

j'ai fait la maj depuis la version 0.51a

MoYo · 2005-09-20 16:23:28

donc cela devrait fonctionner.

MoYo · 2005-09-20 16:28:44

Vous pouvez pour forcer la mise à jour en UTF8 modifier le fichier update_content.php en remplacant les lignes 401 à 404 :
$conv_utf8=false;
if(!FieldExists("glpi_config","utf8_conv")) {
$conv_utf8=true;
}
par
$conv_utf8=true;

si cela ne met toujours pas a jour vos data en UTF8 dans la DB vous pouvez ajouter la ligne suivante :
return false;
à la ligne 124 , c'est à dire juste après :
function seems_utf8($Str) {

christophe · 2005-09-21 10:24:45

désolé pour le temps de réponse, j'ai beaucoup de tâches simultanées en ce moment...

J'ai forcé la conversion en mettant $conv_utf8=true;

j'obtiens le message d'erreur suivant :
0.6 add utf8_conv to glpi_configDuplicate column name 'utf8_conv'

Je dois comprendre que pour lui ma conversion a déjà eu lieu ?? mais pourtant ma base a toujours les carcatères en latin1

Je n'ai pas opéré l'autre suggestion car je pense que si j'ai cette erreur, c'est que la fonction seems_utf8 a renvoyé vrai ?

MoYo · 2005-09-21 11:07:21

Pour le warning ce n'est pas grave.

Si votre base est toujours en latin1 c'est que le seems_utf8 ne renvoie pas le bon resultat.

Essayer alors la deuxieme suggestion.

Netman · 2005-09-21 11:12:41

Hello,

Dans mon cas dans la base mysql, j'ai bien un probleme de charset car je suis en latin 1.
Si je liste par exemple un tracking que j'ai rentré avec un accent je vois bien:
"Portable prÃªt a Netman"

Mais l'application marche bien puisque ce tracking est correctement affiché dans glpi sans problème d'accent.
"Portable prêté a Netman"

Last edited by Netman (2005-09-21 11:13:10)

christophe · 2005-09-21 11:57:19

J'ai essayé la seconde chose, sans succès.

J'ai voulu reprendre le process compet (avec update_content modifié). Le problème est que la base est en prod, je ne peux donc pas repartir d'un update de la base d'avant-hier en 0.51a. Et un update sur une base 0.6 génère des erreur d'update (duplicate key).

La solution : j'ai fait un dump de la base existante et je l'ai mouliné par la commande :

iconv -f ISO-8859-1 -t UTF-8 -o glpi_utf8.sql 2005-09-21-11-05.sql

Puis j'ai réinjecté le dump. J'ai cependant eu un problème à la réinjection : une erreur sur la clé "comments" de la table infocoms. J'ai dû enlever la clé dans le fichier sql pour que l'import se fasse sans erreur. J'ai ensuite remis la clé manuellement depuis mysql.

Maintenant tout est nickel : toutes nos données sont en UTF-8.

Merci de votre aide, disponibilité et réactivité.

MoYo · 2005-09-21 11:59:25

ok merci pour l'info

aurelye · 2006-03-09 18:30:38

coucou
en fait g remarquer qu'il y avait un soucis de caractère en fesant la mise a jour de glpi. pour remédrier a tout cela g donc créer une nouvelle base de données vierge nommée glpi dans phpmyadmin, dans interclassement j'ai chosit utf8, apres j'ai fait l'import du fichier texte sql et juste en dessous ou c marquer jeu de caractère du fichier j'ai choisi latin .et depui plus aucun probleme de caractère pour passer d'une version de glpi a une autre.

FanckR. · 2006-09-29 17:08:14

J'ai eu un problème dans le même genre lors du passage de GLPI 0.65 ver 0.68.
Les textes étaient déjà en utf-8 sur une base mysql 3.xx qui était en iso8859-1

Pour GLPI0.68 j'ai dû passer en mysql 4.1 mais sur un autre serveur (pas de mysql 4.1 pour Woody)

mysql sur un serveur (Debian 3.1 - sarge) - mysql 4.1.xx
apache/php4 sur un autres serveur (Debian 3.0 - woody) - apache 1.3 et php 4.1.2

-dump de la base glpi-0.65 mysql3.23 (depuis le nouveau serveur )
-créé une nouvelle base glpi en indiquant utf-8 par défaut [utf8 comme character_set et utf8_general_ci pour collate] (je pensais que c'était une bonne idée)
-depuis phpMyAdmin sur le nouveau serveur, j'ai importé le dump (en indiquant que le fichier est en utf-8)
[Dans phpMyAdmin je vois les accents correctement.]
-Décompressé glpi 0.68, suppression de db_config.php
-Lancé glpi - L'upgrade s'effectue sans problème.

Mais en ouvrant une sassion dans GLPI, mes accents semblent doublement encodé!
[phpMyAdmin toujours OK - essai avec différents navigateurs et différents encodages de caractère du navigateur (le code source de la page envoie bien charset=utf-8 dans le header)]

Il me semble avoir réusi l'inverse également: accents OK dans GLPI 0.68 mais du coup plus dans phpMyAdmin (Je pense que c'est en créant la base en iso8859-1 comme default charset)

Ce que je souhaitais c'est tout avoir correctement (le beurre ... le lait de la crèmière .. ;-) )
Et j'ai trouvé comme solution d'ajouter dans inc/DBmysql.class.php
dans function DBmysql() ceci:

function DBmysql()
{ // Constructor
$this->dbh = @mysql_connect($this->dbhost, $this->dbuser, $this->dbpassword) or $this->error = 1;
if ($this->dbh) {
mysql_select_db($this->dbdefault) or $this->error = 1;
=========> mysql_query("SET NAMES 'utf8'",$this->dbh); <===================
}...
Et tout va bien!!
J'en suis venu à cette hypothèse après diverses recherches sur le site de mysqlAB et le web
Je pense que cela est dû à mon installation (mysql4.1 sur un serveur et php4 sur un autre serveur plus ancien )
[peut être une config à faire dans php.ini?? ]

Je ne pense pas que cela perturbe le reste du fonctionnement de la classe ???

Forum GLPI-Project

Announcement

#1 2005-09-20 09:38:29

passage UTF-8

#2 2005-09-20 09:47:32

Re: passage UTF-8

#3 2005-09-20 10:03:39

Re: passage UTF-8

#4 2005-09-20 10:44:48

Re: passage UTF-8

#5 2005-09-20 12:24:14

Re: passage UTF-8

#6 2005-09-20 12:42:27

Re: passage UTF-8

#7 2005-09-20 13:44:37

Re: passage UTF-8

#8 2005-09-20 16:15:13

Re: passage UTF-8

#9 2005-09-20 16:23:28

Re: passage UTF-8

#10 2005-09-20 16:28:44

Re: passage UTF-8

#11 2005-09-21 10:24:45

Re: passage UTF-8

#12 2005-09-21 11:07:21

Re: passage UTF-8

#13 2005-09-21 11:12:41

Re: passage UTF-8

#14 2005-09-21 11:57:19

Re: passage UTF-8

#15 2005-09-21 11:59:25

Re: passage UTF-8

#16 2006-03-09 18:30:38

Re: passage UTF-8

#17 2006-09-29 17:08:14

Re: passage UTF-8

Board footer