ISO-8859-15 insuffisant pour les signes euros ?

Je viens de recevoir un mail :

a écrit :
Bonsoir,

Je viens de dépister un petit, non pas souci, mais point dont je ne suis pas sûr qu'il mérite d'être posté sur le forum. Voici:

Les pages du forum sont encodées en ISO-8859-1. Bien. Mais il se trouve que sur la page du Bar du Forum, figure un sujet où se trouve le caractère € (euro). Et boum badaboum, le validateur du W3C ne le reconnaît pas...

Je ne sais pas si cette question méritait d'être posée dans le salon Encodage, dans la mesure où il s'agit d'un problème ponctuel du forum lui-même... mais si c'est le cas et que cela peut être généralisé, il ne faut pas hésiter à le faire à ma place

Cordialement,

Il se trouve que lorsque Dew utilise le charset ISO-8859-15, les caractères euros (€) apparaissent sous forme de carrés.

Comment régler ce problème ?

Si le changement de charset formel produit des petits carrés, c'est que le texte lui-même n'est pas en ISO-8859-15 (le fait de changer le charset spécifié sur une page ne change rien à son encodage réel).

Cet euro pourrait-il être simplement traité en entité numérique ?

Hmm, en clair, il faudrait également changer, via PHP ou .htaccess, la façon dont est servie la page par le serveur (= encodage réél) ?

a écrit :
Cet euro pourrait-il être simplement traité en entité numérique ?

Disons que je ne pense pas qu'on puisse imposer aux membres d'utiliser des entités HTML pour désigner l'euro.

Raphael a écrit :
Hmm, en clair, il faudrait également changer, via PHP ou .htaccess, la façon dont est servie la page par le serveur (= encodage réél) ?

Non, c'est toujours l'encodage spécifié. C'est au niveau de la génération de la page que ça se passe. Mais là, je ne suis pas dans le secret des dieux

Raphael a écrit :
Cet euro pourrait-il être simplement traité en entité numérique ?

Disons que je ne pense pas qu'on puisse imposer aux membres d'utiliser des entités HTML pour désigner l'euro.

Bien-sûr. Mais un le signe euro lui-même pourrait être transcrit en entité lors du traitement du message après saisie.

Laurent Denis a écrit :
Le signe euro lui-même pourrait être transcrit en entité lors du traitement du message après saisie.

C'est exact. Mais l'inconvénient est que les signes précédemment stockés le seront toujours dans l'encodage d'origine (à moins de faire une grosse moulinette pour les remplacer, et être vraiment sûr qu'ils le seront en ISO-8859-15).

Sachant aussi que le texte passe successivement du navigateur à PHP puis à MySQL, la façon dont tout ceci est encodé est assez obscure (n'y en a-t-il pas un qui fait son malin dans la chaîne ?). J'imagine que MySQL stocke le tout en ISO-8859-1 par défaut. Au niveau de la génération de la page, là aussi pas d'allusion explicite à l'encodage.

Bref, j'hésite... Le problème avec l'encodage c'est qu'on est jamais vraiment sûr de ce qu'on stocke ou de ce qu'on délivre, surtout lorsqu'il s'agit de saisies d'utilisateurs.

Merci pour cette réponse.
Modifié par dew (23 Mar 2005 - 20:46)

À mon avis, ni PHP ni MySQL ne se tracassent vraiment de savoir comment est encodée ta chaîne, tant que c'est dans un format "8 bits".

Ce qui intéresse MySQL ou PHP, c'est de savoir si c'est de l'UTF-8 (auquel cas la bdd devra se livrer à une certaine gymnastique pour te permettre de stocker, par exemple, 10 caractères (qui seront peut-être 10, peut-être 15 octets)

Sinon, ben un caractère == un octet. Et chaque valeur ou presque de 0 à 255 est utilisée, quel que soit l'encodage (iso-latin1, iso-latin9, windows-1252). Juste qu'à une valeur correspondra un autre caractère dans un cas ou dans l'autre. Mais, objectivement, MySQL 3 et PHP s'en tamponnent le coquillard, leur rôle se résume à préserver le contenu binaire, pas les caractères. De toute façon comment pourraient-ils savoir qel encodage tu lui fournis en entrée ?

MySQL 4 s'en moque moins, semble-t-il, dans la mesure où il stocke tout en utf-8 et doit donc faire les traductions ad-hoc. D'ailleurs y'a une fonction php pour mysql 4+ qui permet de définir le charset de la base de données.