Jeff-com 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.
>
> en quoi les entités sont un problème ?

Préférer utiliser des entités sans savoir pourquoi, et ne jamais se
documenter sur ce qu'est un codage et comment on doit le spécifier en
HTTP, c'est une très mauvaise manière de travailler.

Si par contre on est déjà renseigné sur toutes ces notions je ne vois
aucune raison de déclarer un codage us-ascii et de coder tout caractère
en-dehors par des entités. Si vous voyez des raisons, dites le nous !

L'utilité des entités est de pouvoir intégrer des caractères en-dehors
du jeux de caractère courant. En Europe on n'est que très peu concerné,
le support d'UTF-8 par les navigateurs est très bon depuis plusieurs
années. Sur des pages CJK la donne peut éventuellement être différente.

> 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.

Le concepteur doit *toujours* spécifier le codage utiliser, c'est un
impératif. Ca a été démontré de multiples fois ici.

> 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.

Je ne sais pas ce que veux dire "utilisera toujours UTF-8" : tel que je
le comprend, vous nous dites qu'une requête XHR lira le contenu
systématiquement en UTF-8, quelque soit le codage spécifié par le
serveur (entête HTTP) ou au sein du document (meta ou prologue XML).

Dans ce fil on a constaté qu'une requête XHR savait très bien se
débrouiller pour récupérer des ressources servies avec un codage autre
que UTF-8. Encore une fois voyez l'exemple que j'ai posté (message-id:
<4627975f$0$3800$426a74cc@news.free.fr>) : on récupère une page servie
en ISO Latin-1 et elle est lue comme telle.

> 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.

L'entête HTTP est utilisé par les clients pour savoir quel codage ils
doivent "utiliser" pour lire le contenu qui leur est envoyé. Si le
contenu n'est pas envoyé avec ce codage, effectivement il y a prb (c'est
ce qui arrivait sur l'exemple donné par ASM, message-id:
<46277247$0$27370$ba4acef3@news.orange.fr>)

Bref oui, il faut être cohérent (sans blague ?).