- Safari importe en iso-Latin (là je pense que c'est son réglage par défaut)
L'ISO-8859-1 est la valeur par défaut en HTTP/HTML.
C'est garanti, sûr de sûr, partout ?
-- Stephane Moriaux et son (moins) vieux Mac déjà dépassé
Patrick Mevzek
L'ISO-8859-1 est la valeur par défaut en HTTP/HTML.
C'est garanti, sûr de sûr, partout ?
Comme toutes les valeurs par défaut, il ne faut justement *pas* s'y fier si on veut faire quelque chose de robuste. Cf sinon §3.7 du RFC2616, je cite : When no explicit charset parameter is provided by the sender, media subtypes of the "text" type are defined to have a default charset value of "ISO-8859-1" when received via HTTP.
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
L'ISO-8859-1 est la valeur par défaut en HTTP/HTML.
C'est garanti, sûr de sûr, partout ?
Comme toutes les valeurs par défaut, il ne faut justement *pas* s'y fier
si on veut faire quelque chose de robuste.
Cf sinon §3.7 du RFC2616, je cite :
When no explicit charset
parameter is provided by the sender, media subtypes of the "text"
type are defined to have a default charset value of "ISO-8859-1" when
received via HTTP.
--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
L'ISO-8859-1 est la valeur par défaut en HTTP/HTML.
C'est garanti, sûr de sûr, partout ?
Comme toutes les valeurs par défaut, il ne faut justement *pas* s'y fier si on veut faire quelque chose de robuste. Cf sinon §3.7 du RFC2616, je cite : When no explicit charset parameter is provided by the sender, media subtypes of the "text" type are defined to have a default charset value of "ISO-8859-1" when received via HTTP.
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Patrick Mevzek
L'ISO-8859-1 est la valeur par défaut en HTTP/HTML.
Non, c'est la valeur par défaut en HTTP
Le point §3.7 du RFC2616 s'applique à tous les contenus en text/*, donc au HTML : When no explicit charset parameter is provided by the sender, media subtypes of the "text" type are defined to have a default charset value of "ISO-8859-1" when received via HTTP.
à condition que le format transporté n'ait pas une autre norme (ce qui est le cas de xml, norme UTF-8).
Le « vrai » XML pour le web (XHTML) n'est pas en text/* donc ce qui précède ne s'applique pas.
Corrigé par les évolutions suivantes de RFC qui disent "surtout si vous ne savez pas, ne supposez rien" (ce qui n'est pas très applicable en pratique il faut bien choisir quelquechose).
Et c'est ISO-8859-1 qui était choisi à l'époque (il y a ~10 ans) par tous les navigateurs.
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
L'ISO-8859-1 est la valeur par défaut en HTTP/HTML.
Non, c'est la valeur par défaut en HTTP
Le point §3.7 du RFC2616 s'applique à tous les contenus en text/*, donc
au HTML :
When no explicit charset
parameter is provided by the sender, media subtypes of the "text" type
are defined to have a default charset value of "ISO-8859-1" when
received via HTTP.
à condition que le format
transporté n'ait pas une autre norme (ce qui est le cas de xml, norme
UTF-8).
Le « vrai » XML pour le web (XHTML) n'est pas en text/* donc ce qui
précède ne s'applique pas.
Corrigé par les évolutions suivantes de RFC qui disent "surtout si vous
ne savez pas, ne supposez rien" (ce qui n'est pas très applicable en
pratique il faut bien choisir quelquechose).
Et c'est ISO-8859-1 qui était choisi à l'époque (il y a ~10 ans) par
tous les navigateurs.
--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
L'ISO-8859-1 est la valeur par défaut en HTTP/HTML.
Non, c'est la valeur par défaut en HTTP
Le point §3.7 du RFC2616 s'applique à tous les contenus en text/*, donc au HTML : When no explicit charset parameter is provided by the sender, media subtypes of the "text" type are defined to have a default charset value of "ISO-8859-1" when received via HTTP.
à condition que le format transporté n'ait pas une autre norme (ce qui est le cas de xml, norme UTF-8).
Le « vrai » XML pour le web (XHTML) n'est pas en text/* donc ce qui précède ne s'applique pas.
Corrigé par les évolutions suivantes de RFC qui disent "surtout si vous ne savez pas, ne supposez rien" (ce qui n'est pas très applicable en pratique il faut bien choisir quelquechose).
Et c'est ISO-8859-1 qui était choisi à l'époque (il y a ~10 ans) par tous les navigateurs.
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Pierre Goiffon
Olivier Miakinen wrote:
http://www.miakinen.net/vrac/charsets/
En fait j'envisage de faire encore plus simple (mais qui ne fonctionnera qu'avec JavaScript), c'est que les deux champs de saisie se pré-remplissent quand on clique sur un caractère donné d'une table donnée.
Yeah, je n'osais le suggérer !
(Et note que c'est maintenant MacRoman qui est la table par défaut
Oui, je l'ai noté avec bonheur :)
Olivier Miakinen wrote:
http://www.miakinen.net/vrac/charsets/
En fait j'envisage de faire encore plus
simple (mais qui ne fonctionnera qu'avec JavaScript), c'est que les deux
champs de saisie se pré-remplissent quand on clique sur un caractère
donné d'une table donnée.
Yeah, je n'osais le suggérer !
(Et note que c'est maintenant MacRoman qui est la table par défaut
En fait j'envisage de faire encore plus simple (mais qui ne fonctionnera qu'avec JavaScript), c'est que les deux champs de saisie se pré-remplissent quand on clique sur un caractère donné d'une table donnée.
Yeah, je n'osais le suggérer !
(Et note que c'est maintenant MacRoman qui est la table par défaut
Oui, je l'ai noté avec bonheur :)
Pierre Goiffon
ASM wrote:
L'ISO-8859-1 est la valeur par défaut en HTTP/HTML.
C'est garanti, sûr de sûr, partout ?
Voir ma réponse :) (message-id: <46288109$0$20757$)
ASM wrote:
L'ISO-8859-1 est la valeur par défaut en HTTP/HTML.
C'est garanti, sûr de sûr, partout ?
Voir ma réponse :) (message-id: <46288109$0$20757$426a74cc@news.free.fr>)
L'ISO-8859-1 est la valeur par défaut en HTTP/HTML.
C'est garanti, sûr de sûr, partout ?
Voir ma réponse :) (message-id: <46288109$0$20757$)
Jeff-com
On 16 avr, 10:52, 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 é) 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, é)
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" da ns 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
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 é) 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, é)
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" da ns
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'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 é) 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, é)
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" da ns 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
Pierre Goiffon
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 é) 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, é)
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.
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 é) 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, é)
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.
malheureusement il faut faire la conversion "à la main"... (...)
1° option : transformer les caractères spéciaux en entités html au départ (é deviens é) 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, é)
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.
Jeff-com
On 27 avr, 14:32, Pierre Goiffon 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 de puis une page servie en UTF-8 était tout à fait exploitable. Le tout est d'être vigilant à bien positionner les entêtes HTTP (sous type char set à 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é.
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 de puis
une page servie en UTF-8 était tout à fait exploitable. Le tout est
d'être vigilant à bien positionner les entêtes HTTP (sous type char set à
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é.
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 de puis une page servie en UTF-8 était tout à fait exploitable. Le tout est d'être vigilant à bien positionner les entêtes HTTP (sous type char set à 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é.
Pierre Goiffon
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$) : 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$)
Bref oui, il faut être cohérent (sans blague ?).
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>)
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$) : 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$)
