Discussion :

[mesken]

J'ai deux problèmes depuis des mois avec la cote simple et la recherche

1) Lorsque je saisis les données avec des mots contenant la cote, par exemple la phrase suivante : Je demande d'expliquer l'appel et que je recherche l'un des mots qui contient la cote, soit le mot d'expliquer soit le mot l'appel , tout se passe bien en local, mais une fois l'application hébergée sur Internet, je saisis du texte contenant des mots avec cote en ligne dans ma console d'administration, mais les résultats de la recherche n'affichent rien dans mon moteur de recherche, pourtant les mots existent bel et bien et la recherche marche en local.

2) Lorsque je copie du texte dans Word ayant des mots avec cote et je colle dans les zones de texte de mon formulaire, la recherche des mots avec cote ne marche pas ni en local ni en ligne. Et la plus part du contenu de l'entreprise est déjà saisi dans des documents Word. La je comprends quand même que la cote de Word est différente de la cote du Navigateur, j'ai essayé d'utiliser la fonction qui recherche la cote de Word ( ’ ) qui est un peu plus penchée et longue et je remplace par la cote du navigateur ( ' ) qui est petite et droite avant d'enregistrer avec str_replace. Mais ça ne marche pas avec les zone de texte simple pourtant avec l'éditeur ça marche.

Quelqu'un a t-il une idée

Merci.

[RunCodePhp]

Salut

Les quotes ont la cote
(je dis ça car ça doit faire 3 ou 4 fois de suite qu'il est plus ou moins question des quotes).
Pour info, on dit quotes (et non cote), bien que ça n'y est pas dans le dico.
Je pense qu'on peu traduire ça comme des délimiteurs.

Faut pas trop se fier à Wold, la simple quote est l'équivalent de l'apostrophe, le caractère ' de la touche 4 (pour un clavier azerty), la double quotes c'est les guillemets ", la touche 3.


D'après ce que tu décris, ça ma tout l'air d'être la directive magic_quotes_gpc du php.ini qui serait activé (à On) coté hébergeur, et désactivé en local.
Les données seraient échappées ce qui fausserait leur valeur, entre autre celles qui ont des simples quotes.

Il faudrait la désactiver (à Off), et là, le mieux serait de voir du coté de ton hébergeur.
Il peu avoir plusieurs manières de le faire :
- Soit ton hébergeur permet de le faire via le panel Admin de la gestion de ton espace (genre case à cocher/décocher).
- Soit de rajouter un code dans un .htaccess
- Soit de le faire dans son code, un ini_set().
voir autre ...

Pour savoir quel est la valeur de cette directive, fait un phpinfo() dans une de tes pages, ou fait un echo ini_get('magic_quotes_gpc').

[mesken]

Merci beaucoup RunCodePhp, j'ai pas encore vérifier avec l'hébergeur pour le premier problème, mais je vais le faire et je crois que je ça va aller.

Mais pour le 2e problème je t'assure c'est un problème véritable pour moi, parce que nous avons développé une base de connaissance pour l'entreprise avec monteur de recherche intégré et l'entreprise est en train d'y mettre du contenu qui se trouvait dans divers documents et tu comprends qu'on ne peut pas ressaisir ce qu'on a déjà saisi, on te demande de trouver une solution. Et là je plante vraiment, tout texte que je copier dans Word pour mettre dans une zone de texte de mes formulaires, si ce texte l'apostrophe venant de Word, la recherche ne marche pas avec le mot apostrophé, si je saisi directement dans la zone de texte la recherche marche parfaitement avec le mot apostrophé, j'arrive pas à trouver une astuce.

Merci.

[RunCodePhp]

et l'entreprise est en train d'y mettre du contenu qui se trouvait dans divers documents

Peut être faudrait il mettre cela en stand by ou alors qu'ils fassent les remplacements avec le bon caractère en attendant de trouver une solution fiable et durable.
Ca c'est à toi voir.

D'ailleurs, as tu vérifier quelques contenus qui se trouve dans la Bdd distante directement dans PhpMyAdmin par exemple ?
Est-ce : d'expliquer
Ou : d\'expliquer (avec un échappement)
Donne un exemple du comment tu procède lors d'une insertion : depuis la récupération des données ($_POST ou $_GET) jusqu'au INERT INTO.
Ca c'est pour mieux comprendre le problème, ne pas se tromper.


Pourquoi str_replace() ne fonctionne pas pour une zone de texte simple ?
J'ai du mal à concevoir cela.
Post le code qu'on voit comment tu procèdes pour faire ces remplacements/conversions.


Si tu n'obtiens pas de solutions ici dans ce forum Php/MySQL, poster un topic dans le forum REGEX peut être plus judicieux, car c'est plus de cette ordre là qu'autre chose.
Je dis ça au cas où, d'autant plus que je ne suis pas fan des REGEX (limite hermétique même).


Vérifie bien qu'il s'agit bien de ce caractère là (’), qu'il n'y ai pas d'autres caractères pour faire une apostrophe (sait on jamais).
De mon coté je me dis qu'il pourrait être possible de rencontrer 3 caractères différents :
1 : ’ -> code ASCII : 226
2 : ’ -> code ASCII : 39
3 : ` -> code ASCII : 96

[ericd69]

salut,

tu es face à un truc simple en fait... word ne met pas ' mais un caractère équivalent typographique... de même pour " qui est remplacé par guillemet ouvrant et fermant... ou sa version anglophone...

en plus, word utilise le charset cp1512 qu'il faut donc convertir vers utf8 ou autre (celui que tu utilises)...

regarde les fonctions qui commencent par mb_

[RunCodePhp]

word ne met pas ' mais un caractère équivalent typographique... de même pour " qui est remplacé par guillemet ouvrant et fermant... ou sa version anglophone...

Que ce ne soit pas les même caractères utilisés, c'est quasi certain.

Mais il me semble que l'insertion se fasse via une interface Web qui elle a son propre encodage (ISO ou UTF-8, à voir).
Donc les données obtenues coté serveur devraient être soit en ISO ou soit en UTF-8, non ?
En faite je me dis que le navigateur va tenter de remplacer/encoder les caractères copiés/collés.

Le fond du problème viendrait peut être de là.
Dans ce cas, ne pourrait on pas faire l'inverse, c'est à dire de convertir le document Word en UTF-8 avant de copier le contenu ?


A coté de ça, faire du copier/coller de Word vers une zone de texte d'une interface Web n'est théoriquement pas une bonne idée.
M'enfin ...

[ericd69]

disons que les caractères dépendent de la locale et de la langue choisie dans word...

tu auras d'autres problème comme les espaces insécables associés aux guillemets, ou : ou ; ou ? ou ! etc...

pour la conversion, elle est normalement faite par le navigateur mais si tu doute tu as une fonction mb qui permet de le tester...

[RunCodePhp]

pour la conversion, elle est normalement faite par le navigateur mais si tu doute tu as une fonction mb qui permet de le tester...

Ce n'est pas que je doutes, j'essaie juste de comprendre


Le problème que je vois, c'est que si on prévoit d'utiliser la fonction mb_ pour convertir d'un jeu de caractère vers un autre, comme du cp1512 vers UTF-8, si un autre utilisateur utilise Word avec un jeu de caractère autre que cp1512 ça risque de coincer.
Même chose que si un autre utilisateur encore utilise un autre éditeur genre Open Office ou autre dans un jeu de caractère autre que cp1512 (sur Mac ou autre OS), ça risque de coincer aussi.

C'est en partie pour ça que je disais que faire du copier/coller de Word vers une zone de texte de son interface Web ce n'est pas une bonne idée.
A moins qu'on ai la certitude que ce soit Word avec cp1512 comme jeu de caractère qui est utilisé, là, ça pourrait fonctionner.
Faut voir.

C'est pour cette raison d'ailleurs que les forum, CMS et autres Blog (WordPress, etc ...) intègrent leur propre éditeur pour saisir les contenus.

[ericd69]

c'est l'éternel soucis...

vu que pour le gestion du texte on ne spécifie pas explicitement le charset mais que tu dois attendre un caractère mb pour le savoir... et pire, rien ne t’empêche de mixer différents charsets dans un texte...

pour info, cp1512 c'est le charset de windows...

mais tu as unicode par exemple avec des caractères mb à taille fixe...

techniquement, faut espérer que sur un texte, il n'y ait donc qu'un seul charset...

en soit, de nos jours, l'iso, pour moi, devrait être abandonné vu ces limitations...

après il y a des limites à connaitre liées aux choix (stupides) des développeurs de mysql pour utf8 et unicode... ils ont limité à 16bits au lieu des 31 de la norme car pour eux les plan de plus de 16 bits ne sont pas utilisés...
or c'est faux... ça sert pour certaines implémentations de CJK, les langues anciennes et ainsi de suite...
la taille maxi de l'utf8 dans mysql est donc de 3 octets au lieu des 6 de la normes...

donc si tu veux coder des hiéroglyphes ou du cunéiforme ou certaines forme des caractères chinois... tu peux juste pas... ou alors faut passer par du varbinary ou blob et tu perds tout un tas de fonctionnalités...

[mesken]

J''ai été indisponible pendant quelques jours et je reviens. Au final, je me rends compte qu'il faut demandé au utilisateurs de ressaisir les textes qui existent déjà. Bien que je sache qu'ils vont me lapider et déclarer mon incompétence, pour eux une application doit faire gagner en temps et non l'inverse.

Merci

[RunCodePhp]

J''ai été indisponible pendant quelques jours et je reviens. Au final, je me rends compte qu'il faut demandé au utilisateurs de ressaisir les textes qui existent déjà.

Pas forcément.
Tu ne le confirmes pas, mais si c'est bien un problème d'encodage, faudrait voir du coté de Word s'il permet de le changer, d'utiliser du UTF-8 (ne serait-ce que pour les documents concernés).
Il y aura certes une manip, mais c'est 1 manip par document et non une multitude de corrections par doc.

(je n'utilise plus Word depuis pas mal de temps, mais je suppose que ça devrait être possible)

Ensuite, te restera plus qu'à faire les remplacements de ces caractères dans ton appli lors des insertions/modifications.


A l'avenir, si cela est possible bien sûr, il faudrait que les nouvelles saisie se fassent directement sur le site Web (pas de copier/coller d'un éditeur à un autre), c'est cela qui peu garantir un bon fonctionnement.
C'est cela qu'adoptent les CMS, mais même les plus évolués sont dans l’incapacité de gérer tous ces cas particuliers liés à l'encodage dû aux copier/copier (si cela peu te rassurer).

pour eux une application doit faire gagner en temps et non l'inverse.

Oui, et pour tout le monde c'est pareil à mon avis.
Certes, c'est un peu la tuile de détecter ça de plus assez tardivement, effectivement.
Mais cela reste quand même un cas particulier.

Si on prend une Appli comme Street View (De GG), le travail effectué en amont est colossal avant que cela rende service et fasse gagner du temps.
Mais ceci ne se fait pas n'importe comment avec avec n'importe quel matériel (pas avec des appareils photos argentiques jetables).
Tout cela doit être bien cadré avant d'alimenter leur Bdd, fichiers, etc ...

De ton coté, s'il n'y pas d'autre moyen que de faire du copier/coller de Word vers le site Web, faudrait alors cadrer cela, au moins pour l'encodage.

Cependant, Word permet de faire des macros (VB), il devrait être possible de remplacer tel caractère par un autre, voire peut être de vérifier l'encodage et le remplacer si nécessaire.

Voire d'autres solutions que je ne connaitrais pas si on cherche bien, qui sait.

Il y a peut être manière à limiter la casse.