[spip-dev] [SPIP Zone] Question de débutant : bug de la fcontion rechercher

cerdic · Mai 18, 2009, 11:56

Euh…

Merci pour la réponse, mais je crois que trouver les articles contenant deux mots (où qu’ils soient titre ou texte) quel que soit l’ordre dans lequel on les a indiqué dans le formulaire de recherche me semble faire partie du minimum qu’on peut demander à un moteur de recherche non ? Par ailleurs, dans les documentations de SPIP, il est indiqué que le moteur devrait retourner les articles dans ce cas là. (pondération par présence de mots dans les différentes parties de l’article.)

En tout cas, ça fonctionnait sur la version 192, et ça ne fonctionne plus sur la 208.

D’autres avis ?

Je n’emet pas un avis, je te donne des faits
C’est discutable, sûrement, mais le fait est que la recherche a été complètement recodée dans la branche 2.0, et fonctionne maintenant comme cela.

Je pense que si tu veux continuer la discussion, il faut le faire sur la liste spip-dev, car cela concerne les fonctions natives de SPIP.

PS : j’ai testé le plugins fulltext qui ne corrige pas le problème.

fil, un avis ?
Cédric

fil · Mai 18, 2009, 12:38

Merci pour la réponse, mais je crois que trouver les articles contenant
deux mots (où qu'ils soient titre ou texte) quel que soit l'ordre dans
lequel on les a indiqué dans le formulaire de recherche me semble faire
partie du minimum qu'on peut demander à un moteur de recherche non ? Par
ailleurs, dans les documentations de SPIP, il est indiqué que le moteur
devrait retourner les articles dans ce cas là. (pondération par présence de
mots dans les différentes parties de l'article.)

On dirait bien que c'est un bug

PS : j'ai testé le plugins fulltext qui ne corrige pas le problème.

"chez moi ça marche"

as-tu bien activé les index fulltext en allant sur la page ecrire/?exec=fulltext

-- Fil

klaus · Mai 19, 2009, 5:14

Effectivement, merci de l'avoir répété
"as-tu bien activé les index fulltext en allant sur la page ecrire/?exec=fulltext"

Je ne vois pas de lien vers cette page dans l'espace privé. Est-ce que j'ai bien regardé?

merci, klaus++

Fil schrieb:

fil · Mai 19, 2009, 7:41

Effectivement, merci de l'avoir répété
"as-tu bien activé les index fulltext en allant sur la page
ecrire/?exec=fulltext"

Je ne vois pas de lien vers cette page dans l'espace privé. Est-ce que j'ai
bien regardé?

Il n'y a rien dans l'espace privé (*), mais la méthode est indiquée dans la doc.

(*) N'hésite pas à l'ajouter

-- Fil

9aa2aa68144b2781ac02 · Mai 28, 2009, 11:31

PS : j'ai testé le plugins fulltext qui ne corrige pas le problème.

"chez moi ça marche"
Résultats de la recherche - Le Monde diplomatique

Chez moi en local, ça marche aussi.

as-tu bien activé les index fulltext en allant sur la page ecrire/?exec=fulltext

En bas j'ai le message « Une incohérence entre le charset de votre site et celui des tables de votre base de données risque de fausser les recherches avec caractères accentués » (j'ai bien une structure historique en ISO avec des contenus UTF-8) et quand je lance la conversion, tous mes accents sont foirés.

Y a t-il une manip MySQL en ligne de commande pour corriger l'encoding mieux que le script PHP proposé ?

-Nicolas

fil · Mai 28, 2009, 12:22

En bas j'ai le message « Une incohérence entre le charset de votre site et
celui des tables de votre base de données risque de fausser les recherches
avec caractères accentués » (j'ai bien une structure historique en ISO avec
des contenus UTF-8) et quand je lance la conversion, tous mes accents sont
foirés.

Ca arrive parfois. J'ai eu deux cas :

1) à la toute fin, on vide les caches et c'est bon

2) à la toute fin, c'est pas bon : là il faut analyser le problème
plus en détails.

Mes notes de la dernière fois que ça m'est arrivé (avant-hier !)

(Je vous fait un résumé comme si j'avais pas galéré 4 heures pour
comprendre dans quel ordre faire les choses)

Le problème : dans la base de données DATABASE,
certaines tables ont des problèmes de charset, *mais pas toutes*.

Comment savoir si la table a un problème :

mysql -u(USER) -p(PASSWORD) DATABASE
SELECT titre FROM spip_articles LIMIT 10;

==> "Les petits mÃ©tiers clandestins"

ici on devrait avoir un "é" et pas "Ã©".

Pour résoudre ça, SPIP propose un outil de conversion efficace :
?exec=convert_sql_utf8

Une fois cette conversion appliquée, j'ai constaté que trois tables de
la base étaient en fait *doublement* en utf8, c'està-dire que le é,
qui en binaire s'écrit Ã©, est devenu (en binaire toujours), "ÃCÂ©",
qui correspond à la conversion utf8 de la chaine iso "Ã©". Donc 4
caractères en binaire, alors qu'il en faut deux. Du coup après
conversion, les tables en question se retrouvaient à afficher des
"Ã©". Vous me suivez ?

Ces trois tables : spip_articles, spip_auteurs, spip_mots : sans doute
lié à notre méthode d'importation initiale des données.

J'ai fait un dump de ces tables en précisant que je voulais un
dump "latin1", histoire d'avoir (en binaire) dans mon fichier dump la
chaîne "Ã©".
# mysqldump --opt --default-character-set=latin1
DATABASE spip_articles spip_auteurs spip_mots >
latin1.sql

Ensuite dans le dump (latin1.sql) j'ai remplacé (avec un éditeur de
texte tout bête) la chaîne :
/*!40101 SET NAMES latin1 */;
en
/*!40101 SET NAMES utf8 */;

puis j'ai réimporté le fichier dump.
# mysql DATABASE < latin1.sql

En important ce fichier MySQL a lu "Ã©" comme étant bien le
caractère "é" en utf8. Ouf.

-- Fil

9aa2aa68144b2781ac02 · Mai 28, 2009, 4:29

En bas j'ai le message « Une incohérence entre le charset de votre site et
celui des tables de votre base de données risque de fausser les recherches
avec caractères accentués » (j'ai bien une structure historique en ISO avec
des contenus UTF-8) et quand je lance la conversion, tous mes accents sont
foirés.

Ca arrive parfois. J'ai eu deux cas :

1) à la toute fin, on vide les caches et c'est bon

Chez moi le cache n'y faisait rien.

2) à la toute fin, c'est pas bon : là il faut analyser le problème
plus en détails.

Mes notes de la dernière fois que ça m'est arrivé (avant-hier !)

(Je vous fait un résumé comme si j'avais pas galéré 4 heures pour
comprendre dans quel ordre faire les choses)

Le problème : dans la base de données DATABASE,
certaines tables ont des problèmes de charset, *mais pas toutes*.

Comment savoir si la table a un problème :

mysql -u(USER) -p(PASSWORD) DATABASE
SELECT titre FROM spip_articles LIMIT 10;

==> "Les petits mÃ©tiers clandestins"

ici on devrait avoir un "é" et pas "Ã©".

Pour résoudre ça, SPIP propose un outil de conversion efficace :
?exec=convert_sql_utf8

Une fois cette conversion appliquée, j'ai constaté que trois tables de
la base étaient en fait *doublement* en utf8, c'està-dire que le é,
qui en binaire s'écrit Ã©, est devenu (en binaire toujours), "ÃCÂ©",
qui correspond à la conversion utf8 de la chaine iso "Ã©". Donc 4
caractères en binaire, alors qu'il en faut deux. Du coup après
conversion, les tables en question se retrouvaient à afficher des
"Ã©". Vous me suivez ?

Ouah ! Ca se tient, bien vu !

Personnellement, je vois le problème dans l'interface Web avec SPIP, que ce soit dans ecrire/ ou sur le site avec la dist, alors que mysql en ligne de commande me montre les accents comme il faut.

Ces trois tables : spip_articles, spip_auteurs, spip_mots : sans doute
lié à notre méthode d'importation initiale des données.

J'ai fait un dump de ces tables en précisant que je voulais un
dump "latin1", histoire d'avoir (en binaire) dans mon fichier dump la
chaîne "Ã©".
# mysqldump --opt --default-character-set=latin1
DATABASE spip_articles spip_auteurs spip_mots >
latin1.sql

Ensuite dans le dump (latin1.sql) j'ai remplacé (avec un éditeur de
texte tout bête) la chaîne :
/*!40101 SET NAMES latin1 */;
en
/*!40101 SET NAMES utf8 */;

puis j'ai réimporté le fichier dump.
# mysql DATABASE < latin1.sql

En important ce fichier MySQL a lu "Ã©" comme étant bien le
caractère "é" en utf8. Ouf.

Je viens de faire la manipulation juste sur la table spip_articles et effectivement ça me corrige l'affichage dans SPIP, mais en même temps je me retrouve avec des "?" à la place des accents en ligne de commande.

Plus étrange, j'ai bien fait la manip uniquement sur spip_articles, mais c'est aussi corrigé, dans SPIP, pour les autres données !

C'est à y perdre son latin....

-Nicolas

cerdic · Mai 28, 2009, 4:46

La difficulté de la question est qu'on ne voit jamais comment est stocké l'info dans la base, car :
- l'info est stockée dans un charset par mysql
- elle est rendue a la connexion dans un autre charset, celui de la connexion
- elle est affichée par un périphérique avec un 3ème charset

Autrement dit, pour que ça marche, il faut que le charset de la connexion et celui de l'affichage soient identiques.
Si ta console est iso mais ta connexion sql est utf ou le contraire cela peut "sembler marcher".

Tous nos ennuis viennent ici du fait qu'avant SPIP 2.0 :
spip stockait en base l'info en envoyant de l'utf mais sans s'occuper du charset de la connexion.
Du coup si la connexion est en iso, mysql prend ce qui arrive poru de l'iso, et le reencode.
Tant que tout reste comme ça ça va, mais les problèmes arrivent en général lors des changements de configuration.

Depuis SPIP 2.0, on fixe bien le charset des tables, de la connexion, et du site.
Les nouvelles installations sont donc bien carrées sur ce point, mais les migrations hasardeuses du fait de la combinatoire.

Je conseille généralement après une migration réussie, de faire un dump, une installe neuve de SPIP, et de réimporter dans la base neuve.
C'est le seul moyen d'avoir une base propre et bien déclarée du point de vue du charset.

Cédric

JLuc · Mai 28, 2009, 7:12

cedric.morin@yterium.com a écrit :

Je conseille généralement après une migration réussie, de faire un dump, une installe neuve de SPIP, et de réimporter dans la base neuve.
C'est le seul moyen d'avoir une base propre et bien déclarée du point de vue du charset.

Et pour être sur de réussir la migration, quelle serait ta recommmandation ?
JL