On 16 avr, 10:52, o...@netcourrier.com wrote:
> Bonjour,
>
> J'ai beau avoir lu pas mal de page sur le sujet je ne comprends pas le
> pb.
>
> J'ai une page ouèbe qui s'affiche très bien en direct, avec des
> accents, sous Firefox:
>
> http://osele.free.fr/prg/accent.html
>

malheureusement il faut faire la conversion "à la main"... je n'ai pas
testé en full javascript mais avec un server-side (php pour moi) donc
je pense que le principe est bon mais peut être pas la forme

1° option : transformer les caractères spéciaux en entités html au
départ (é deviens &eacute ainsi, quel que soit l'encodage de
caractères, ça passera
2° option : convertir les caractères spéciaux selon leur code ascii à
l'arrivée (\xE9 deviens é ou, mieux, &eacute

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

de même, il faut être cohérent et ne pas placer de tags xml ou html
indiquant que la page est en utf8 si le header http dit iso..., en php
tu peux utiliser la fonction header() avec par exemple :
header("Content-Type: text/html; charset=utf-8");

j'espère avoir fait avancer le shmilblick
jeff

Jeff-com wrote:
> malheureusement il faut faire la conversion "à la main"...
(...)
> 1° option : transformer les caractères spéciaux en entités html au
> départ (é deviens &eacute ainsi, quel que soit l'encodage de
> caractères, ça passera
> 2° option : convertir les caractères spéciaux selon leur code ascii à
> l'arrivée (\xE9 deviens é ou, mieux, &eacute

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.

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

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.

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

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