Problème incompréhensible avec htmlentities et UTF-8

Problème incompréhensible avec htmlentities et UTF-8 - PHP - Programmation

Marsh Posté le 23-01-2013 à 00:23:29    

Yopla,
 
J'ai un problème qui dépasse ma compréhension avec htmlentities et UTF-8.
 
- Je suis sous PHP 5.4.11
- J'ai une table MySQL avec un interclassement "utf8_general_ci" contenant une colonne TEXT avec un interclassement "utf8_general_ci", elle contient des caractères accentués français.  
- Ma page HTML a un meta spécifiant UTF-8,
- quand j'utilise htmlentities je spécifie le charset UTF-8
 
Bref je suis UTF-8 du sol au plafond.
 
Pourtant, htmlentities s'acharne à ne pas comprendre mes données contenant éàèù etc, et à me retourner une string vide ou des caractères pourris selon que j'utilise les flags ENT_SUBSTITUTE, ENT_IGNORE etc etc (par exemple en ENT_SUBSTITUTE un "é" est rendu comme "�" )
 
Comment se fait-il que htmlentities bute sur de bêtes accents qui devraient passer sans problème ?


Message édité par Gonzoide le 23-01-2013 à 00:24:25
Reply

Marsh Posté le 23-01-2013 à 00:23:29   

Reply

Marsh Posté le 23-01-2013 à 09:43:21    

Citation :

Bref je suis UTF-8 du sol au plafond.


En es-tu si sûr?
As-tu vérifié le charset par défaut d'apache?
As-tu vérifié le charset des variables suivantes de la conf de mysql :
* character set client (la globale et la locale)
* character set connection (la globale et la locale)
* character set database  
* character set results (la globale et la locale)
* character set server  
* character set system
* character sets dir
* collation connection (la globale et la locale)
* collation database
* collation server
Dans le tas, y'en aurait pas une ou 2 qui seraient en latin1 ?
 
Passes-tu, à un moment donné pour générer ton html, par du XML voire du XSL? Si oui, as-tu bien spécifié le charset utf-8. Et la lib faisant la transfo XSLT gère t-elle bien l'utf-8?  Si tu fais du ajax et que t'envoies du texte, spécifies-tu bien le charset utf-8?


Message édité par rufo le 23-01-2013 à 09:45:50

---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Planeta Calandreta : https://framalibre.org/content/planeta-calandreta
Reply

Marsh Posté le 23-01-2013 à 10:41:23    

Bonjour,
En faite, si je comprends bien, au moment d'insérer une nouvelle entrée dans votre base de données, les accents ne sont pas codés?


---------------
Besoin d'aide pour votre projet? agence web
Reply

Marsh Posté le 23-01-2013 à 10:51:57    

Ben ça doit être un truc dans le genre, mais je ne comprends pas comment ça peut être le cas ... sachant que si ma colonne est en UTF-8 elle ne devrait contenir que des entrées en UTF-8, non ? Si j'affiche la donnée sans aucune preécaution, elle s'affiche correctement  :??:
 
Quoi qu'il en soit, effectivement quand htmlentities récupère une entrée directement depuis lq bqse, elle ne considère pas ce que je vois en "é" comme un caractère UTF-8 valide :??:


Message édité par Gonzoide le 23-01-2013 à 10:53:17
Reply

Marsh Posté le 23-01-2013 à 11:26:07    

Lors de la connexion à la base de données, utilises tu un petit SET NAMES UTF-8 pour que tout passe bien en UTF ?


---------------
Main/Alt1/Alt2/Alt3
Reply

Marsh Posté le 23-01-2013 à 11:31:42    

Ben non, je pensais que définir base de données, table et colonne en UTF-8 était suffisant pour qu'au final toute entrée que j'insère se retrouve au bon endroid en UTF-8 :/

Reply

Marsh Posté le 23-01-2013 à 11:43:26    

tsoko a écrit :

Bonjour,
En faite, si je comprends bien, au moment d'insérer une nouvelle entrée dans votre base de données, les accents ne sont pas codés?


J'avais plutôt compris l'inverse : en base, c'est bon, c'est quand il tente de réafficher sur sa page web que ça merdouille... Mais j'ai peut-être mal compris ou supposer qu'en BD, c'était bon.


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Planeta Calandreta : https://framalibre.org/content/planeta-calandreta
Reply

Marsh Posté le 23-01-2013 à 11:44:13    

Gonzoide a écrit :

Ben non, je pensais que définir base de données, table et colonne en UTF-8 était suffisant pour qu'au final toute entrée que j'insère se retrouve au bon endroid en UTF-8 :/


Je te recommande aussi de faire SET NAMES UTF-8 après la création de la connexion à la BD. Ca évite de batailler avec le fichier de conf de mysql. :/


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Planeta Calandreta : https://framalibre.org/content/planeta-calandreta
Reply

Marsh Posté le 23-01-2013 à 12:32:53    

rufo a écrit :


J'avais plutôt compris l'inverse : en base, c'est bon, c'est quand il tente de réafficher sur sa page web que ça merdouille... Mais j'ai peut-être mal compris ou supposer qu'en BD, c'était bon.


 
Ben en fait j'en sais rien : dans PHPMyAdmin ou quand je lis les données sans les tranformer, les lettres accentuées apparaissent correctement, ce qui ne veut pas forcément dire que c'est bon  [:spamafote]  
 
J'aurais tendance à dire que, puisque htmlentities(xxx,yyy, 'UTF-8') ne reconnaît pas un caractère accentué c'est qu'il n'est pas UTF-8 du tout, mais je vois pas comment c'est possible puisque j'imaginais qu'une table et une colonne UTF-8 suffisait à garantir ça :??:
 
Maintenant, y a-t-il un moyen indiscutable pour déterminer la nature de ce que j'ai dans ma base ?
 
@volken : je vais tenter ça, mais est-ce que ça va améliorer l'insertion ou la récupération des données ?

Reply

Marsh Posté le 23-01-2013 à 13:25:12    

Gonzoide a écrit :


 
Ben en fait j'en sais rien : dans PHPMyAdmin ou quand je lis les données sans les tranformer, les lettres accentuées apparaissent correctement, ce qui ne veut pas forcément dire que c'est bon  [:spamafote]  
 
J'aurais tendance à dire que, puisque htmlentities(xxx,yyy, 'UTF-8') ne reconnaît pas un caractère accentué c'est qu'il n'est pas UTF-8 du tout, mais je vois pas comment c'est possible puisque j'imaginais qu'une table et une colonne UTF-8 suffisait à garantir ça :??:
 
Maintenant, y a-t-il un moyen indiscutable pour déterminer la nature de ce que j'ai dans ma base ?
 
@volken : je vais tenter ça, mais est-ce que ça va améliorer l'insertion ou la récupération des données ?


Ben fait un echo de la chaîne en provenance direc de ta bd dans ta page web puis fait de même en utilisant en plus la fonction htmlentities(xxx,yyy, 'UTF-8'). Tu verras bien si c'est htmlentities() qui pose pb.
 
Par rapport à l'utilisation de SET NAMES UTF-8 après une création de connexion à la BD, ça te garantira que le charset utilisé pour l'insertion ou la récup est bien UTF-8. Par contre, si avant, les données insérées en base ne sont pas du utf-8, faudra les reprendre. Mais si l'affichage via phpmyadmin est bon, les données insérées sont donc bien du utf-8.


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Planeta Calandreta : https://framalibre.org/content/planeta-calandreta
Reply

Marsh Posté le 23-01-2013 à 13:25:12   

Reply

Marsh Posté le 23-01-2013 à 21:20:58    

rufo is right.
 
PHP a un encodage interne en UTF-16.
 
Pour forcer les données à apparaitre en UTF-8, il faut faire un SET NAMES utf8 (sans le tiret, donc) à chaque connexion de base de données.
 
C'est à dire que SET NAMES utf8 doit être ta première requête juste après avoir ouvert une connexion à une BD.
 
Je te conseille de te faire une petite fonction qui te fait les deux à la suite, comme ça t'es sûr de pas oublier ;)


---------------
Directeur Technique (CTO)
Reply

Marsh Posté le 24-01-2013 à 08:11:16    

Ben je vais tenter ça, merci à tous  :jap:  
 
D'ici là j'ai retiré mes htmlentities, ça craint mais ça marche :/

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed