Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1879 connectés 

  FORUM HardWare.fr
  Programmation
  PHP

  Charset modifié entre Mysql et mes pages web

 



 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

Charset modifié entre Mysql et mes pages web

n°2055320
rufo
Pas me confondre avec Lycos!
Posté le 09-02-2011 à 12:00:40  profilanswer
 

Bonjour à tous,
 
Je connais pourtant la plupart des sources de pb de charset dans les applis web qui exploitent une BD Mysql, mais là, je sèche (même si j'ai qq soupçons).
 
J'ai une BD qui est en charset et collation latin1 (iso-8859-1). J'ai essayé différentes méthodes d'import, ça a l'air bon de ce côté là. Côté site web, tout ce qui provient de fichiers de langues s'affichent san pb en iso-8859-1 (charset défini dans le header des pages web). Mais les données provenant directement de la base s'affichent mal (pb de charset sur les accents et autres caractères spéciaux). Le fichier de conf de mysql a été modifié pour prendre de base latin1 (collation, connexion, client, serveur) mais ça ne change rien. Alors je me dis que le charset doit probablement être modifié par qq chose entre la sortie des données de mysql et l'affichage dans les pages web. Est-ce que ça pourrait venir de la conf d'apache ou du charset du serveur lui-même :??:


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Cantine Calandreta : http://sourceforge.net/projects/canteen-calandreta
mood
Publicité
Posté le 09-02-2011 à 12:00:40  profilanswer
 

n°2055333
smaragdus
whores, drugs & J.S. Bach
Posté le 09-02-2011 à 12:34:56  profilanswer
 

Comment les données s'affichent mal ?
 
Tu as genre un Ä(c) à la place d'un "é" ou  plutôt un losange avec un point d'interrogation ?

n°2055371
rufo
Pas me confondre avec Lycos!
Posté le 09-02-2011 à 14:16:00  profilanswer
 

Ä(c) à la place du é mais uniquement pour ce qui vient de la BD. Par ailleurs, dans phpmyadmin, les données sont affichées correctement : or, le charset des champs texte est bien latin1_swedish_ci. Pourtant, à partir de phpmyadmin, si j'ajoute une donnée dans un champ texte, elle s'affiche correctement dans phpmyadmin mais pas dans l'appli web. Si j'ajoute une donnée dans la base depuis l'applis web, celle-ci ne s'affiche pas correctement dans phpmyadmin ni quand je la réaffiche dans l'appli web.
C'est pour ça que je pense que ça vient d'un "truc" entre l'appli web et mysql et je pencherai pour apache.


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Cantine Calandreta : http://sourceforge.net/projects/canteen-calandreta
n°2055389
smaragdus
whores, drugs & J.S. Bach
Posté le 09-02-2011 à 14:30:54  profilanswer
 

si ça affiche 2 char, c'est que ta base est en UTF8 (2 à 4 octets par caractère) et que tu affiches ta page en ISO (1char = 1 octet)
 
Convertit ta base en ISO ou bien convertit à la volée (sale)
 

n°2055686
rufo
Pas me confondre avec Lycos!
Posté le 10-02-2011 à 09:57:36  profilanswer
 

smaragdus a écrit :

si ça affiche 2 char, c'est que ta base est en UTF8 (2 à 4 octets par caractère) et que tu affiches ta page en ISO (1char = 1 octet)
 
Convertit ta base en ISO ou bien convertit à la volée (sale)
 


 
Je suis pas très convaincu que mon pb vient de Mysql. Le fichier sql qui contient la base à importer (fichier dont le contenu provient d'une BD Mysql en Iso-889-1 qui fonctionne bien) est bien en iso-8859-1 : quand je l'ouvre avec le bloc-note de windows ou Wordpad, les caractères accentués sont correctement affichés. Quand j'importe ce fichier sql dans ma nouvelle base, les caractères accentués s'affichent bien dans phpmyadmin. Si l'import avait été réalisé avec un charset en utf-8, les données en entrée étant en iso, elles s'afficheraient donc mal dans phpmyadmin. Or, ce n'est pas le cas...
Le charset que j'ai mis à la création de la BD est bien iso-8859-1 et c'est aussi le charset de tous les champs txt de la base. L'import se passe bien donc c'est ce qui m'amène à penser que mon pb ne vient pas de Mysql mais d'ailleurs : le charset d'apache. En effet, celui d'apache, par défaut est utf-8.


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Cantine Calandreta : http://sourceforge.net/projects/canteen-calandreta
n°2055691
smaragdus
whores, drugs & J.S. Bach
Posté le 10-02-2011 à 10:23:35  profilanswer
 

Un peu de logique voyons : si le charset de apache était en cause, c'est tous les char accentués qui seraient impactés.
 
Quant à phpmyadmin, je vais éviter d'en parler avant de devenir grossier...


Message édité par smaragdus le 10-02-2011 à 10:24:06
n°2055788
rufo
Pas me confondre avec Lycos!
Posté le 10-02-2011 à 13:38:28  profilanswer
 

Je veux bien reconnaître que mon idée est tirée par les cheveux mais je n'arrive pas à trouver la source de mon pb. Pour comprendre, voici qq détails supplémentaires. En fait, je déplace une appli web d'un serveur A (une machine physique) vers un serveur B (une machine virtuelle). Sur le serveur A, ça a toujours fonctionné correctement.
 
Bon, l'export de ma BD, je l'ai fait avec mysqldump avec la même ligne de commande que j'utilise depuis des années pour ce genre d'opération sur cette BD (sans jamais avoir eu de pbs). Donc, je peux dire à coup sûr que mon export est OK.
 
L'import, je l'ai fait via phpmyadmin de différentes façon : dans phpmyadmin, ça s'affiche correct mais pas dans mon appli web placée sur le nouveau serveur (serveur B). Comme selon toi, phpmyadmin c'est pas bien (perso, il m'a toujours donné satisfaction, mais bon, j'ai un pb donc faut envisager toutes les solutions), j'ai réalisé mon import d'abord via le client lourd Mysql Administrator (sous Windows) puis directe sur le serveur B via le binaire mysql (en ligne de commande, donc) : mysql --default-character-set=utf8 base_de_donnees -h host -u user -ppass < fichier_dump
 
J'ai essayé avec latin1 à la place d'utf8, j'ai le même résultat (ce qui du reste, est bizarre). Du coup, je ne vois pas où est ma source d'erreur.
Côté variables de conf de mysql, voilà ce que j'ai concernant les charset (les mêmes valeurs que sur mon serveur A du reste) :
 
character set client   utf8
(Valeur globale)  latin1
character set connection  utf8
(Valeur globale)  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  utf8_unicode_ci
(Valeur globale)  latin1_swedish_ci
collation database  latin1_swedish_ci
collation server  latin1_swedish_ci
 
La seule différence que j'ai trouvée concernant les charset entre le serveur A et B, c'est la variable d'environnement LANG qui est à fr_FR sur le serveur A et à fr_FR.UTF-8 sur le serveur B. N'étant pas un spécialiste de l'admin système, j'ignore si ça peut avoir un rapport avec mon pb. Du coup, j'en suis réduit à chercher les différences entre les 2 machines à l'aide des données que m'affichent phpmyadmin et les valeurs des variables du my.cnf et les infos renvoyées par phpinfo() :/
(précision, je suis pas admin des serveurs, donc peux pas faire des tests facilement)...


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Cantine Calandreta : http://sourceforge.net/projects/canteen-calandreta
n°2055789
esox_ch
Posté le 10-02-2011 à 13:45:58  profilanswer
 

Ah mais je pense que tu as mis le doigt dessus justement. La variable LANG va définir le charset utilisé par ton shell. Donc à mon avis c'est justement là que le bas blesse!


---------------
Si la vérité est découverte par quelqu'un d'autre,elle perd toujours un peu d'attrait
n°2055795
rufo
Pas me confondre avec Lycos!
Posté le 10-02-2011 à 13:52:45  profilanswer
 

esox_ch a écrit :

Ah mais je pense que tu as mis le doigt dessus justement. La variable LANG va définir le charset utilisé par ton shell. Donc à mon avis c'est justement là que le bas blesse!


 
Dans la mesure où c'est la seule différence, ça pourrait être ça. Cela dit, autant je comprends que la langue du shell puisse avoir un impact quand je fais mon import en ligne de commande avec le binaire mysql, autant je le vois moins avec un import réalisé avec un client lourd sur un poste distant (mon poste bureautique sous Windows xp) ou via phpmyadmin :/


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Cantine Calandreta : http://sourceforge.net/projects/canteen-calandreta
n°2055916
Bloubinouc​hko
Posté le 10-02-2011 à 18:28:12  profilanswer
 

Je vérifie les 3 points suivants lorsque j'ai un problème d'encodage :

  • Le charset de la table
  • Le charset du client MySQL
  • Le charset HTML


Celui qu'on peut oublier et qui peut poser problème, c'est le charset du client MySQL.
Si la table est en Latin1 mais qu'on se connecte en client UTF8, MySQL va envoyer les données en convertissant l'encodage de manière à pouvoir les lire correctement.
 
D'ailleurs dans ton cas tu as "character set client utf8".
Tu es peut-être dans le cas où Table Latin 1 -> Client UTF8 -> Affichage Latin 1 alors qu'il faudrait Table Latin1 -> Client Latin1 -> Affichage Latin1
 
Le cas est évoqué pour une connexion avec PDO dans la doc PHP :
http://www.php.net/manual/fr/pdo.connections.php

In order to set the encoding of the database connection, use the exec function:
<?php
try {
    $dbh = new PDO('mysql:host=localhost;dbname=test', $user, $pass);
    $dbh->exec("SET CHARACTER SET utf8" );
    $dbh = null;
} catch (PDOException $e) {
    print "Error!: " . $e->getMessage() . "<br/>";
    die();
}
?>


En espérant que ça puisse aider !


Message édité par Bloubinouchko le 10-02-2011 à 18:31:13
mood
Publicité
Posté le 10-02-2011 à 18:28:12  profilanswer
 

n°2055996
rufo
Pas me confondre avec Lycos!
Posté le 11-02-2011 à 10:07:40  profilanswer
 

Merci pour ta réponse. Concernant le charset de connexion du client ça pourrait être ça, cela dit, phpmyadmin m'affiche l'info suivante pour cette variable :
character set client   utf8
(Valeur globale)  latin1  
 
Mon interprétation de ça est que le charset client de la connexion en cours est en utf8 mais que la variable globale charset client est en latin1 et que donc, ça devrait prendre le pas sur la connexion client en cours, non?


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Cantine Calandreta : http://sourceforge.net/projects/canteen-calandreta
n°2056028
rufo
Pas me confondre avec Lycos!
Posté le 11-02-2011 à 11:24:20  profilanswer
 

Bon, j'ai fini par trouver une solution qui marche. Au moment de la création de la connexion, je lui fait exécuter derrière la requête SQL :
SET CHARACTER SET latin1;
 
Et ça marche :)
 
On regardant sur la doc de mysql, j'ai vu quelles variables d'environnements étaient impactées par cette requête, du coup, j'ai demandé à mon admin sys de faire les modifs du fichier de conf de mysql. Merci de votre aide :)


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Cantine Calandreta : http://sourceforge.net/projects/canteen-calandreta
n°2056033
esox_ch
Posté le 11-02-2011 à 11:36:13  profilanswer
 

Et c'est là que tous les autres utilisateurs du serveur se ramassent le problème dans l'autre sens :D


---------------
Si la vérité est découverte par quelqu'un d'autre,elle perd toujours un peu d'attrait
n°2056123
rufo
Pas me confondre avec Lycos!
Posté le 11-02-2011 à 14:59:04  profilanswer
 

esox_ch a écrit :

Et c'est là que tous les autres utilisateurs du serveur se ramassent le problème dans l'autre sens :D


 
serveur (en fait une machine virtuelle) dédié pour mon appli, donc pas de pb :) Et puis cette manip n'affecte que ma connexion (session), pas la conf globale du serveur. Donc ça reste local à ma connexion et à mon appli web...


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Cantine Calandreta : http://sourceforge.net/projects/canteen-calandreta

Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  PHP

  Charset modifié entre Mysql et mes pages web

 

Sujets relatifs
Parser un fichier BibTex pour l'insérer dans une bdd MySQLRécupération de donénes mysql après upgrade
[RESOLU] [MySQL] Jointures sur 3 tablesMysql 5/SQLServer - Cherche grosse base de données
[archi mysql] splitter ou non des tables pour gagner en perf ?[mySql] Probleme cle etrangere sur deux primary key
[PHP/MySQL] Recherches bénévoles[PHP - MySQL] : Access denied for user 'user00329'@'%' to database 'db
optimisation de connexion php mysqlMYSQL : Problème pour retrouver la clé primaire dans les metadatas
Plus de sujets relatifs à : Charset modifié entre Mysql et mes pages web


Copyright © 1997-2018 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR