utf-8 et regex + car accentués, chez Free
Bonjour à tous,
Quelqu'un a-t'il déjà approfondi l'utf-8 chez Free ?
je rencontre un soucis qui provient apparemment de la structure des caractères accentués utf-8 coté serveur.
Tout d'abord, je voulais améliorer un peu le moteur de recherche que j'utilise (pas de mots tronqués dans le résumé, une présentation différente du résultat, la prise en compte des limites de mots ...) en tenant compte du fait que j'utilise ckeditor qui ne génère que des entités html (au fait, peut-on le 'passer' en utf-8 ?) ce qui m'oblige a ré-encoder.
Pour résumer, le texte utilisé par le moteur de recherche est bien en utf-8, le mot recherché aussi.
En local, tout fonctionne.
En distant (chez Free), si je cherchais 'été' par exemple, le moteur matchait 'été' mais aussi 'météo'..., bref les limites de mot \b ne fonctionnaient pas.
Enfin, presque pas : si le mot recherché ne comportait aucun caractères accentués à ses extrémités, ça marchait !
j'essaie alors la classe \W (Tout autre caractère qu'un caractère de mot) qui fonctionne en distant bien qu'il y ait tout de même un soucis:
Par exemple, le mot 'déjà' existe. Je le trouve aussi en recherchant 'déj'. Idem pour le mot 'trouvé' qui apparait en résultat de 'trouv'
(évidemment, en local, cela ne se produit pas). C'est la solution que j'ai laissé en place sur le blog pour l'instant.
Je suppose qu'il y a donc une différence entre la table utf-8 de mon serveur local et celle de Free ?
en plus, lclocale fait partie des fonctions interdites chez Free (et donc setlocale(LC_CTYPE, 'fr_FR.utf8'); ne risque pas de faire la différence). J'ai d'ailleurs dû ajouter \u derrière chaque regex pour que cela fonctionne correctement.
Je m'étais déjà bien amusé avec les regex (Ici sous GuppY) et bien que c'était en iso-8859-1, j'avais eu également des soucis avec les limites de mots en présence d'entités html ou numériques... Mais là, pour l'utf-8, je bloque !
Si vous avez une explication, je suis preneur
Cordialement,
Ludo
Quelqu'un a-t'il déjà approfondi l'utf-8 chez Free ?
je rencontre un soucis qui provient apparemment de la structure des caractères accentués utf-8 coté serveur.
Tout d'abord, je voulais améliorer un peu le moteur de recherche que j'utilise (pas de mots tronqués dans le résumé, une présentation différente du résultat, la prise en compte des limites de mots ...) en tenant compte du fait que j'utilise ckeditor qui ne génère que des entités html (au fait, peut-on le 'passer' en utf-8 ?) ce qui m'oblige a ré-encoder.
Pour résumer, le texte utilisé par le moteur de recherche est bien en utf-8, le mot recherché aussi.
En local, tout fonctionne.
En distant (chez Free), si je cherchais 'été' par exemple, le moteur matchait 'été' mais aussi 'météo'..., bref les limites de mot \b ne fonctionnaient pas.
Enfin, presque pas : si le mot recherché ne comportait aucun caractères accentués à ses extrémités, ça marchait !
j'essaie alors la classe \W (Tout autre caractère qu'un caractère de mot) qui fonctionne en distant bien qu'il y ait tout de même un soucis:
Par exemple, le mot 'déjà' existe. Je le trouve aussi en recherchant 'déj'. Idem pour le mot 'trouvé' qui apparait en résultat de 'trouv'
(évidemment, en local, cela ne se produit pas). C'est la solution que j'ai laissé en place sur le blog pour l'instant.
Je suppose qu'il y a donc une différence entre la table utf-8 de mon serveur local et celle de Free ?
en plus, lclocale fait partie des fonctions interdites chez Free (et donc setlocale(LC_CTYPE, 'fr_FR.utf8'); ne risque pas de faire la différence). J'ai d'ailleurs dû ajouter \u derrière chaque regex pour que cela fonctionne correctement.
Je m'étais déjà bien amusé avec les regex (Ici sous GuppY) et bien que c'était en iso-8859-1, j'avais eu également des soucis avec les limites de mots en présence d'entités html ou numériques... Mais là, pour l'utf-8, je bloque !
Si vous avez une explication, je suis preneur
Cordialement,
Ludo
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Oui, j'ai essayé avec succès une modif dont voici le détail : ici
J'avais un soucis avec les regex et cela était dû aux propriétés du fichier. Je l'éditais avec Notepad++ qui m'indiquait le fichier en utf-8
Puis j'en ai fais une copie, l'ai ouvert avec PsPad pour l'enregistrer en utf-8 et est comparé les deux fichiers avec winmerge : seul celui enregistré avec PsPad était réellement en utf-8, curieux.
De plus, strtolower ne fonctionne pas en utf-8, trouvé une explication et la solution ici : http://orangetanguine.blogspot.com/2007/06/strtolower-et-utf-8.html. Je l'ai donc remplacé par mb_strtolower et n'est plus de signes bizarres (point d'interrogation sur losange noir) à la sortie de la fonction.
J'ai finalement ma page statique 'moteur de recherche' qui est à présent en utf-8
ckeditor également, ainsi que tous mes articles et tout fonctionne.
Par contre, j'ai dû conserver \W pour détecter les limites de mots car \b ne donne pas le résultat attendu en présence de caractères accentués situés aux extrémités du mot recherché.
Si cela peut être utile à quelqu'un...
Cordialement,
[congés]Ludo[/congés]
... marche pas le bbcode 'congés' ici...