squalyl (./6) :
d'ailleurs le codage de la db est totalement inutile, code le en ce que tu veux, et php y stockera ce qu'il veut même si ça correspond pas a ce que t'as choisi.

Oui et non, c'est une solution très crade de contourner le problème. Bien sûr que si tu sauvegardes des données dans tes tables, au moment de la restitution MySQL te les donnera exactement telles que tu les as enregistrées, mais ça ne veut pas dire que c'est sans conséquence.

Il faut savoir que MySQL prend en compte l'encodage que tu as spécifié pour tes tables, par exemple pour savoir comment classer les textes quand tu lui demandes de les restituer par ordre alphabétique (pour reconnaitre un "à" et savoir comment le comparer à un "b", il faut déjà savoir comment il se code). Enfin plus exactement c'est l'interclassement qui détermine ça, mais ça va ensemble.

Quand tu communiques avec MySQL depuis ton code PHP, MySQL s'attend à recevoir des données dans un encodage bien précis (on va l'appeler "A"), et si ça n'est pas le même que celui de la table dans laquelle les données doivent être stockées (notons-le "B"), il va effectuer une conversion d'encodage A->B. Dans le sens inverse, quand tu récupères tes données, il effectue une conversion B->A et tu retrouves exactement ce que tu avais sauvegardé.

Tout ça ne marche donc que si tu connais "A" : si tu commences par injecter des données en UTF-8 dans les tables depuis X programmes différents alors que certains ne spécifient pas que "A" est de l'UTF-8 (j'imagine que phpMyAdmin fait les choses correctement, mais peut-être pas ton code), tu as toutes les chances de te retrouver avec de la bouillie dans tes tables. Si ton site est en UTF-8 et que tes tables également, il faut soit que tu changes la configuration de MySQL pour que l'encodage "A" soit par défaut de l'UTF-8, soit le déclarer dans ton programme juste après avoir effectué la connexion, avec la commande "SET NAMES 'UTF-8'".

Plus d'infos ici : http://dev.mysql.com/doc/refman/5.0/fr/charset-connection.html