Accents non reconnu par MYSQL

Support Debian
#1

Bonjour à vous,

Voilà j’ai un autre petit soucis et je viens voir si vous pouviez me dépanner à nouveau big_smile

Cette fois il s’agit d’un problème de caractères par rapport à MYSQL, je m’explique :

Les résultats des mes requêtes mysql ne s’affichent pas correctement, les accents sont remplacés par des é.
De plus si j’ai effectue une requête qui comporte un accent ( ex : SELECT * FROM Jeux_abandonware WHERE Licencié = ‘Non’ ), celle-ci ne marche pas.

J’ai essayé de régler mon php.ini, apche2.conf en UTF-8 ou en ISO-8859-1 mais rien ne change. Pareil pour mes BDD, j’ai essayé latin_general_ci ou utf8_xxx_xx, aucun ne marche et rien ne change non plus.

Auriez-vous une idée sur ce que je pourrai essayer ?

Merci

Des ptits bouts de config :

apache2.conf

php.ini

phpmyadmin

Je sais vraiment plus quoi faire :’( Merci pour votre aide.

#2

tu as ce probleme lorsque tu importes une base de données dans mysql ?
dans ce cas :–default-character-set=utf8
exemple:
mysql --default-character-set=utf8 -u root -p nom-bbd < chemin de ton import/sql.sql

#3

Salut et merci pour ta réponse.

Oui en effet c’est quand j’importe une BDD, sauf que celle-ci étant trop volumineuse je passe directement dans SQL pour ajouter petit à petit ma BDD.

Je n’ai jamais utilisé ce type de fonction, je vais placé ma .sql import dans un répertoire et essayer cela. Je reviens te dire ce qu’il en est juste après.

#4

Re,

J’ai donc fait ce que tu ma dit mais le problème reste le même.

Peut-être il y a t’il un problème dans la façon d’importer ma BDD, je vais donc te résumer ce que je fait.

  1. Je me connecte à phpmyadmin de mon hébergeur actuel et j’importe ma base de donnée dans un fichier .sql sur mon ordi.
    Voici par quoi il commence :
  1. J’envoie le fichier .sql dans un répertoire de mon serv.
  2. Je fait la fonction que tu ma dit :
  1. Ma BDD est correctement importé sur mon serv, je vais sur la page index du serv et la j’ai toujours les é à la place des accents.
#5

bonjour,
c’est souvent pénible les problèmes d’encodage … d’abord je vois trois choses à distinguer:

  • l’encodage de ta base, de tes tables, à leur création et actuellement
  • l’encodage dans ta config php.ini apache etc…
  • l’encodage dans la config de l’outil avec lequel tu lis les résultats.

Comme il y a déjà assez de problème avec l’encodage sans en rajouter, je te suggère de faire en sorte que ces trois points soit cohérent, et pas 2 en utf-8 et 1 en ISO, comme j’ai pu le constater.

parenthèse:
Il y a un autre point, c’est l’encodage d’un éventuel fichier source. Imagine que tu as un export de db dans un fichier quelconque, avec des accents, qui parce que tu n’avais pas les choses correctement configurées, ne c’est pas exporté correctement mais avec des caractères mal retranscrits et bizarroïdes ? c’est encore un point à vérifier si tu utilises un tel fichier.

Bon, pour mettre une config cohérente en utf8:
http://blog.neovov.com/index.php?2007/03/06/143-convertir-un-site-en-utf-8
vivement php6 avec utf-8 intégré !
Note l’astuce ‘set names utf8’ quand tu initialises la connexion à la base.

La conversion en utf8 demande un peu de patience, et de boulot, car les choses ne se mettent pas en place aussi vite qu’on voudrait, mais bon, une fois que c’est fait …
Donc soit tu restes en ISO, soit tu passes tout en UTF8, mais entre les deux, ya pas. et oui, l’informatique, c’est manichéen.

#6

Salut,

Merci pour ta réponse. En effet les problèmes d’encodage c’est vraiment chiant… :imp:

J’avais déjà suivi le tuto du lien que tu m’a envoyé mais sans connaître l’astuce du UTF-8 à la création de la BDD, je vais donc réessayer avec.

Pour mon import, il n’y a pas de soucis, les accents et autres caractères sont tous correctement retranscrient. Le problème vient réellement de l’affichage de ces BDD sur les pages du serv. Et bien uniquement de mysql puisque j’ai réglé le problème des accents pour les textes hml par exemple.

Je vais donc encore magouiller, mais ca me rend vraiment dingue :smiley: Surtout que dans tout ce que je change je ne constage AUCUN changement :frowning: Ca c’est encore plus chiant car cela ne laisse même pas l’ombre d’une piste.

En tout cas merci ! :smt006

#7

non non, laisse moi préciser:
Par exemple j’ai deux problèmes avec l’encodage, dont un que je ne peux résoudre sans cette petite astuce.

  • partant du principe qu’on a tout mis bien comme il faut en utf8, mysql, la table qu’on utilise(charset et collation), apache (accessoire), php5. Si on fait un tour dans les variables serveur(mysql) dans l’interface phpmyadmin au moment où on utilise une table(affichage), on s’aperçoit que c’est ok, mais que la valeur globale est toujours latin1, alors je sais pas si ça joue pour ce qui va suivre, mais on ne peut pas changer cette valeur globale sans recompiler(voir doc mysql). j’ai pas envie de recompiler, et pas sur que ça joue.
    Toujours est-il que si je met un “à” dans un champ tinytext(assimilé blob),
    il s’affiche bien dans phpmyadmin, mais sur ma page web il sort en ISO (incompréhensible) et donc il fait tâche, parce que mon nav lit en utf8.
    Je suis donc obligé avant de faire un select par exemple, tout du moins juste après la création d’une connection, de faire un :

pour qu’après je n’ai plus de soucis avec l’affichage de mes résultats.
Donc ma précision, c’est que cette requête n’a rien à voir avec la création de la base ou de la table (sous entendu si tu veux de l’utf8, tu mets du ‘CHARSET=utf8’ (table, base) et éventuellement des ‘character set utf8 collate’ utf8_bin_ou_general_ci sur les champs.

Bon alors je sais pas pourquoi j’arrive pas à faire afficher ce “à” comme je veux mais je pense que ça peut venir de la compile mysql et php, car avant j’avais pas ce problème en passant tout en utf8 avec un php5 et un mysqld compiler par mes soins(et je me souviens plus si j’avais changer les valeurs globales dîtes plus haut), et en testing ou unstable.

En tout cas, les changements dans php.ini concernant le charset sont pris en compte sans redémarrer quoique ce soit. Étonnant que tu n’aies pas vu de changement.

  • autre problème, le fait de passer mbstring.func_overload=7 (tant qu’à faire !) pose un problème avec phpmyadmin, qui affiche des warnings à tout va, ligne 1367 d’une de ces libs d’affichage des résultats. :frowning:
    parenthèse: peut-être un lien avec ce qui est dit sur les librairies portables et mbstring.encoding_translation(cf. doc mysql).
    car mbstring se substitue à toute les fonctions de chaines ici, et phpmyadmin doit passer à sa fonction (str_replace je crois, du coup relayée par mb_replace un truc du style) un paramètre mal digéré par mbstring !
    ça doit pouvoir se résoudre sans désactiver les warnings, d’autant que sur la page web d’un site, aucun warning, puisque plus rien à voir avec phpmyadmin.

Donc je dis, tant qu’on veut pas afficher du Japonnais, c’est peut-être mieux de pas se lancer dans les galères de l’utf8 pourtant l’avenir, du moins pas tant que php6 est pas dans les bacs.

#8

Merci beaucoup pour ton aide. Je vais encore une fois essayer. Je viendrai donner des nouvelles un peu plus tard :smt006

#9

C’est plutôt marrant, j’arrive à afficher maintenant les accents des requêtes de BDD. J’ai donc tout positionné en UTF8. Mais ce qui est drôle c’est que maintenant ce sont les accents de mes textes qui ne passent pas lol :smt005

Ils sont tranformé en �, et ce malgrè un meta.

Si je résume la situation en faite soit :

  • mes données BDD sont en UTF-8 et le navigateur les affiche en ISO mais les données hors BDD sont encodées et affichées en ISO
  • mes données BDD sont encodées et affichées en UTF-8 mais les données hors BDD sont encodées en ISO mais le navigateur les affichent en UTF-8

Donnez moi une corde que je me pende lol

Par contre j’ai essayé de faire la même méthode que pour UTF8 mais en ISO, tout est bien converti mais le problème reste le même, les accents BDD ne passent pas.