PHP, mysql et l'utf8

[Guest azazel]

Hello -

J'ai une base mysql encodé en utf8.

J'ai une page xhtml avec le charset utf8 de définie au niveau header http, xml et meta tags.

Dans une page, j'ai un formulaire.

Dans ce forumaile, je saisie du html, et en cas d'erreur, je réaffiche le formulaire en conservant les valeurs saisies dans les champs.

Et firefox me revoie une jolie erreur de parsing car dans ce cas, la'attribut value de mes inputs contient du html (<b>test</b>, par exemple), ce qui n'est pas accepté par la norme xhtml.

Une solution est passe par un htmlentitie() avec en troisième paramêtre le charset utf8, mais je croyait, peut être naïvement, que spécifier le charset de la page dispensait de cette opération.

Me trompe je ?

A+ FCH

[maximettb]

Tu devrais peut être essayer de spécifier l'encodage du formulaire (<form ... accept-charset="utf-8">) dans celui ci...

[MarvinLeRouge]

Salut,

J'ai moi aussi eu récemment des problèmes en rapport avec l'encodage. Je te conseille donc :

1) de transformer tous tes caractères en cas de ré-affichage grâce à htmlentities (dans le cas du ré-affichage seulement bien sûr), et de traiter ça à l'insertion (ou à la récupération de tes données depuis ta base de données (que je suppose existante puisque les données de ce formulaire atterrissent bien quelque part).

2) de préciser ton encodage grâce à la fonction php header. En effet, l'existence de la valeur d'encodage utf-8 dans la balise header de ton fichier (je ne sais pas si tu parles de la balise header html ou de la fonction php dans ton message) ne suffit pas nécessairement (j'ai eu le cas) car ton serveur renvoie potentiellement un autre header d'encodage, ce qui crée(rait) un conflit de priorité.

Voilà j'espère que je ne t'ai pas trop

[Ganf]

Le codage caractère n'a *rien* à voir avec l'aptitude à mettre les caractères spéciaux (j'ai nommé < > & et le délimiteur de chaîne pour un attribut) dans le code source.

Un bon codage caractère peut éventuellement te permettre de ne pas passer sous forme d'entité les caractères non ascii (accents, caractères étrangers,...), mais c'est tout.

Les deux problématique sont totalement indépendantes.

[Guest azazel]

Le codage caractère n'a *rien* à voir avec l'aptitude à mettre les caractères spéciaux (j'ai nommé < > & et le délimiteur de chaîne pour un attribut) dans le code source.

Un bon codage caractère peut éventuellement te permettre de ne pas passer sous forme d'entité les caractères non ascii (accents, caractères étrangers,...), mais c'est tout.

Les deux problématique sont totalement indépendantes.

<{POST_SNAPBACK}>

Exact.

La norme interdit la présence de html dans les attributs.

Il faut donc htmlentitities tout ce qui est mis dans l'attribut 'value' dans les formulaires.

Par contre, dans le cas ou l'on utilise un encodage différent de l'iso-8859-1, il faut utiliser le troisième paramêtre de la fonction htmlentitites() pour spécifier le charset de la chaine htmlentitieser.

A+

[Anubis]

Petit info bète, il serait peut-être plus judicieux d'utiliser htmlspecialchars() que htmlentities(). En effet, htmlentities() transforme tous les caractères étendus en entité HTML, ce qui peut être ennuyeux pour le traitement du PHP.

Sinon, je dirais que c'est normal de devoir spécifier à ta fonction PHP un codage UTF-8, il ne pourra pas le deviner tout seul tout simplement parce que PHP est très nul avec les codages de caractères.

Alors je dirais juste une chose, il faut faire bien attention, et tester ton code dans tous les cas extrèmes car PHP est une vraie plaie dès qu'il manipule des caractères un peu avancés.

M'enfin, je le redis, un bon vieux htmlspecialchars() devrait suffir dans ton cas à retirer les balises HTML de tes attributs et à les transformer en texte simple.