[Terminé] Encodage: latin1, ISO et CP1252

Message par **sly** » 07 févr. 2013, 21:40

Charlinette a écrit :
sly a écrit : 2n yeux étant mieux si n > 1, j'engage tout courageux à parcourir :
http://refuges.letuffe.org/

A la recherche de zones qui pourraient foirer.

Que les photos n'apparaissent pas, ni sur la page d'accueil ni sur les fiches, c'est normal ?

L'absence de photo est normal (bien trop long à copier)

Message par **sly** » 07 févr. 2013, 21:42

Dominique a écrit :Question bête: pourquoi n'annonces tu pas de charset ? UTF-8 est il implicite ?

heu ? annoncer où et comment ?

Dans les meta des pages HTML ? oui, on pourra le remettre, mais le header http prend le dessus de toute façon, donc inutile, sauf dans le cas où quelqu'un voudrait avoir une copie "hors ligne" du site refuges.info

Message par **Dominique** » 07 févr. 2013, 21:50

Faudra changer l'encodage du header et de la première ligne des exportations GPX
<?xml version="1.0" encoding="iso-8859-1" standalone="no"?>
- Header: exportations.php / ligne 72
- Première ligne: fonctions_exportations.php / ligne 177
Voir à ce moment là si on a bien de l'UTF-8 dans les données, parce que pour l'instant, c'est pas gagné

Voir les autres formats par la même occasion. Un grep "8859" serait salutaire

Message par **Dominique** » 07 févr. 2013, 21:51

sly a écrit :...mais le header http prend le dessus de toute façon...

Ha ben oui, bien sur ! je me disais bien que j'avais oublié qquchose

Message par **sly** » 07 févr. 2013, 22:03

Dominique a écrit :Faudra changer l'encodage du header et de la première ligne des exportations GPX
<?xml version="1.0" encoding="iso-8859-1" standalone="no"?>
- Header: exportations.php / ligne 72
- Première ligne: fonctions_exportations.php / ligne 177

Voilà qui est changé pour le gpx, j'ai normalement passé presque tout en revue avec un grep (il m'en reste un dans le forum)

Dominique a écrit : Voir à ce moment là si on a bien de l'UTF-8 dans les données, parce que pour l'instant, c'est pas gagné

ha bon ? où ?

Message par **Dominique** » 07 févr. 2013, 22:21

sly a écrit :Voilà qui est changé pour le gpx, j'ai normalement passé presque tout en revue avec un grep (il m'en reste un dans le forum)

Sarbi: j'obtiens toujours
<?xml version="1.0" encoding="iso-8859-1" standalone="no"?>

sly a écrit :
Dominique a écrit : Voir à ce moment là si on a bien de l'UTF-8 dans les données, parce que pour l'instant, c'est pas gagné
ha bon ? où ?

Et un fichier encodé ANSI
Si je change l'encodage en UTF, les é passent en hexa

Message par **sly** » 07 févr. 2013, 22:26

Dominique a écrit :
sly a écrit :Voilà qui est changé pour le gpx, j'ai normalement passé presque tout en revue avec un grep (il m'en reste un dans le forum)
Sarbi: j'obtiens toujours
<?xml version="1.0" encoding="iso-8859-1" standalone="no"?>

Vérifie l'url, le lien d'exportation donné re-pointe sur www.refuges.info, qui t'envoi donc de l'iso.
remplace bien www.refuges.info par refuges.letuffe.org

(c'est pas un bug mais une fonctionnalité qui permet à quelqu'un de copier le lien puis de le ré-utiliser dans un autre logiciels qui synchroniserait par exemple des points)

Message par **Dominique** » 07 févr. 2013, 22:46

sly a écrit :remplace bien www.refuges.info par refuges.letuffe.org

Ha ben oui, c'est ballot.
Impec ! j'ai testé tous les caractères hors norme que j'avais vu (sauf Alt+0160 qui ne représente rien)

Alt+0173 correspond à un caractère de césure (-), non affiché

Question qui n'a rien à voir: dans le point http://www.refuges.info/point/2922 Swisstrekker a saisi: 46.— Je suppose que le caractère — représente le Franc Suisse, mais qu'il n'est pas affiché correctement

Message par **Claude Mauguier** » 07 févr. 2013, 23:16

Dominique a écrit : Question qui n'a rien à voir: dans le point http://www.refuges.info/point/2922 Swisstrekker a saisi: 46.— Je suppose que le caractère — représente le Franc Suisse, mais qu'il n'est pas affiché correctement

C'est corrigé en CHF.

Message par **Y.. bo.b.. bob** » 07 févr. 2013, 23:53

sly a écrit : <..>les requêtes spatiales de mysql et sortir plus facilement tous les points d'un massif

Pour les requetes spatiales, euh, la version MySQL > 5.6 qui fait enfin du GIS correctement est surement trop recente ? Paske sinon ca a l'air chaud, mais chaud

... mais banco.

Vous emballez pas sur le SQL hein

, j'en ai jamais fais ailleurs qu'ici, donc le niveau ne s'est pas amélioré et a même régréssé ces derniers temps.
je me retrouve juste dans la même situation qu'en 2001 : 100% du temps disponible pour lire la doc et coder. Et le boulot accomplit sur ce site par tous, anciens et nouveaux-elles me tient tellement à coeur qu'avant de poster un truc, j'ai lu, relu et croisé des tas de docs pendant des heures pour éviter de dire une anerie. Ca pouvait faire gagner du temps à ceux qui en ont moins que moi.

sly a écrit : D'une manière que je n'explique pas, les signe euros et les oe qui étaient pourtant encodés en fruits pourri (WINDOWS-1252) dans la base, se sont

retrouvés, comme par magie, correctement converti en UTF-8 par mon opération mysqldump
ce qui ne cesse de m'étonner, au point de me demander si ça ne cache pas un loup (qui, rappelez-vous, hurle à la lune)

En fait c'est logique, win1252 n'est pas pourri, c'est meme la reference pour mySQL, ils etaient bien encodés. (les createurs de MySQL ont fumé le chichon quand ils ont adoptés win1252 au lieu de iso-8859-15 ).
MySQL a toujours fait de la conversion au vol, et s'est démerdé pour que tout ce qui passait dans ses pattes soit du win1252, en entrée comme en sortie.
partant de la, vu que le comportement de mysqldump est de faire un "SET NAMES UTF8" sans le dire, il convertit.
Comme la base est un bon win1252 bien propre, il convertit en UTF-8 bien propre. comme peut le faire un CONVERT TO.

sly a écrit : <...>A la recherche de zones qui pourraient foirer.

Que des petits bugs discrets :
-sur la page de recherche, les résultats annexes de OSM sont fournis en iso8859-1, alors que le reste de la page est donc en UTF.
Au passage la recherche avec des caractères accentués marche bien ! (recherche "Bassiès" par exemple)
-les URL des "points a proximité" sont apparement codées en UTF, alors que sur le site de prod', elles sont converties en ASCII. AFAIK, il faudrait que ce soit en ASCII, avec de signes %FF pour les caractères hors-ascii. en UTF, ca devrait donc faire un truc du genre "%AA%BB" pour un "é". ca fait coincer les validators mais ca passe quand meme; peut etre simplement parce que tout ce qui suit le "point/NNNN/" est ignoré. rawurlencode() est utilisé ?
-les flux RSS, ont des caractères foireux, on dirait de la triple conversion UTF->ISO->UTF sans doute une phase PHP, ou un SET NAMES UTF8 a la trappe. par exemple: rss/rss.php?jours=5&listeobjets=0-9&listemassifs=0-3
-le navigation carte avec les 2 services de ces BIIIIP de fils de BIIIP de IGN ne marche pas . mais ca doit etre normal et lié au HTTP referer. on dirait une 403 forbidden. C'est normal, c'est des BIIIP de BIIP de BIIIIP de leur mères. Bon. Au lit avec les cachetons maintenant.

Bon c'est cool, J'ai eu un petit passage à vide à regarder les recettes de cocktails Molotov, mais ça va. tout le monde a l'air d'aller bien, j'ai hate de vous (re)voir !

Euh, sly, tu peux m'envoyer les mdp STP ? ( jm@r.i marche toujours ) et passe le bonjour à Madame !

Message par **sly** » 08 févr. 2013, 00:23

Dominique a écrit : Swisstrekker a saisi: 46.— Je suppose que le caractère — représente le Franc Suisse, mais qu'il n'est pas affiché correctement

Pas sûr du tout, j'ai déjà vu cette syntaxe pour désigner une monnaie un vrai "." et un vrai "-" (ou tiret long ou dieu seul sait comme il s'appel en typographie)

Message par **sly** » 08 févr. 2013, 01:39

Whaa punaise, je relis mon message et d'un coup je me souviens pourquoi j'avais pas des bonnes notes en résumé de texte.

Y.. bo.b.. bob a écrit : Pour les requetes spatiales, euh, la version MySQL > 5.6 qui fait enfin du GIS correctement est surement trop recente ? Paske sinon ca a l'air chaud, mais chaud :shock: ... mais banco.

Mon commentaire était plutôt une forme de blague désabusée ;-)
Oui, il est vrai que le code de refuges.info pour la gestion des polygones de type massifs, puis par la suite des pays, département, des "massifs niveau 1" (alpes/pyrénnées/massif central)
puis par la suite encore des réserves naturelles et dans un futur hypothétique des communes (pour savoir laquelle contacter lorsque l'on découvre un problème dans une cabane
communale) se base toujours sur le même code, bien lent, fait à la main en php avec force bidouille et indexes douteux serait largement à reprendre avec un "vrai" sgbd relationnel
mais voilà, 3 fois hélas, mais mysql n'est pas (encore) fait pour ça.

Notez que le mysql utilisé par refuges.info dispose de 3/4 bouts de fonctions spatiales (je viens de le découvrir !) mais rien de standard, tout n'y étant pas.
Les versions plus récentes de mysql ont semble-t-il évoluées sur ce point, mais sans vouloir rentrer dans la théorie du complot, oracle (qui tient mysql) ne semble pas disposer
à trop faire d'effort de peur de concurencer son produit phare.

En clair, et je le vois bien avec openstreetmap, le top dans le libre et en respectant le standard OpenGIS, c'est postresql/postgis. Qu'utilise d'ailleurs camp2camp. Mais voilà, le
déménagement de refuges.info vers une solution à base de postGIS est une toute autre affaire plus complexe encore que la passage à UTF-8 !
- Il faut trouver une plateforme d'hébergement qui en dispose (et pas un truc au rabais sans postGIS ou avec seulement 100Mo de base de donnée)
- Il faut convertir le code de refuges.info pour être compatible
- Il faut refaire les fonctions de calculs spatiaux

bref, un beau projet d'avenir, mais il faut un plan sérieux pour y parvenir.

Vous emballez pas sur le SQL hein :oops: , j'en ai jamais fais ailleurs qu'ici, donc le niveau ne s'est pas amélioré et a même régréssé ces derniers temps.

Et ben ! On aurait pas dit vu que tu sais des choses que j'ignore alors que ça fait 10 ans que je bosse avec mysql ! comme quoi ;-)

je me retrouve juste dans la même situation qu'en 2001 : 100% du temps disponible pour lire la doc et coder.

Je sais pas si je dois dire tant mieux ou ouille ouille ;-)

Ca pouvait faire gagner du temps à ceux qui en ont moins que moi.

Je ne me plains pas, je passe 50% de ma semaine sur refuges.info et openstreetmap réuni, un vrai geek du libre (et j'adore ça !).

Comme la base est un bon win1252 bien propre, il convertit en UTF-8 bien propre. comme peut le faire un CONVERT TO.

à ce propos, si ça le fait bien, on a peut-être intérêt alors à passer par un convert to plutôt qu'un dump et re-dump et vas-y que je remplace l'interclassement dans le dump non ?

Que des petits bugs discrets :
-sur la page de recherche, les résultats annexes de OSM sont fournis en iso8859-1, alors que le reste de la page est donc en UTF.
Au passage la recherche avec des caractères accentués marche bien ! (recherche "Bassiès" par exemple)

Bien vu ! C'est d'autant plus drôle que la base OSM est full UTF-8 et qu'on a été obligé de faire plein de conversion douteuses pour revenir en ISO et que ça nous revient dans les dents
dominique qui s'en est occupé doit savoir comment couper la conversion qui ne doit pas êter bien méchante.

-les URL des "points a proximité" sont apparement codées en UTF, alors que sur le site de prod', elles sont converties en ASCII.
AFAIK, il faudrait que ce soit en ASCII, avec de signes %FF pour les caractères hors-ascii. en UTF, ca devrait donc faire un truc du genre "%AA%BB" pour un "é".
ca fait coincer les validators mais ca passe quand meme; peut etre simplement parce que tout ce qui suit le "point/NNNN/" est ignoré. rawurlencode() est utilisé ?

Sur ce coup là, j'avoue avoir voulu faire le malin. Sur le code en prod tous les caractères hors du champs ascii 7 bits sont convertis é=>e É=>E ç=>c etc.
En passant à UTF-8 je me suis dit aller, faisons les malins, et mettons carrément des accents dans l'url (comme tout ce qui suit le "point/NNNN/" est en effet ignoré, ça devrait passer
même si des internautes se refilent des url par mail, par sms ou pigeon voyageur, les anciennes urls, google et sa recherche)

Mais je peux revenir en arrière à du plus classique (cf la fonction un peu plus haut à base de strtr)

rawurlencode() n'est pas utilisé (je ne connaissais même pas)

-les flux RSS, ont des caractères foireux, on dirait de la triple conversion UTF->ISO->UTF sans doute une phase PHP, ou un SET NAMES UTF8 a la trappe. par exemple: rss/rss.php?jours=5&listeobjets=0-9&listemassifs=0-3

ha ben ouais, on dirait que lui il se chope une conversion de trop, je vais jeter un coup d'oeil.

-le navigation carte avec les 2 services de ces BIIIIP de fils de BIIIP de IGN ne marche pas . mais ca doit etre normal et lié au HTTP referer. on dirait une 403 forbidden.
C'est normal, c'est des BIIIP de BIIP de BIIIIP de leur mères. Bon. Au lit avec les cachetons maintenant. :sleep:

Ouais, ils on tellement peur qu'on se servent de leur carte sans que ça gonfle leurs stats pour dire "si si on fait aussi bien que google" que si le site de provenance n'est pas wri,
walou nada. J'imagine que ça se réparera tout seul dès qu'on sera sur le bon domaine.

Bon c'est cool, J'ai eu un petit passage à vide à regarder les recettes de cocktails Molotov, mais ça va.

Il faut pas boire de cette cochonnerie, le génépy et la vulnéraire (pas plus que la main ne peut contenir ;-) ) ça c'est une bonne recette, et à déguster sur les plateaux de la chartreuse
c'est encore meilleur.
"La plume est plus forte que l'épée" disait albator (oui je sais, chacun sa référence)

tout le monde a l'air d'aller bien, j'ai hate de vous (re)voir !

Pareil ! Et si la passion montagnarde est toujours avec toi, ça pourrait être plus vite que tu ne le crois.

Euh, sly, tu peux m'envoyer les mdp STP ? ( jm@r.i marche toujours ) et passe le bonjour à Madame !

Je t'envoi ça.

véro était à coté de moi au début de mon message, et te renvoi le bonjour.

Message par **Dominique** » 08 févr. 2013, 10:59

sly a écrit :
tout le monde a l'air d'aller bien, j'ai hate de vous (re)voir !
Pareil ! Et si la passion montagnarde est toujours avec toi, ça pourrait être plus vite que tu ne le crois.

Bon ça, très bon

ça sent la 8ièmme....

Message par **Dominique** » 08 févr. 2013, 11:00

-le navigation carte avec les 2 services de ces BIIIIP de fils de BIIIP de IGN ne marche pas . mais ca doit etre normal et lié au HTTP referer. on dirait une 403 forbidden.
C'est normal, c'est des BIIIP de BIIP de BIIIIP de leur mères. Bon. Au lit avec les cachetons maintenant.
Ouais, ils on tellement peur qu'on se servent de leur carte sans que ça gonfle leurs stats pour dire "si si on fait aussi bien que google" que si le site de provenance n'est pas wri,
walou nada. J'imagine que ça se réparera tout seul dès qu'on sera sur le bon domaine.

Oui, il y a une clé par domaine. Idem Swiss (GG faisait ça aussi avant la V3 !)

Message par **sly** » 08 févr. 2013, 14:28

le bug rss est corrigé.

Là, je commence à penser que l'on peut mettre en ligne. Qu'en pensez-vous ?

Il restera de ci de là des petits bugs mais que chacun pourra corriger directement en prod (ça évitera que j'ai ma copie dans mon coin pendant que personne ne peut toucher en prod sous prétexte de perdre dès que j'aurais recopié)

Si oui, je peux faire ça dans la journée, on aura ensuite tout le week end pour débugger ;-)

Par contre, je ne suis pas à l'aise avec l'histoire du "convert to", si quelqu'un peu m'aider à le faire, ok, sinon, ben je fais comme j'ai fais, après tout, ça marche, et comme disait l'autre : le chemin le plus court, c'est celui qu'on connait