On 27 avr, 14:32, Pierre Goiffon <pgoif...@free.fr.invalid> wrote:

> Je vois trop souvent des concepteurs conseiller d'utiliser les entités.
> A ma connaissance on n'a *jamais* besoin de le faire, et d'habitude ce
> conseil est donné par ignorance de tout ce qui est lié à la notion de
> codage.
> Je dirais donc qu'en débutant la lecture de votre message j'ai un très
> mauvais à prioris.

en quoi les entités sont un problème ? il faut qu'on m'explique... le
but de la personne à qui je répondais était, à priori, simplement
afficher des informations dans un navigateur, lesdites informations
n'ayant pas pour but d'être échangées par un autre moyen qu'une "page
web". Dans ce cas précis, l'encodage importe moins que peu : les
entités ont été créées pour ça, justement : afficher des caractères
non ascii sans avoir à se soucier de l'encodage.
> > quoi qu'il en soit, ajax envoie les paramètres en utf-8 et est sensé
> > les servir (ie : après avoir récupéré une réponse il la "sert" dans
> > une variable) en utf-8 quel que soit l'encodage de la page ou du
> > formulaire etc...
>
> Je ne suis pas sûr d'avoir compris la signification de ce paragraphe,
> pourriez-vous être plus précis ?

il suffit de relire : ajax emploi utf-8.
Lorsqu'on place un formulaire sur une page, on peut spécifier un
paramètre "accept-charset". Dans la page elle même, on peut spécifier
un encodage de caractères dans la balise meta "content-type", on peut
aussi, si on emploie XHTML (et qu'on le fait bien) spécifier aussi un
charset dans l'a déclaration xml du document, enfin on peut spécifier
un encodage dans les en-têtes http envoyées par le serveur. Quel que
soit le charset spécifié dans les élément cités, "Ajax" (ou "XHR"si
vous préférez) utilisera toujours utf8. Donc si vous utilisez ajax
pour afficher des informations sur une page web, ces informations
seront encodées en utf8, et si vous envoyez des informations provenant
d'un formulaire en utilisant "Ajax", les informations arriveront au
CGI (au script php, perl, python...) encodées en utf8
Il faut donc partir de là pour encoder ses documents html. Dans une
configuration apache/php classique (celle de free en fait partie)
l'encodage par défaut utilisé est latin-1. quelle que soit la fonction
utilisée pour traiter les chaines de caractères, celles-ci seront
considérées comme du latin1 même si elles n'en sont pas. il conviendra
donc de les convertir vers latin1 (les fonctions utf8_encode et
utf8_decode sont là pour ça, encore faut-il y penser) avant de les
traiter, en en utf8 avant de les envoyer. Il ya d'autres méthodes,
mais il faut avoir accès à apache.conf et php.ini....

> Nous avons pu vérifier au cours de la discussion (l'avez vous lue ?) que
> le contenu d'une page servie en ISO Latin-1 et récupérée par XHR depuis
> une page servie en UTF-8 était tout à fait exploitable. Le tout est
> d'être vigilant à bien positionner les entêtes HTTP (sous type charset à
> l'entête content-type) : si on ne le fait pas on a des problèmes, si on
> le fait convenablement les choses se passent bien.

ce n'est pas tout ! php a cette fâcheuse manie de penser que toutes
les chaînes de caractères sont en latin1 et de les traîter comme
telles. les headers ne sont pas forcément la panacée : si la chaîne
est envoyée en latin1, tous les headers du monde n'en feront pas une
utf8.

en effet il faut être vigilant, mais surtout cohérent.

Et je ne parle pas des éditeurs sous windows qui encodent tous les
fichiers en latin 1 ou 15... impossible alors de ne pas utiliser les
entités (ou faire un buffering et re-encoder ce buffer en utf8 avant
la sortie) sous peine d'avoir, éternellement un problème d'encodage.

est-ce plus clair ?

et puis pourquoi décrier une méthode si elle fonctionne dans ce cas
précis ? les entités sont une solution tout à fait acceptable dans le
cas présenté.