Phpmyadmin et ses accents convertient...

Bonjour à tous,
bon je vous le dit tout de suite, je ne suis pas un expert dans le php

j'ai un petit soucis mais que plusieurs personnes ont également, j'ai même retrouvé un sujet qui parle de ce même problème mais la solution ne fonctionne pas pour moi.

je vous explique:
je suis actuellement entrain de faire la partie administrative de mon site avec des sections permettant d'ajouter du contenu et de modifier du contenu...
j'ai opté pour ajouter du contenu dans la base de donnée avec les balises html intégrée: <h1>Titre de la page</h1><p> Et voici son contenu</p>

j'utilise ces fonctions pour empêcher que les symboles < > soient traduits en code html par la bdd
mysql_real_escape_string(html_entity_decode(stripcslashes($_POST["contenu"])));

mais mon problème est que les accents ne sont pas prit en compte et lorsque le texte est envoyé à la base, phpmyadmin me traduit les accents par des codes comme ceux-là:
é - è - â€Ââ

Quelqu'un a-t-il une solution ?

ps: je n'ai pas de problème d'affichage d'accents quand je tape moi même les accents dans la base...
j'utilise echo utf8_encode et tous les caractères s'affichent correctement en presque sauf les accents qui sont traduits par ses codes bizarres...
j'ai oublié également de préciser que les symbole comme le "ç" sont également traduit en code.

Bonjour,

Pour commencer, je ne vois pas trop pourquoi tu aurais besoin de faire un html_entity_decode. Quand j'envoie un formulaire en POST avec "test <lol>" comme contenu, j'obtiens exactement "test <lol>" (en fait, l'information envoyée est "test+%3Clol%3E", mais si tu utilises $_POST en PHP il devrait traduire directement en "test <lol>"). Donc si tu es obligé de décoder des entités HTML telles que &lt; et &gt; pour obtenir à nouveau < et >, c'est que tu encodes l'information en amont, et c'est à corriger.
(Je dis ça, mais je ne connais pas grand chose à PHP, donc il y a peut-être des caractéristiques de ce langage que j'ignore...)

Ensuite, si tu travailles en UTF-8 de bout en bout, tu n'as pas besoin de faire des utf8_encode et autres conversions. La marche à suivre serait donc de faire un site déclaré en UTF-8, de stocker de l'UTF-8 en base de données, et de ne pas chercher à transcoder les données à quelque moment que ce soit.
Pour éviter que MySQL ne transcode automatiquement les données, il faut s'assurer que les champs de la base sont bien marqués comme étant en UTF-8 (avec un interclassement tel que utf8_unicode_ci ou ut8_general_ci), et que la connexion entre le site et la base de données se fait bien en UTF-8 (soit en configurant le serveur MySQL, soit en utilisant SET NAMES lorsque tu ouvres ta connexion MySQL).

Enfin, ne pas se fier au rendu de phpMyAdmin, qui n'est pas fiable, notamment parce que l'on ne contrôle pas forcément le codage de caractères utilisé pour la connexion entre phpMyAdmin et le serveur MySQL.

Florent V. a écrit :
(...)
Enfin, ne pas se fier au rendu de phpMyAdmin, qui n'est pas fiable, notamment parce que l'on ne contrôle pas forcément le codage de caractères utilisé pour la connexion entre phpMyAdmin et le serveur MySQL.

Re-bonjour Florent,

Ceci expliquerait que malgré tous mes headers, htaccess, SET CHARACTER SET utf8, SET NAMES utf8 (array(PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8") )... ...
- quand j'entre manuellement "é" dans phpMyAdmin, sur mon site il s'affiche "é"
- quand je poste "é" depuis mon site, dans phpMyAdmin il s'affiche "&eacute;"
- quand j'appelle ce "&eacute;" sur une page de mon site, il s'affiche "é" !
...ceci garanti 100% SANS utf8_encode ni utf8_decode.

Pas extrêmement gênant à mon niveau, si ce n'est pour éditer dans phpMyAdmin.

Pas l'air simple cette question, mon pauvre Abitbol !
Modifié par Zoliv (17 Nov 2010 - 16:20)

Zoliv a écrit :
- quand j'entre manuellement &quot;é&quot; dans phpMyAdmin, sur mon site il s'affiche &quot;é&quot;
- quand je poste &quot;é&quot; depuis mon site, dans phpMyAdmin il s'affiche &quot;&amp;eacute;&quot;

Dans ce cas c'est ton site qui transforme les caractères qui reçoit. Pas la faute à phpMyAdmin.
Si c'est un site PHP, il y a sans doute une fonction htmlentities() utilisée quelque part.
Ou bien le site utilise un éditeur de texte JavaScript tel que TinyMCE, CKEditor ou autre, et l'option "transformer en entités HTML" est activée par défaut.

Florent V. a écrit :

Dans ce cas c'est ton site qui transforme les caractères qui reçoit. Pas la faute à phpMyAdmin.
Si c'est un site PHP, il y a sans doute une fonction htmlentities() utilisée quelque part.
Ou bien le site utilise un éditeur de texte JavaScript tel que TinyMCE, CKEditor ou autre, et l'option &quot;transformer en entités HTML&quot; est activée par défaut.

Bonsoir,
Merci pour ta réponse, que je n'attendais pas (car je n'avais pas vraiment formulé de question).
TinyMCE et CKEditor virés, reste effectivement un htmlentities($vars, ENT_QUOTES, "UTF-8"). Je le croyais bien paramétré.

Le sujet de l'encodage est si "tordu" pour un non-initié que malgré ce genre d'article :
http://www.coinduwebmaster.com/convertir-site-web-utf8/491/
je ne parviens pas à mes fins... Vivement une prochaine version de php !
Bonne soirée.
Zoliv.

PS : passé le plaisir de trouver tant d'aide bénévole -souvent de qualité- le suis intrigué : comment faites-vous pour trouver le temps et la motivation ? Certains -comme vous- persistent à aider la foule des débutants (ou parfois fainéants ?) au fil des années...
Ça m'intrigue mais finalement, ça ne me regarde pas !!!

Zoliv a écrit :
reste effectivement un htmlentities($vars, ENT_QUOTES, "UTF-8"). Je le croyais bien paramétré

Tu passes les bons paramètres à la fonction. Tu lui dis que ta chaine de caractères ($vars) est en UTF-8, information dont elle a besoin pour travailler. Par contre, ça reste un appel à une fonction dont le but est de convertir des caractères naturels (é, ÿ...) en entités HTML (&eacute;, &yuml;...). Si tu ne veux pas faire ce type de conversion, il ne faut pas utiliser la fonction htmlentities du tout.

(Ou alors j'ai mal lu ta réponse. J'enfonce peut-être des portes ouvertes, là.)

Zoliv a écrit :
Le sujet de l'encodage est si "tordu" pour un non-initié

Il n'est pas tordu car c'est très logique. Ça demande juste d'être rigoureux.
Les principaux problèmes qu'on rencontre sont:
- On ne sait pas ce qu'est un «caractère» en informatique ou ce qu'est vraiment un codage de caractères. C'est le cas d'énormément de monde, y compris une majorité des développeurs web! Pour ma part une des premières choses que j'ai découvert en informatique c'est le binaire, la notation hexadécimal, et comment jouer avec des fichiers en hexadécimal... ça aide à comprendre.
- Les articles qu'on trouve sur le sujet ne dissipent pas toujours les malentendus courants, ne vont pas assez loin sur les fondements du problème (voir le point ci-dessus ) afin de rester accessibles. Du coup on n'a qu'une compréhension partielle et parfois erronée du sujet.
- Les outils et langages informatiques font parfois de la «magie» avec les codages de caractères, sans que ça soit bien clair pour les utilisateurs. MySQL, par défaut, fait des conversions à la volée quand tu demandes des données dans un premier codage et qu'il pense que les données en base sont dans un codage différent. Certains CMS utilisent allègrement htmlentities sans que ça soit documenté... ce genre de choses.
- Le succès actuel de UTF-8 simplifie grandement les choses, mais pour que ça marche bien (comme avec tout autre codage...) il faut que toute la chaine technique soit en UTF-8. On est encore dans une phase de transition, même si on arrive à la fin et que mettre de l'UTF-8 partout est de plus en plus simple.

Merci beaucoup Florent,

Après une pause... je recommence à piocher. Après tout, Georges Abitbol lui-même doit bien se reposer, parfois ?
Je ne vais bientôt plus pouvoir communiquer avec mes semblables si j'émaille mon vocabulaire de "utf-8", "hexadécimal" et autres onomatopées peu poétiques. On me dira que c'est du vol et du plagiat... j'aime pas trop les voleurs, et les fils de p...

Alors, un peu de rigueur,
si vous le dites, Monseigneur.