Je galère depuis quelques jours sur un problème, et j'ai rien trouvé
d'intéressant sur Google que se soit sur le web ou dans les newsgroups.
Je génère un fichier XML encodé en utf-8, pour encoder les textes rentrées
j'y vais à coup de utf8_encode(htmlspecialchars($texte)) pour être conforme
à la fois à XML et au paramètre d'entrée de utf8_encode (utf8_encode
convertit de iso-8859-1 en utf-8).
Jusque là pas de problème avec la grande majorités des caractères
(&<>éèà...) mais je me suis aperçu : qu'avec celui-ci par exemple : right
single quote mark 92 ’ ’ --> '
Ni htmlspecialchars ou htmlentities et ni utf8_encode l'encode du coup je me
retrouve avec un document XML non valide !
J'aimerais savoir qu'elle est la meilleur stratégie à adopter à votre avis,
pour l'instant je fais un str_replace mais la solution me convient pas car
j'imagine que le problème peu se reposer avec d'autre caractère. Qu'elles
sont les caractères à problème et existe t-il une solution propre pour y
remédier ?
PS : v. PHP 4.3.2
D'avance un grand merci pour votre aide,
Séb
-- carpe diem --
Tout le monde savait que c'était impossible. Il est venu un imbécile qui ne
savait pas et qu'il l'a fait. Marcel Pagnol.
Y a quand meme quelques chose de relou dans cette histoire, c'est que c'est toujours pas des caractère UTF-8 !!!
Faudrai la meme fonction avec des resultat UTF-8 !
C'est vrai qu'un des avantages de UTF-8, c'est de plus avoir à se faire ch*** avec les entitées :/
-- Bobe (Aurélien Maille) http://webnaute.net
"la vie d'un geek est un combat perpétuel contre l'imperfection"
nano
Bobe wrote:
J.J.SOLARI nous a dit le 16/05/2004 23:07:
Le problème résidait (plutôt, réside toujours) principalement, comme il me semble que c'est ton cas, dans l'incompatibilité entre les jeux de caractères win-1252 (et d'autres win-xxxx) avec iso-8859-1.
Je m'en étais sorti en mappant chacun des caractères du jeu cp-1252 situés dans la zone réservée (selon iso-8859-1) par leur équivalent Unicode. Voici ce que ça donnait :
Quelle était la provenance des données ?
Car dans le cas d'un formulaire html par exemple, et si le charset de la page est ISO-8859-1, le navigateur devrait théoriquement envoyer les données sous le charset ISO-8859-1 non ?
Bobe,
Pour le cas cité, les données provenaient d'une base Access, laquelle avait fait l'objet d'un export au format CSV chargé ensuite (après filtrage idoine cp-1252->iso-8859-1) dans une base MySQL.
En ce qui concerne la nature du codage utilisé par le navigateur, cela dépend de beaucoup trop de paramètres, mais voyons plutôt le document RFC2616 définissant le protocole HTTP/1.1 <http://www.ietf.org/rfc/rfc2616.txt>, §3.7.1 :
[...] 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. Data in character sets other than "ISO-8859-1" or its subsets MUST be labeled with an appropriate charset value. [...]
Cela dit que les données transitant via HTTP sont supposées être codées en iso-8859-1 seulement si aucune indication sur le codage utilisé n'est fournie, et NON que le navigateur enverra forcément des données iso-8859-1. Nuance...
Si les données se présentent dans un autre codage, il FAUT alors l'indiquer. C'est le rôle de l'attribut accept-charset (et dans une moindre mesure de l'attribut enctype) sur l'élément form. Voir HTML4.01 <http://www.la-grange.net/w3c/html4.01/interact/forms.html#h-17.3>.
Par conséquent, pour une page déclarée iso-8859-1, le serveur devrait voir les données du formulaire dans ce codage, en l'absence d'une indication contraire (accept-charset) du formulaire.
Maintenant, est-ce que, préalablement à la soumission d'un formulaire, TOUS les navigateurs réalisent un transcodage automatique en iso-8859-1 (ou dans autre codage normalisé) et en informent le serveur (qui lui même doit être configuré dans ce sens) ?
Rien n'est moins sûr et, par précaution, on est tenu au traitement de "normalisation" côté serveur.
Le problème résidait (plutôt, réside toujours) principalement, comme il
me semble que c'est ton cas, dans l'incompatibilité entre les jeux de
caractères win-1252 (et d'autres win-xxxx) avec iso-8859-1.
Je m'en étais sorti en mappant chacun des caractères du jeu cp-1252
situés dans la zone réservée (selon iso-8859-1) par leur équivalent
Unicode. Voici ce que ça donnait :
Quelle était la provenance des données ?
Car dans le cas d'un formulaire html par exemple, et si le charset de la page
est ISO-8859-1, le navigateur devrait théoriquement envoyer les données sous
le charset ISO-8859-1 non ?
Bobe,
Pour le cas cité, les données provenaient d'une base Access, laquelle
avait fait l'objet d'un export au format CSV chargé ensuite (après
filtrage idoine cp-1252->iso-8859-1) dans une base MySQL.
En ce qui concerne la nature du codage utilisé par le navigateur, cela
dépend de beaucoup trop de paramètres, mais voyons plutôt le document
RFC2616 définissant le protocole HTTP/1.1
<http://www.ietf.org/rfc/rfc2616.txt>, §3.7.1 :
[...] 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. Data in character sets
other than "ISO-8859-1" or its subsets MUST be labeled with an
appropriate charset value. [...]
Cela dit que les données transitant via HTTP sont supposées être codées
en iso-8859-1 seulement si aucune indication sur le codage utilisé n'est
fournie, et NON que le navigateur enverra forcément des données
iso-8859-1. Nuance...
Si les données se présentent dans un autre codage, il FAUT alors
l'indiquer. C'est le rôle de l'attribut accept-charset (et dans une
moindre mesure de l'attribut enctype) sur l'élément form.
Voir HTML4.01
<http://www.la-grange.net/w3c/html4.01/interact/forms.html#h-17.3>.
Par conséquent, pour une page déclarée iso-8859-1, le serveur devrait
voir les données du formulaire dans ce codage, en l'absence d'une
indication contraire (accept-charset) du formulaire.
Maintenant, est-ce que, préalablement à la soumission d'un formulaire,
TOUS les navigateurs réalisent un transcodage automatique en iso-8859-1
(ou dans autre codage normalisé) et en informent le serveur (qui lui
même doit être configuré dans ce sens) ?
Rien n'est moins sûr et, par précaution, on est tenu au traitement de
"normalisation" côté serveur.
Le problème résidait (plutôt, réside toujours) principalement, comme il me semble que c'est ton cas, dans l'incompatibilité entre les jeux de caractères win-1252 (et d'autres win-xxxx) avec iso-8859-1.
Je m'en étais sorti en mappant chacun des caractères du jeu cp-1252 situés dans la zone réservée (selon iso-8859-1) par leur équivalent Unicode. Voici ce que ça donnait :
Quelle était la provenance des données ?
Car dans le cas d'un formulaire html par exemple, et si le charset de la page est ISO-8859-1, le navigateur devrait théoriquement envoyer les données sous le charset ISO-8859-1 non ?
Bobe,
Pour le cas cité, les données provenaient d'une base Access, laquelle avait fait l'objet d'un export au format CSV chargé ensuite (après filtrage idoine cp-1252->iso-8859-1) dans une base MySQL.
En ce qui concerne la nature du codage utilisé par le navigateur, cela dépend de beaucoup trop de paramètres, mais voyons plutôt le document RFC2616 définissant le protocole HTTP/1.1 <http://www.ietf.org/rfc/rfc2616.txt>, §3.7.1 :
[...] 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. Data in character sets other than "ISO-8859-1" or its subsets MUST be labeled with an appropriate charset value. [...]
Cela dit que les données transitant via HTTP sont supposées être codées en iso-8859-1 seulement si aucune indication sur le codage utilisé n'est fournie, et NON que le navigateur enverra forcément des données iso-8859-1. Nuance...
Si les données se présentent dans un autre codage, il FAUT alors l'indiquer. C'est le rôle de l'attribut accept-charset (et dans une moindre mesure de l'attribut enctype) sur l'élément form. Voir HTML4.01 <http://www.la-grange.net/w3c/html4.01/interact/forms.html#h-17.3>.
Par conséquent, pour une page déclarée iso-8859-1, le serveur devrait voir les données du formulaire dans ce codage, en l'absence d'une indication contraire (accept-charset) du formulaire.
Maintenant, est-ce que, préalablement à la soumission d'un formulaire, TOUS les navigateurs réalisent un transcodage automatique en iso-8859-1 (ou dans autre codage normalisé) et en informent le serveur (qui lui même doit être configuré dans ce sens) ?
Rien n'est moins sûr et, par précaution, on est tenu au traitement de "normalisation" côté serveur.
