[Terminé] Encodage: latin1, ISO et CP1252

[ybob]

En 2 mots, les pages HTML envoyées, ainsi que les GPX sont encodées en WINDOWS-1252, et pas en ISO-8859-1.
elles sont pourtant annoncées comme tel.

La plupart du temps ca passe parce que:
-Firefox et ses amis sont gentils et corrigent tout seuls
-les deux charset sont très proches (seuls E (euro) et (oe) diffèrent en gros).

J'ai le cas d'une appli qui ne peut pas lire les GPX à cause de cela (c'est vrai, son parser est fragile )
Pour faire le test et savoir si le client tolère cette erreur, il suffit d'aller voir la page:
http://www.refuges.info/point/3127
Si "Les Deux Soeurs" affichent bien le "O dans l'E", c'est bon.

Pourtant, le OE est ici codé en 0x9C. Ce qui n'existe ni dans la ISO-8859-1, ni dans la ISO-8859-15 (ou il devrait etre en 0xBD)
Le fichier envoyé est encodé en Windows-1252, ce qui n'est pas conforme à l'entête.
(En forcant l'encodage en ISO-8859-15, le caractère se fait bouffer car ce n'est pas le bon (0x9C au lieu de 0xBD).)

C'est vérifié en testant un export GPX:
$ file -bi vercors.gpx
application/xml; charset=unknown-8bit


la base de donnée de MySql est encodée en latin1_????_ci (http://collation-charts.org/mysql60/)
chez MySQL, le latin1 ne correspond ni à ISO-8859-1, ni à 8859-15, mais bien à WINDOWS-1252.

Donc en théorie, il ne faudrait pas servir des infos brut de MySQL sous l'etiquette ISO-8859-??, mais sous celle de windows-1252. Pas courant.

Maintenant, vu que les charset Windows, c'est pas top pour plein de raisons, la solution c'est l'UTF8.

Et c'est là qu'on entend une longue plainte du loup dans les montagnes a propos de ce vieux serpent de mer qui ressort ...
Car une migration de charset, ça promet un bordel sans nom...
mais bon. Si je peux aider...

=== UNICODE UTF8 ===
Quelques infos que j'ai découvert, surement déja connues:

utf8_unicode_ci est a la lecture des documents la collation ideale (utf8_general_ci est a eviter).

Une premiere solution pour laisser toutes les requetes telles quelles:
http://blog.oneiroi.co.uk/mysql/mysql-f ... nnections/

Apres ne reste que les header XML/HTML a modifier, faudrait que ce soit centralisé ...

de la doc sur les charset/collation:
http://mysql.rjweb.org/doc.php/charcoll

un script un peu complexe qui est censé tout faire, meme les cas foireux
http://www.mysqlperformanceblog.com/200 ... cter-sets/

=== Fausse autre solution ===
Passer en ISO-8859-15, qui lui gère le OE et euro, est une fausse idée.
MySQL ne connait pas du tout cette norme. pour lui c'est ou bien du latin1(cp1252), ou de l'unicode.
il faudrait déplacer le euro/OE a un endroit incohérent pour MySQL, ce qui rendrait toute future migration sous UTF8 impossible. Dommage car les champs dans la DB sont bien et cohérent, mais en cp1252.
A moins qu'une conversion au vol soit possible.

=== STATU QUO ===
Hormis le non-respect des standards.
concernant la partie Web, le risque est limité à 2 caractères qui de temps en temps ne s'affichent pas, ca c'est pas grave, le browser fait avec.
Ca se voit plutot sur les exports, puisque là ça fait planter tout le fichier pour un pauvre caractère.
Ou alors passer des moulinettes qui se débarassent des E et des OE. mais c'est sale.
Une moulinette : http://www.cylman.com/nettoyer-l-encoda ... _qr11.html

Qu'en pensent les experts ?

[Claude Mauguier]

...mais c'est sale. .Qu'en pensent les experts ?

Sale, un ours ....?

[Dominique]

Salut

Merci pour ce long commentaire très bien documenté.
Nous (les 2 programmeurs actuels : Sly & moi) sommes tout à fait conscients de cette difficulté.

Le site est en effet diffusé en charset=iso-8859-1 (parce que on écrit en Français que diable)
et les texte de la base sont archivés en latin1_swedish_ci (parce qu'une partie du sité est basée sur PHPBB, après une une installation initiale en version française)
Nous héritons donc:
- de l'acrobatique conversion utf8_unicode_ci => UTF8 interne à PHPBB
- du repliement sur iso-8859-1 au moment de l'envoi de la page (j'ignore personnellement grâce à quelles conversions)

On s'est effectivement colletiné quelques problèmes de compatibilité (il doit y en avoir 5 ou 6 dans les différents forum).
En ce qui me concerne, pour la partie en javascript traitant les cartes (issue d'OpenLayers), j'ai fini par quelques traductions en dur du contenu de quelques messages qui, s'ils ont l'air de marcher au final, ne sont pas très propres.

Je n'avais pas vu le coup du Windows-1252 et de ses quelques différences, mais ça ne m'étonne pas. Merci pour cette remarque.

Je suis personnellement d’accord sur le fait qu'on aurait plus de cohérence à tout passer en UTF8, au moins l'envoi des pages (je laisse Sly compléter, il me semble avoir lu récemment un commentaire de sa part dans ce sens)

Mais, mais, mais, c'est effectivement là qu'on entend une longue plainte du loup dans les montagnes a propos de ce vieux serpent de mer qui ressort ... Car une migration de charset, ça promet un bordel sans nom...
Pour l'instant, aucun n'a osé jeter un coup d'oeuil en dehors du sac de couchage, tant le froid intense et piquant émanant de cet imbroglio nous incite à 1/4 d'heure de plus dans le confort douillet de notre iso-8859-1

Je suis tout à fait favorable, en ce qui me concerne, puisque tu sembles avoir les compétences et courage requis, que tu nous donnes un coup de main
- soit pour compléter les quelques conversions manquantes
- soit pour regarder ce que donnerait une conversion complète (peut être faire une maquette indépendante du site de production dans un premier temps). Mon seul bémol serait pour reprendre le code PBPBB qui converti ce qui vient de sa base latin1_swedish_ci (On essaye de toucher le moins possible au CORE PHPBB).

Je laisse Sly compléter et conclure

[Dominique]

Pour parer au plus pressé, en ce qui concerne les exportations, j'ai replié en dur les caractères latin1_swedish_ci n'existant pas en ISO-8859-1 en quelque chose de lisible
'œ' => 'oe',
'Œ' => 'OE',
'Ÿ' => 'Y',
'š' => 's',
'Š' => 'S',
'„' => '"',
'“' => '"',
'€' => 'Euros',
Dis moi si ça passe dans ton parser fragile (je reconnais que certains GPS et leur logiciels associés sont quelque peu sourcilleux )

Bon c'est pas encore de l'UFT8 mais au moins du vrai ISO-8859-1. Tant qu'a faire bœuf, autant le faire bien

[Invité]

Merci d'avoir regardé ça Dominique ! C'est pas vraiment urgent non plus hein...
ça passe ni le parser HTML, ni l'export GPX ...
En fait, je vois pas de changement
les caractères sont toujours là.

Pour le parser, celui du W3C en bas de page ne detecte pas les erreurs d'encodage (je suis déçu mais déçu ! )
celui la si : http://www.validome.org il suffit d'y valider les fiches refuges suspectes, comme le refuge des cretes http://www.refuges.info/point/3127/ pour voir apparaitre les erreurs d'encodage.

Il y a qq jours, j'ai fait quelques petites statistiques sur un export GPX assez large de 2000 points: (donc sans les commentaires)
NombreOccurences CodeHexa Caractere
491 92 ' (apostrophe de typo)
289 80 euro
61 96 - (petit tiret du milieu)
16 85 ... (trois-petits-points)
13 95 * (pastille)
5 9C oe
4 97 -- (gd tiret du milieu)
2 93 " (guillemets ouvrants)
2 91 ' (apostrophe ouvrante)
1 94 " (guillemets fermants)
1 8C OE
1 84 ,, (double virgule ou guillemet du bas)

sur environ 2 millions de caracteres

Il y en a des bizarres, comme le caractere ... "3-petits-points", perso, je l'ai pas sur mon clavier ...

A ce que j'ai lu sur le net, MS Word exploite a fond ce charset cp1252, car il permet de mieux respecter les regles de typographie françaises ( par exemple les apostrophes simple des touches 4 ou 7 ne sont pas correctes de ce point de vue, il parait qu'il faut que l'apostrophe soit plus courbée, donc cp1252 0x92).
Ces caractères peuvent apparaitre quand Word fait de la correction automatique de grammaire, par exemple c'est courant pour les 3 points "...".
Ils seraient ensuite venus dans la DB lors d'un import ou copier/coller.

Bien vu le phpBB/BBcode, j'avais oublié ... je connais pas du tout ...

[Dominique]

Salut

D'abord, je n'ai corrigé que les exports GPX (pour ne pas perturber les parsers), pas les pages (qui s'affichent autant que je sache bien avec les dernières versions de la plupart des explorateurs actuels). Donc normal qu'il y ait encore des erreur (Corrections à faire)

J'ai ajouté la conversion des petit tiret du milieu, trois-petits-points, pastille, gd tiret du milieu, apostrophe ouvrante que je n'avais pas vu. Bien vu, merci
Bien vu aussi le validome (je ne connaissais pas)

Enfin, je ne vois plus de caractères spécifiques dans les exportations GPX (mais je n'ai pas d'outil pour). Peux tu réessayer? Par exemple avec l'exportation la plus complète.

[ybob]

Merci!

Code : Tout sélectionner

$ file -bi wri.gpx
application/xml; charset=iso-8859-1

c'est bon !

Si c'est pas modifié, ni en base, ni en web, ca veut dire que tu fais une conversion speciale, uniquement pour les exports ? Aie !
mais au moins ça marche.

Le soft au parser fragile s'appelle OruxMaps, sur Android. il est assez utilisé. je suis étonné qu'il n'y ait pas eu d'autres plaintes. C'est les exports qui doivent pas être très utilisés alors.

[sly]

Salut,

J'arrive un peu tard et je ne sais pas si ce que je vais dire sera valable à cause des corrections déjà apportées entre temps. Mais tout d'abord un grand merci pour cette fine analyse qui aura le mérite de nous remettre sur la seule voie d'avenir valable : UTF-8 (Mais ouille ouille ouille, que ça risque d'être compliqué !)

En 2 mots, les pages HTML envoyées, ainsi que les GPX sont encodées en WINDOWS-1252, et pas en ISO-8859-1.
elles sont pourtant annoncées comme tel.

C'est un peu plus compliqué que ça je crois mais je n'en saisi pas toutes les subtilités.
Les pages du site et les gpx sont en effet annoncées comme étant encodés en ISO-8859-1 car c'est le but. Notre base de données est prévue pour contenir cet encodage et toutes les pages, actuellement, ne devraient renvoyer que du contenu encodé en ISO-8859-1 uniquement.
Et c'est... presque le cas ;-)

Seulement, et je ne parviens pas à l'expliquer mais je viens de le constater à l'instant: si dans firefox je "force" l'ajout d'un commentaire avec un oe lié alors que l'encodage ISO-8859-1 ne le contient justement pas, firefox (au moins) semble prendre la liberté de l'envoyer encodé en 0x9C là où je me serais attendu à l'envoi, soit de le convertir en o+e soit, à la limite, comme il l'aurait fait si on avait envoyé un kandji japonais par exemple (testez), encodé en entité HTML : & #339 ; mais ça n'est pas le cas.

Notre base se retrouve donc "polluée" par des caractères non contenu dans le charset ISO-8859-1 que des contributeurs ont rentré en toute bonne foi.

Ma déduction (non confirmée) serait que les navigateurs et leur fonctionnement un peu trop "holé holé" sont responsables de 3 erreurs qu'il me semble avoir vu :
le oe, le signe euro (même cause, même effet) et l'apostrophe français qui semble (semblait ?) être ajouté par les navigateurs safari sur mac.

la base de donnée de MySql est encodée en latin1_????_ci (http://collation-charts.org/mysql60/)
chez MySQL, le latin1 ne correspond ni à ISO-8859-1, ni à 8859-15, mais bien à WINDOWS-1252. :evil:

Donc en théorie, il ne faudrait pas servir des infos brut de MySQL sous l'etiquette ISO-8859-??, mais sous celle de windows-1252. Pas courant.

Voilà une hypothèse intéressante, mais je ne suis pas sûr d'y adhérer ;-)
Mais peut-être que mes compétences mysql sont ici insuffisantes. De ce que je comprenais, pour Mysql il n'y a pas de notion d'"encodage" lors du stockage. Peut-importe ce qu'on lui insère par un "INSERT" lors du "SELECT *" il renverra la même chose que ce qu'on lui a donné, on pourrait donc y mettre de l'utf-8 que ça marcherait quand même.

Le choix pour l'interclassement ou "collation" ayant pour but d'informer mysql de l'encodage du champ afin de lui permettre de faire marcher des requêtes comme where "a" like "A" ou de calcul de longueur de champs texte

M'enfin bref, peut-importe à qui la faute, on est emmerdé, et il faut bien tenter de s'en tirer, et je ne peux qu'aller dans ton sens, oui mille fois à UTF-8, mais comme l'a dit domnique et je le confirme aïe.
Conversion, vérif, tests, phpBB, ça ne va pas être simple du tout, mais je suis pour de tenter le coup.

Et c'est là qu'on entend une longue plainte du loup dans les montagnes a propos de ce vieux serpent de mer qui ressort ... :mouton:
Car une migration de charset, ça promet un bordel sans nom...
mais bon. Si je peux aider...

J'aime bien l'image du loup qui hurle à la lune, car ça risque de ressembler un peu à ça ;-)

[sly]

Je laisse Sly compléter et conclure

Je crois que tu as tout dis, il faut tester et je suis prêt à participer pour corriger mes bouts de codes que je connais qui ne doivent pas manquer de ci de là à faire du ISO->UTF-8 parce que certaines portions du site en ont besoin

[Dominique]

J'ai fait quelques recherches complémentaires:

En effet ni SQL ni PHPbb ne touchent à l'encodage des caractères (bien vu Sly)
Le paramètre "interclassement" (= latin1_swedish_ci) sur les champs de TEXT SQL ne joue que sur les tris ou les recherches
Le seul paramètre gérant les charset est celui envoyé par le header qui configure l'explorateur dans la langue correspondante (iso-8859-1 = une langue latine quelconque)
Tant que le charset utilisé pour la saisie et l'affichage est le même on obtient le bon rendu
La majorité des explorateurs actuels (vérifié avec IE, FF, Opera et Chrome) se replient correctement, saisissent et affichent tous les caractères non spécifiées par iso-8859-1 (œ Œ Ÿ š Š „ “ €)

Bémols:
- En annonçant avec ce charset on peut avoir des comportements bizarres avec ces caractères non supportés, comme par exemple avec OruxMaps Android
- Il se peut qu'il y ait dans la base des caractères saisis avec une vielle version d'un explorateur (il y a longtemps, ou par quelqu'un n'upgradant pas souvent son logiciel, suivez mon regard) et donc mal encodés. Dans ce cas, on peut avoir un affichage différent de celui souhaité (je n'ai pas vérifié s'il y en a)

Pour passer en UTF-8, selon moi, il faudrait:
- Changer le charset dans le header en "UTF-8" (3 secondes). Idem dans le ou les headers des extractions
- Encoder tous les fichiers sources contenant des textes affichables (PHP, templates, fichiers langages PHPbb) en UTF8 au lieu d'ANSI (ouvrir avec un éditeur prenant en compte les encodages, copier tout, changer l'encodage en UTF-8, coller, sauver)
- Passer des moulinettes sur les champs texte du SQL pour transcoder les caractères iso-8859-1 en UTF-8 (export SQL + copier/coller en changeant l'encodage + import ou moulinette str_replace PHP ?)
- Virer toutes les bidouilles qui transcodent quelque chose

Tu vois autre chose ?
On tente ?

[ybob]

Salut Sly

Salut,
Notre base se retrouve donc "polluée" par des caractères non contenu dans le charset ISO-8859-1 que des contributeurs ont rentré en toute bonne foi.

Ca c'est capital. Si elle est polluée, ca va merder a fond lors du changement de charset/collation.
mais caractères hors ISO-8859-1 ne veut pas dire polluée, puisque ce n'est pas le charset de MySQL. son charset est latin1_ (= cp1252).
Si elle est clean (en latin1_swedish s'entends), la conversion se résume à un simple "ALTER TABLE", MySQL faisant tout seul la conversion vers UTF8.
Au vu des exports GPX, elle a l'air clean. c-a-d que tous les caractères sont bien ce qu'ils doivent etre en latin1swedish.
le latin1 de MySQL (cp1252) n'est pas le Latin1 tel qu'on l'entends habituellement (iso88591). La collation "swedish" n'a aucune importance. (je fais le malin mais j'ai découvert ça il y a tout juste 1 semaine )

Ma déduction (non confirmée) serait que les navigateurs et leur fonctionnement un peu trop "holé holé" sont responsables de 3 erreurs qu'il me semble avoir vu :
le oe, le signe euro (même cause, même effet) et l'apostrophe français qui semble (semblait ?) être ajouté par les navigateurs safari sur mac.

+1 .
La page arrive en 8859-1. le gars rentre un commentaire avec un euro, en théorie, ca devrait bipper alors même qu'il tappe sur la touche "euro".
Car c'est un caractère interdit en 8859-1.
Si le navigateur laisse passer ça, et il le font tous, il sait qu'il va devoir magouiller. A mon avis, la magouille consiste à passer en 8859-15 ou cp1252 ou même unicode silencieusement.
mais ce qui compte, c'est que Mysql ait bien convertit vers du latin1swedish, et ça a l'air d'etre le cas.
L'autre charset qui risquerait de se trouver c'est 8859-15.
Pour s'assurer que la base est clean, une solution serait de chercher le caractère 0xA4 et son contexte: en 8859-15, c'est euro, en latin1_swedish_1252, c'est la puce ¤.
Plus facile à dire qu'a faire: aussi bien mysql_query que phpmyadmin se font leurs petites conversions de charset au vol.

la base de donnée de MySql est encodée en latin1_????_ci (http://collation-charts.org/mysql60/)
chez MySQL, le latin1 ne correspond ni à ISO-8859-1, ni à 8859-15, mais bien à WINDOWS-1252.

Donc en théorie, il ne faudrait pas servir des infos brut de MySQL sous l'etiquette ISO-8859-??, mais sous celle de windows-1252. Pas courant.

Voilà une hypothèse intéressante, mais je ne suis pas sûr d'y adhérer

cf lien donné et wikipedia, compare les tables hexa ... C'est vrai que mettre un content-type: Windows-1252 (cp1252) , ca fait peur

De ce que je comprenais, pour Mysql il n'y a pas de notion d'"encodage" lors du stockage. Peut-importe ce qu'on lui insère par un "INSERT" lors du "SELECT *" il renverra la même chose que ce qu'on lui a donné, on pourrait donc y mettre de l'utf-8 que ça marcherait quand même.

En pratique, on pourrait négliger le charset associé et gérer le TEXT/VARCHAR comme si c'etait un BLOB. on peut enregistrer de l'UTF dans un VARCHAR L1swedish. ca marche mais apres il faut laisser tomber toute idée de ALTER TABLE CHARSET, qui foutra une pagaille mémorable, ou de collation.
selon la doc,
http://dev.mysql.com/doc/refman/5.0/fr/ ... ction.html
c'est les variable set_character_set_results/client qui definit ce comportement,
Il peut, ou pas, convertir, mais souvent il convertit apparemment.
Par exemple, ce qui a du déja arriver, lors d'un INSERT, MySQL regarde la valeur de "character_set_client" et convertir les donnée pour les rentrer chez lui. si il voit arriver un OE avec un encodage 8859-15, il le déplacera en cp1252 (0x8* et 0x9*).

Si l'etat actuel est cohérent , un ALTER TABLE ... CHARSET ... COLLATION va tout convertir en UTF automatiquement.

Après, par défaut, mysql_query() gère le latin1, donc il faut a chaque session, faire un "SET NAMES UTF-8" après le connect(). relou, mais AFAIK pas moyen d'y couper.
cette commande va forcer les variable d'échanges avec mysql (set_characterset_*) à UTF-8. ainsi, si Mysql voit arriver autre chose, il le transformera en UTF avant de le stocker.

Ce qui est dommage, c'est que mysql raisonne encore, par defaut, en latin1, faut passer tout un tas de ALTER DATABASE/TABLE/COLUMN ...
ou alors modifier le my.cnf et y modifier les default-character-set/cnx/result/database...
le PHP risque bien de raisonner en 8859-1 par defaut aussi, je connais pas mais peut etre "setlocale(LC_ALL, 'fr_FR.'UTF-8'); "

Pour passer en UTF-8, selon moi, il faudrait:
- Changer le charset dans le header en "UTF-8" (3 secondes). Idem dans le ou les headers des extractions

y compris le Content-type du header HTTP et exports XML
header('Content-Type: text/html; charset=utf-8');

- Encoder tous les fichiers sources contenant des textes affichables (PHP, templates, fichiers langages PHPbb) en UTF8 au lieu d'ANSI (ouvrir avec un éditeur prenant en compte les encodages, copier tout, changer l'encodage en UTF-8, coller, sauver)
- Passer des moulinettes sur les champs texte du SQL pour transcoder les caractères iso-8859-1 en UTF-8 (export SQL + copier/coller en changeant l'encodage + import ou moulinette str_replace PHP ?)

Si c'est cohérent, et phpmyadmin est moins fiable qu'un dump à cause de ses conversions web , un simple ALTER suffit. pas de str_replace... MySQL fait déjà de la conversion de charset. Sauf pour les BLOB, ça il y touche pas.

Pfiouu, C'est un sacré bazar ces encodages! Je bouffe de la doc en ce moment !

[Dominique]

Si elle est clean (en latin1_swedish s'entends), la conversion se résume à un simple "ALTER TABLE", MySQL faisant tout seul la conversion vers UTF8.

? je ne connais pas. Il faut que je regarde

Au vu des exports GPX, elle a l'air clean. c-a-d que tous les caractères sont bien ce qu'ils doivent etre en latin1swedish.

Non car je retraite les caractères avant de les envoyer. Je n'ai pas réglé le pb de fond

En pratique, on pourrait négliger le charset associé et gérer le TEXT/VARCHAR comme si c'etait un BLOB. on peut enregistrer de l'UTF dans un VARCHAR L1swedish. ca marche mais apres il faut laisser tomber toute idée de ALTER TABLE CHARSET, qui foutra une pagaille mémorable, ou de collation.

Neni car on a un forum PHPbb qui est aussi comme ça. Et, même si on fait ça pour nos fiches, je ne pense pas que ce soit une bonne idée de charcuter le forum

[sly]

Pour passer en UTF-8, selon moi, il faudrait:
- Encoder tous les fichiers sources contenant des textes affichables (PHP, templates, fichiers langages PHPbb) en UTF8 au lieu d'ANSI (ouvrir avec un éditeur prenant en compte les encodages, copier tout, changer l'encodage en UTF-8, coller, sauver)

Je peux m'occuper de cette phase, avec linux, c'est assez facile et j'ai l'outil pour ça qui marche bien :
Tu lui donnes un dossier, et il converti chaque fichier texte dedans d'un encodage à un autre.

- Passer des moulinettes sur les champs texte du SQL pour transcoder les caractères iso-8859-1 en UTF-8 (export SQL + copier/coller en changeant l'encodage + import ou moulinette str_replace PHP ?)

Je propose (à discuter) l'opération suivante :
export SQL de tout dans un seul fichier, conversion d'iso-8859-1 vers UTF-8 *, remplacement des inter-classement latin1 vers utf8 et ré-import du fichier

Tu vois autre chose ?
On tente ?

Oui, mais à condition de bien faire une sauvegarde complète avant.

* Note à creuser : Il faut se rappeler que la base contient des fruits pourris en WINDOWS-1252, ce qui veut dire qu'il reste possible que la conversion ne se passe pas correctement. On peut donc tenter deux conversion : de iso -> utf8 ou de WINDOWS-1252 -> utf8
La question étant de savoir si nous avons, en base, un seul et unique encodage utilisé. Ce qui est loin d'être certain.

ybob ? toi qui semble avoir un outil d'analyse d'encodage, peut-on te fournir un dump sql total que tu fasses tourner ta moulinette et nous dire si, selon toi, toute notre base peut être considérées comme n'ayant que des caractères valides en WINDOWS-1252 ?

[Dominique]

Il faut se rappeler que la base contient des fruits pourris en WINDOWS-1252, ce qui veut dire qu'il reste possible que la conversion ne se passe pas correctement. On peut donc tenter deux conversion : de iso -> utf8 ou de WINDOWS-1252 -> utf8
La question étant de savoir si nous avons, en base, un seul et unique encodage utilisé. Ce qui est loin d'être certain.

Sur que non: on a toutes les merdes que les différents explorateurs ont bien voulu nous envoyer depuis 10 ans
Par contre, on peut faire un recenssement

[sly]

si quelqu'un veut se lancer dans un analyse, le dump de la base est disponible et je peux vous en donner une copie en privée pour analyse

(les mots de passe forum sont hachés donc je ne m'inquiètes pas trop, mais on y trouve tous les emails des membres, je préfère donc opter pour la non publication et je compte sur vous pour une utilisation "technique" de cette base)