[Terminé] Encodage: latin1, ISO et CP1252

[yip2]

ici ca marche nickel. du beau japonais pur jus.

Bug:
- Le massif Pyrénées n'est pas reconnu (Accueil->Massif->Pyrénées) l'URL est pourtant RFC-valide car encodée en Pyr%E9n%E9es, mais c'est un encodage ISO (E9=é en iso)
le site attends un encodage UTF : %C3%A9 pour é
Les liens "Massifs Et encore..." dans la page sont correctement encodés en %C3%A9 et marchent. c'est seulement celui de la barre de titre qui vient de l'ISO.
-Réunion/NlleCalédonie/Cordillère marchent (URL non valide mais c'est l'ID qui est utilisé)

Bug sur toutes les fiches:
- Dans les coordonnées, l'item "Degrés décimaux" apparait en iso (donc avec losanges ?)
- Dans les coordonnées, quand on passe en Deg Min Sec, les séparateurs entre Deg et Min passent en losanges.
- Dans l'entête, le lien "cabane non gardée" (vers mode d emploi) renvoie vers une 404. c'est le probleme d'URL en UTF8 déjà vu pour les "points a proximité", mais ici plus grave car 404.
-De même, le lien "France->Alpes->Savoie" juste en dessous n'est pas valide non plus a cause de "département" dans l'URL. mais ca passe car l'analyse s'arrete à l'ID.

La chasse au bug bat son plein !
les 2 premiers ont déjà été repérés par Charlinette
le temps que j'écrive un post, les autres surement aussi

[sly]

Ce qui est étonnant, c'est que ta fiche a un nom en idéogramme japonais, que le forum dédié, sur la fiche semble porter le même nom, mais que le forum lui s'appelle "??????"

Il fallait tout lire des 6 pages de ce forum ma bonne dame !

Oui, en effet, je l'ai remarqué, l'explication est lié au forum qui ne semble pas être capable de gérer correctement cette avalanche de caractères.
Il peut gérer les "classiques" accents et particularités française ou disons latines, mais dès que ça part en japonais ou arabe, ça sort de son champ de fonctionnalités. Et je doute que je puisse le convaincre de babéliser ;-)

[yip2]

Alors là, je ne comprends pas. Je suis perdu, j'ai tenté avec tous les navigateurs à ma disposition et rien y fait (je n'ai pas google chrome, je fais de la résistance passive anti google), chez moi... ça marche toujours

le validator du W3C met un warning sur l'absence d'encoding dans le XML header.
Warning: No Character encoding declared at document level

normalement c'est implicite UTF-8 selon la norme mais cela peut il venir de là ?

genre certains brouteurs qui ne tiendrait pas compte de l'encoding HTTP , et en l'absence d'encoding XML, basculerait sur un truc local ISO ? (en infraction de la norme c'est vrai)

[Dominique]

- Le massif Pyrénées n'est pas reconnu (Accueil->Massif->Pyrénées)

Alors là, je dis STOP plus UTF-8 je rigole plus. nà

Bug sur toutes les fiches:
- Dans les coordonnées, l'item "Degrés décimaux" apparait en iso (donc avec losanges ?)
- Dans les coordonnées, quand on passe en Deg Min Sec, les séparateurs entre Deg et Min passent en losanges.

Cherchez pas dans le HTML ni le PHP, ces <options> sont générées par le javascript de la librairie. Je regarde

[Dominique]

Bug sur toutes les fiches:
- Dans les coordonnées, l'item "Degrés décimaux" apparait en iso (donc avec losanges ?)
- Dans les coordonnées, quand on passe en Deg Min Sec, les séparateurs entre Deg et Min passent en losanges.

Pas chez moi. Peux tu vider ton cache ? (la lib openlayers)

[yip2]

- Le massif Pyrénées n'est pas reconnu (Accueil->Massif->Pyrénées)

Alors là, je dis STOP plus UTF-8 je rigole plus. nà

Chut ... Faut pas reveiller l'ours ...

Bug sur toutes les fiches:
- Dans les coordonnées, l'item "Degrés décimaux" apparait en iso (donc avec losanges ?)
- Dans les coordonnées, quand on passe en Deg Min Sec, les séparateurs entre Deg et Min passent en losanges.

Cherchez pas dans le HTML ni le PHP, ces <options> sont générées par le javascript de la librairie. Je regarde[/quote]

ça remarche, je retarde.

[Dominique]

- Le massif Pyrénées n'est pas reconnu (Accueil->Massif->Pyrénées)

Ou bien pas chez moi (et je vais me coucher de suite) ou bien quelqu'un a corrigé ?

[sly]

Bug:
- Le massif Pyrénées n'est pas reconnu (Accueil->Massif->Pyrénées) l'URL est pourtant RFC-valide car encodée en Pyr%E9n%E9es, mais c'est un encodage ISO (E9=é en iso)
le site attends un encodage UTF : %C3%A9 pour é
Les liens "Massifs Et encore..." dans la page sont correctement encodés en %C3%A9 et marchent. c'est seulement celui de la barre de titre qui vient de l'ISO.

C'est malin celle-là, c'était en dur dans le code avec des %E9, j'ai remis des é et ça semble marcher.

Reste toutefois la question en suspend de notre choix pour les caractères dans les urls. Je trouve classe les urls avec des accents en UTF-8 (il faut être moderne !) mais en même temps, si ça ne marche pas sur les 3/4 des navigateurs, on peut simplifier et retourner dans le champs ascii, ou passer par un rawurlencode proposé par yip.

-Réunion/NlleCalédonie/Cordillère marchent (URL non valide mais c'est l'ID qui est utilisé)

Bien plus propre que la combine "à la Dominique ;-)" pour définir des zones d'ailleurs. Ce qui me rappel qu'il faudrait généraliser ça aux zones fait main qu'on trouve dans massif.php et les rentrer dans notre base directement, définis comme polygone (même si ça ne fait qu'un rectangle)

Tu peux préciser en quoi une URL avec des caractères UTF-8 est invalide ? c'est juste "pas recommandé" ou vraiment, la norme HTTP interdit les caractères UTF-8 dans les requêtes ?

Bug sur toutes les fiches:
- Dans les coordonnées, l'item "Degrés décimaux" apparait en iso (donc avec losanges ?)

Ha ben flûte, tu l'as aussi toi ? (ni moi ni charlinette n'avons le problème, mais toi et claude l'avez) Tu peux vérifier que c'est pas ton cache qui est en cause ? quel navigateur ?

- Dans les coordonnées, quand on passe en Deg Min Sec, les séparateurs entre Deg et Min passent en losanges.

Rien ici, ça semble être en lien avec un fichier .js car ces texte sont dans un fichier javascript. Donc sans doute lié au problème juste avant.

- Dans l'entête, le lien "cabane non gardée" (vers mode d emploi) renvoie vers une 404. c'est le probleme d'URL en UTF8 déjà vu pour les "points a proximité", mais ici plus grave car 404.

Vu ! C'est mon courcircuitage de conversion accents vers lettres non accentuées qui cause ça.
Il faut que je trouve une parade

-De même, le lien "France->Alpes->Savoie" juste en dessous n'est pas valide non plus a cause de "département" dans l'URL. mais ca passe car l'analyse s'arrete à l'ID.

Idem avant, est-ce vraiment invalide ?

[yip2]

Tu peux préciser en quoi une URL avec des caractères UTF-8 est invalide ? c'est juste "pas recommandé" ou vraiment, la norme HTTP interdit les caractères UTF-8 dans les requêtes ?

euh, oui, c'est d'abord le validator de validome qui l'a vu, celui de W3C ne voit rien. du coup j'ai vérifié le wikipedia de RFC3986 et de URI et en effet, la norme prévoit que ne doivent transiter sur le protocole HTTP que certains caractères ( très réduit, une 40e max. bien plus réduit que l'ASCII)
officiellement, les URI, dans les href, ne doivent contenir que ce set très limité.
tous les autres caractères doivent êtres en %XX (code hexa).
Il me semble maintenant que dans la réalité, le navigateur fait la conversion en %XX avant d'envoyer sa requete HTTP.

Tout est converti en %AA%BB%CC, même les multi-octets unicodes.
C'est le boulot de rawurlencode() en PHP si j'ai tout saisi.

<..cabane-non-gardée .. 404>
Vu ! C'est mon courcircuitage de conversion accents vers lettres non accentuées qui cause ça.
Il faut que je trouve une parade

quand le navigateur traduit "gardée" en langage URI automatiquement, il fait soit du %E9 si il vient de l'ISO, soit du %A3%A9 si il vient de l'UTF. Il risque pas de traduire vers "e" simple.
l'ennui c'est que rawurlencode() fera pareil, il ne traduira pas un é vers e mais vers %AA%A9. c'est pas forcément ce qu'on veut, ou alors ça change certaines choses.
Peut-être renommer le fichier suffirait, je ne sais pas. peut-être l'encodage du terminal peut foutre la grouille lors du renommage.

[yip2]

http://stackoverflow.com/questions/2742 ... rs-in-urls

Ils y parlent de l'encodage Unicode dans les URL, comment il est traité, et ils y recommandent l'utilisation d'ID à analyser au début de l'URL.
autrement dit exactement ce que tu as mis en place ici et qui fait que ça marche !

[Charlinette]

Ce qui est étonnant, c'est que ta fiche a un nom en idéogramme japonais, que le forum dédié, sur la fiche semble porter le même nom, mais que le forum lui s'appelle "??????"

Il fallait tout lire des 6 pages de ce forum ma bonne dame !

C'est que je l'ai lu... mais c'est du chinois votre jargon pour moi... vient donc dans mon pays professionnel que je te dépayse...

[Claude Mauguier]

Parfait alors. Le problème semble se situer chez l'ours, peut-être en lien avec une mise en cache, car ce problème existait il y a 3h mais je l'ai réparé (il me semble) depuis

Sly, c'est OK sur chrome aussi, après vidange du cache !

[sly]

normalement c'est implicite UTF-8 selon la norme mais cela peut il venir de là ?

Je vais l'ajouter de toute façon, la validateur w3c donne un warning très pertinent :
"Ce n'est pas obligatoire, mais vous devriez le mettre, car si quelqu'un fait une copie du site sur un support de type local (cd, clé, disque), l'information de header http n'existera plus, et il y aura alors ambiguïté sur le choix de l'encodage"

[sly]

- Le massif Pyrénées n'est pas reconnu (Accueil->Massif->Pyrénées)

Ou bien pas chez moi (et je vais me coucher de suite) ou bien quelqu'un a corrigé ?

J'ai trouvé d'où ça venait : chrome semble être tatillon du javascript ;-)

Le fichier js qui contenait les é corrects en UTF-8 contenait bien plus bas des caractères biscornus (dans un commentaire) qui n'ont pas été convertis proprement, je suppose que la VM js de chrome re-basculait alors en mode compatible ISO et donc foirait les é

Moins les histoires de cache, je suppose que c'est réparé

[sly]

Suite à un commentaire de yip indiquant à juste titre qu'on avait un peu pourri la page d'accueil avec nos tests, je me suis permis de retirer la fiche qui nous a bien servi afin de montrer que les pages des points sur wri supportent bien le passage à UTF-8.

Pour les encodages indiqués dans les pages Xhtml, j'ai rajouté ça au mieux et ça semble plaire au validateur w3c

Pour les URLs, j'ai eu une longue discussion avec moi même en tenant compte du lien donnée par yip, de la norme http, de l'usage actuellement en vigueur, de la réalité de refuges.info, d'un compromis simple à coder et efficace, du choix retenu par un projet comme wikipedia, et enfin de ma volonté initiale qui était de produire des URL lisibles, indiquant d'elles même ce vers quoi elles pointent, facilement copiables et réutilisables par e-mail, blog et autre moyen de communication...
... et j'en suis arrivé à grosso modo un retour comme avant ;-)

Et ça donne ça :
http://www.refuges.info/point/3934/caba ... nde-Combe/
http://www.refuges.info/point/3942/refu ... ang-Pinet/
http://www.refuges.info/point/3931/caba ... ron/Borie/

Je souhaite éviter au maximum d'avoir recours à l'encodage d'url comme /cabane non gar%C7e/%D6tang%3E/ car c'est illisible pour un humain quand on l'envoi par email par exemple, mais je ne peux pas passer par des accents car les navigateurs les convertissent de toute façon au format "encodage d'url" ce qui revient à la solution d'avant (dommage) et je souhaite éviter les caractères non autorisés dans les urls car ils subiront le même sort.

Bref, ça donne des url plates et sans saveur mais lisibles et compatibles.

J'ai testé avec des alphabets/idéogrammes non latins et mon code zigouille tout (l'url reste valide, mais pas lisible) si l'occassion se présente vraiment, je re-coderais ma fonction, mais pour l'instant, restons pragmatiques.