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

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 ?

Ä(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.

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.

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...

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)...

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

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

En espérant que ça puisse aider !

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?

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

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

 
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...