UTF8_decode() pour afficher de l'UTF8

Bonjour,

Configuration:
- l'encodage du coté serveur est en UTF8 (vérifié dans l'entête HTTP).
- l'encodage de ma base, de mes tables et de mes colonnes est en UTF8
- J'ai un mysql_query("set names utf8"); après chaque connexion à mes bases.
- J'ai <meta http-equiv="Content-type" content="text/html; charset=utf-8" /> sur toutes les pages du site.

back-office
-Mes articles sont copié d'une page facebook.
-Aucune fonction php n'est utilisée ni pour l'affichage ni pour le l'enregistrement dans ma BDD
- Tout est bien affiché, même après retour de mon enregistrement dans des textarea ou dans des <p>.

PhpMyAdmin
Les caractères spéciaux sont illisibles, ce qui ne les empêche pas d'être bien affiché dans le back-office du site.

front-office
-Impossible d'afficher les caractères spéciaux à moins d'utiliser utf8_decode() ce qui n'est pas logique vu que tout est configuré pour enregistrer et afficher de l'UTF8.
-Après utilisation de utf8_decode tous les caractères accentués sont bien affichés mais pas les "œ" de œuf par exemple et les apostrophes.
-Je repasse tout mon texte à la main dans le coté back-office, et les apostrophes s'affichent, mais pas les œufs.

navigateur
En définissant l'encodage du navigateur en UTF8 et sans utf8_decode() les caractères spéciaux sont illisibles.
En définissant l'encodage du navigateur en ISO (peut importe le quel) et sans utf8_decode() les caractères spéciaux sont illisibles.
Il faut une encodage en UTF8 et la fonction utf8_decode pour afficher les caractères accentués. mais pas les "œufs"

Je crois comprendre que le problème des apostrophes vient du copier coller, ça je peux gérer (ce qui le rend pas moins illogique pour moi vu que la réponse HTTP de facebook renvoie de l'UTF8)

Je pense être passé à coté de quelque chose, il doit y avoir une autre configuration à faire, pour boucler la chaine, il y a surement un maillon qui n'est pas en UTF8 mais le quel?

J'espère que que vous allez pouvoir m'aider, je dois livrer le site dans 2 jours
et merci d'avance pour vos contributions.

Salut,

Fais par étape :
- vérifie la valeur en bdd
- récupère la avec une page test, affiche la brut de pomme. Si c'est cassé, c'est probablement la liaison à la bdd.
- essaie aussi d'afficher depuis le php des valeurs accentuées

Hop je viens d'y penser : vérifie que ton fichier php est bien enregistré en utf-8.

Salut Marvin et merci pour ta réponse,
Je viens de comparer mes fichiers conf.inc.php dans le front et dans le back-office de mon site.
L'affichage se fait très bien dans le back, parce que mysql_query("set names utf8"); n'est pas exécutée.
En la retirant "mysql_query("set names utf8");" et "utf8_decode" de mon front-office, comme par magie tout s'affiche très bien.

Je ne comprends pas comment c'est possible, quand tout est encodé en utf8, je pensais qu'il fallait mettre mysql_query("set names utf8"); après chaque connexion.
Vous auriez une explication?

xelnegga a écrit :
PhpMyAdmin
Les caractères spéciaux sont illisibles, ce qui ne les empêche pas d'être bien affiché dans le back-office du site.

Une piste: phpMyAdmin configuré pour ouvrir une connexion MySQL en ISO-8859-1?

xelnegga a écrit :
front-office
-Impossible d'afficher les caractères spéciaux à moins d'utiliser utf8_decode() ce qui n'est pas logique vu que tout est configuré pour enregistrer et afficher de l'UTF8.

-Après utilisation de utf8_decode tous les caractères accentués sont bien affichés mais pas les &quot;œ&quot; de œuf par exemple et les apostrophes.
utf8_decode prend de l'UTF-8 et sort de l'ISO-8859-1. Je suppose donc que ta page HTML est affichée, pour une raison ou une autre, en ISO-8859-1. C'est cohérent avec ce que tu décris:
- quand tu sors de l'ISO-8859-1 avec utf8_decode, les caractères accentués s'affichent bien...
- sauf certains caractères comme "œ" qui existent en UTF-8 mais pas en ISO-8859-1 (tu pourrais tester aussi avec des points de suspension, des tirets cadratin, ou encore des caractères arabes ou chinois par exemple).

Donc pour une raison ou une autre tes pages sont interprétées par le (/les) navigateur(s) en ISO-8859-1. Ça pourrait être à cause d'une configuration de serveur web qui déclare de l'ISO-8859-1 pour toutes les pages de tous les sites, et qui ne laissent pas les configurations locales (.htaccess pour Apache) prendre le dessus, par exemple.

xelnegga a écrit :
En la retirant mysql_query("set names utf8"); et utf8_decode de mon front-office, comme par magie tout s'affiche très bien.

Tentative de diagnostic avec deux-trois suppositions:
1. Tes données sont en UTF-8 en base (données non corrompues et marquées comme étant en UTF-8).
2. Le serveur force une déclaration en ISO-8859-1 pour une raison ou une autre.
3. Par défaut, le serveur MySQL ouvre une connection en ISO-8859-1. Si tu retires ton SET NAMES, MySQL va donc convertir tes données UTF-8 vers ISO-8859-1 à la volée, et tu récupères donc du ISO-8859-1.
4. Ce contenu en ISO-8859-1 fourni par MySQL peut être affiché tel quel, sans utf8_decode.

xelnegga a écrit :
Configuration:
- l'encodage du coté serveur est en UTF8 (vérifié dans l'entête HTTP).

Tu es sûr de ce point? Si le serveur déclare de l'ISO-8859-1 ça explique tout le reste et tout se tient.

fvsch a écrit :

Tu es sûr de ce point? Si le serveur déclare de l'ISO-8859-1 ça explique tout le reste et tout se tient.

Je te remercie pour tes réponses fvsch,
pour répondre à ta question,
malheureusement oui, voici la réponse obtenue dans mon entête pour l'encodage: Content-Type: text/html; charset=UTF-8

j'ai mis l'encodage du navigateur à UTF8 pour m'assurer que c'est comme ça qu'il va m'afficher les données, et j'ai utilisé un de tes articles pour convertir ma bdd en UTF8 également, ainsi qu'une déclaration de l'UTF8 dans mon .htaccess.
Le problème vient apparemment du SET NAMES , qui devrait si j'ai bien compris indiquer que mes données sont en UTF8.
Tout s'affiche très bien quand je retire le SET NAMES.

Une hypothèse me vient à l’esprit (je ne sais sûrement pas de quoi je parle, mais je constate):
Si l'encodage à l'origine envoyé pendant l'enregistrement est en UTF8
Mais que le serveur lui convertit les données dans un autre encodage autre que UTF8 et autre que ISO-8859-1
Après appel des données:
- Si le requête SET_NAMES est appelée pour indiquer que les données sont en UTF8, alors qu'elles ne le sont pas, les navigateurs font mal la conversion puisque l'encodage indiqué n'est pas le bon.
- Si SET_NAMES n'est pas appelée, là le navigateur, cherche tout seul l'encodage des données fournie par le serveur et arrive tout seul à faire la conversion et à bien afficher le contenu en UTF8.

PS: je sais que le sujet est censé être clos, vu que le problème n'existe plus après avoir retiré SET_NAMES, mais si ça ne vous dérange pas on peut essayer de comprendre le comment.

Merci encore pour vos efforts et vos réponses.

xelnegga a écrit :

- Si le requête SET_NAMES est appelée pour indiquer que les données sont en UTF8, alors qu'elles ne le sont pas, les navigateurs font mal la conversion puisque l'encodage indiqué n'est pas le bon.
- Si SET_NAMES n'est pas appelée, là le navigateur, cherche tout seul l'encodage des données fournie par le serveur et arrive tout seul à faire la conversion et à bien afficher le contenu en UTF8.

Ça ne veut pas dire grand chose: le fait que tu configures ta connexion MySQL d'une manière ou d'une autre (en changeant la configuration de MySQL sur le serveur ou en utilisant une directive SET NAMES) n'a aucune incidence sur le comportement du navigateur. Ça peut par contre changer la nature des données que le navigateur reçoit.

On peut voir le site pour déjà diagnostiquer avec certitude ce qui se passe en front-end?
Il faudrait pouvoir déterminer très clairement quel est le codage des contenus envoyés par le serveur (et là je ne parle pas d'en-têtes HTTP, qui sont des métadonnées, mais du codage réel des caractères dans la réponse HTTP). Tu veux obtenir de l'UTF-8, donc déjà commencer par vérifier que c'est le cas.

xelnegga a écrit :

PS: je sais que le sujet est censé être clos, vu que le problème n'existe plus après avoir retiré SET_NAMES, mais si ça ne vous dérange pas on peut essayer de comprendre le comment.

Ça ne me dérange pas et c'est même l'approche que je conseille.
Si tu appliques une solution dont tu ne comprends pas les tenants et aboutissants, non seulement tu n'apprends pas grand chose mais en plus si un paramètre change la «solution» peut t'exploser à la figure.

fvsch a écrit :

On peut voir le site pour déjà diagnostiquer avec certitude ce qui se passe en front-end?
Il faudrait pouvoir déterminer très clairement quel est le codage des contenus envoyés par le serveur (et là je ne parle pas d'en-têtes HTTP, qui sont des métadonnées, mais du codage réel des caractères dans la réponse HTTP). Tu veux obtenir de l'UTF-8, donc déjà commencer par vérifier que c'est le cas.

La réponse HTTP justement donne du UTF8, je t'envoie l'adresse du site par MP, je fais un affichage en brut des données pour l'instant, mon PHP n'est pas encore sécurisé.