Messages : 986
Sujets : 75
Inscription : Jun 2009
Réputation :
0
JCE,
Tu as raison, ça vient de Windows ! Non je blague Drupal et Joomla pour ne citer qu'eux réussissent l'exploit d'avoir toutes les tables avec le même interclassement (je passe sur le fait qu'eux ne continuent pas de stocker des "HTMLentities" dans la base de donnée avec les 2 traitements indispensable d'encodage et de décodage (conso processeur + temps + ennuis divers et variés comme ici en ce moment) alors qu'il y a bien 5 ans que tout l'environnement est en utf-8...
J'en parle ici, mais apparemment cela ne passionne pas les foules... Les foules ceci dit, cela devient un grand mot, y a 30 secondes y avait même pas un seul utilisateur enregistré parcourant le forum .org....
Win 10 pro 64 - CMSMS 2.2.19 - grincheux parfois...
Messages : 986
Sujets : 75
Inscription : Jun 2009
Réputation :
0
JCE,
Tu as raison, ça vient de Windows ! Non je blague Drupal et Joomla pour ne citer qu'eux réussissent l'exploit d'avoir toutes les tables avec le même interclassement (je passe sur le fait qu'eux ne continuent pas de stocker des "HTMLentities" dans la base de donnée avec les 2 traitements indispensable d'encodage et de décodage (conso processeur + temps + ennuis divers et variés comme ici en ce moment) alors qu'il y a bien 5 ans que tout l'environnement est en utf-8...
J'en parle ici, mais apparemment cela ne passionne pas les foules... Les foules ceci dit, cela devient un grand mot, y a 30 secondes y avait même pas un seul utilisateur enregistré parcourant le forum .org....
Win 10 pro 64 - CMSMS 2.2.19 - grincheux parfois...
Messages : 11,013
Sujets : 230
Inscription : Sep 2007
Réputation :
1
Citation :Je pense que le soucis vient de Windows ...
j'ai essayé avec conviction mais ça marche pas ... j'ai voulu parodier une réponse ... :p
Messages : 11,013
Sujets : 230
Inscription : Sep 2007
Réputation :
1
Citation :Je pense que le soucis vient de Windows ...
j'ai essayé avec conviction mais ça marche pas ... j'ai voulu parodier une réponse ... :p
Messages : 2,487
Sujets : 18
Inscription : Dec 2009
Réputation :
0
Cela étant, toutes les tables sont en utf8 hors, hors les _seq qui ne stockent qu'un simple numéro. Donc le pb ne vient pas de là je pense, mais du passage des infos entre le ContentManager, Search, et la DB
Messages : 2,487
Sujets : 18
Inscription : Dec 2009
Réputation :
0
Cela étant, toutes les tables sont en utf8 hors, hors les _seq qui ne stockent qu'un simple numéro. Donc le pb ne vient pas de là je pense, mais du passage des infos entre le ContentManager, Search, et la DB
Messages : 318
Sujets : 11
Inscription : Apr 2011
Réputation :
0
Bonjour, j'ai également toutes les tables en utf-8 et le même soucis.
Comme il semble que le soucis vienne du module de Recherche j'ai testé un petit truc en ajoutant "jusqu'à" dans Mots exclus de la recherche, réindexé tout le contenu et maintenant je n'ai plus ce bug.
A vérifier.
Eric
EricFreelance - Design, intégration et développement de sites internet.
Messages : 318
Sujets : 11
Inscription : Apr 2011
Réputation :
0
Bonjour, j'ai également toutes les tables en utf-8 et le même soucis.
Comme il semble que le soucis vienne du module de Recherche j'ai testé un petit truc en ajoutant "jusqu'à" dans Mots exclus de la recherche, réindexé tout le contenu et maintenant je n'ai plus ce bug.
A vérifier.
Eric
EricFreelance - Design, intégration et développement de sites internet.
Messages : 2,487
Sujets : 18
Inscription : Dec 2009
Réputation :
0
Le problème se situe semble-t-il au niveau du Statement en PHP (qui prépare la requête pour l'indexation d'un mot dans la DB). Ca roule sous linux, mais bloque sous windows (ok sous mac aussi à priori avec mamp)
Je continue de chercher dès que j'ai un moment
Messages : 2,487
Sujets : 18
Inscription : Dec 2009
Réputation :
0
Le problème se situe semble-t-il au niveau du Statement en PHP (qui prépare la requête pour l'indexation d'un mot dans la DB). Ca roule sous linux, mais bloque sous windows (ok sous mac aussi à priori avec mamp)
Je continue de chercher dès que j'ai un moment
Messages : 2
Sujets : 0
Inscription : Mar 2018
Réputation :
0
21/03/2018, 11:51:22
(Modification du message : 21/03/2018, 19:09:55 par jsearby.)
Bonjour à tous.
Après un bout de temps a galérer sur ce problème " Incorrect string value: '\xC3' for column 'word' at row 1 "
J'en profite pour vous envoyer mon analyse et une solution.
Les exemples ci dessous sont relatifs à l'envoi du content " juq'à la" (" juq'à ")
La solution proposée est générique et résoudra pas mal de vos problèmes d'encodage.
Localisation du problème :
En regardant les trames reseaux SQL on voit que le problème vient effectivement de l’exécution du statement SQL
INSERT INTO epc_module_search_index (item_id, word, count) VALUES (1325,?,?)
En effet, lors du passage du tableau de mot, on obtient pour juq'
Code : 6A 75 71 27 C3 01
j u q ' !! 1
-------------- --
le mot Nb occurence
C'est cela qui est responsable de la fameuse erreur 0xC3 ....
Mais quel est la source du probleme ?
0x27 en UTF8 est bien '
mais 0xC3 n'est ni connu en UTF8 ni en LATIN.
Il faut donc comprendre pourquoi notre moteur php envoi un xC3 qui semble ne correspondre a rien..
..
On regarde le code responsable de la préparation du statement SQL: search.tools.php.
On trouve ici la sequence responsable de la création du tableau de mots a indexer.
Code : 1) $content = html_entity_decode($content);
2) $stemmed_words = $obj->StemPhrase($content);
3) $tmp = array_count_values($stemmed_words);
Que se passe t'il avec un content de type juq'à la
1) L’exécution de html_entity_decode juq'à la --> juq'à la
Par défaut l'encodage est utf8 et à en UTF8 ça donne xC3xA0
On obtient donc
Code : x6A x75 x71 x27 xC3 xA0
j u q ' à
On commence a comprendre que notre probleme semble venir d'un mauvais decoupage.
2) StemPhrase exécute en réalité search_StemPhrase (toujours dans search.tools.php.)
La décomposition de la phrase en mots a lieu avec
Code : $words = preg_split('/[\s,!.;:\?()+-\/\\\\]+/', $phrase);
Et la se trouve l'erreur ... (stackoverflow 15137660)
On a une difference entre Lunix et windows:
- Par defaut preg_split utilise l'encodage local (donc pas UTF8 sur Windows).
- Mais html_entity_decode fournie de l'UTF8 !!!
Si en entrée on a du UTF8 (ce qui est notre cas ...) alors la correction est :
=> Rajouter /u a notre paramettre preg_split pour forcer un comportement en UTF8 sur preg_split
En resumé :
Certaines methodes PHP de traitement de texte ne s'alignent pas forcement sur default_charset.
On a ici un html_entity_decode fera du UTF8 (car default_charset = UTF8)
Mais on a un preg_split qui travail avec le charset local ... et donc n'arrivera pas a interpréter/splitter x27 xC3 xA0 correctement.
La solution:
Il faut modifier modules\Search\search.tools.php
Code : $words = preg_split('/[\s,!.;:\?()+-\/\\\\]+/', $phrase);
==>
$words = preg_split('/[\s,!.;:\?()+-\/\\\\]+/u', $phrase);
Note:
Depuis PHP 5.4.0 html_entity_decode fonctione bien par defaut en UTF8 ..
.... mais par acquis de conscience et afin d'eviter un plantage de cms madesimple sur un default_charset different de UTF8
Je recommanderais aussi de modifier
$content = html_entity_decode($content);
avec
$content = html_entity_decode($content,ENT_COMPAT | ENT_HTML401,UTF-8);
Messages : 2
Sujets : 0
Inscription : Mar 2018
Réputation :
0
21/03/2018, 11:51:22
(Modification du message : 21/03/2018, 19:09:55 par jsearby.)
Bonjour à tous.
Après un bout de temps a galérer sur ce problème " Incorrect string value: '\xC3' for column 'word' at row 1 "
J'en profite pour vous envoyer mon analyse et une solution.
Les exemples ci dessous sont relatifs à l'envoi du content " juq'à la" (" juq'à ")
La solution proposée est générique et résoudra pas mal de vos problèmes d'encodage.
Localisation du problème :
En regardant les trames reseaux SQL on voit que le problème vient effectivement de l’exécution du statement SQL
INSERT INTO epc_module_search_index (item_id, word, count) VALUES (1325,?,?)
En effet, lors du passage du tableau de mot, on obtient pour juq'
Code : 6A 75 71 27 C3 01
j u q ' !! 1
-------------- --
le mot Nb occurence
C'est cela qui est responsable de la fameuse erreur 0xC3 ....
Mais quel est la source du probleme ?
0x27 en UTF8 est bien '
mais 0xC3 n'est ni connu en UTF8 ni en LATIN.
Il faut donc comprendre pourquoi notre moteur php envoi un xC3 qui semble ne correspondre a rien..
..
On regarde le code responsable de la préparation du statement SQL: search.tools.php.
On trouve ici la sequence responsable de la création du tableau de mots a indexer.
Code : 1) $content = html_entity_decode($content);
2) $stemmed_words = $obj->StemPhrase($content);
3) $tmp = array_count_values($stemmed_words);
Que se passe t'il avec un content de type juq'à la
1) L’exécution de html_entity_decode juq'à la --> juq'à la
Par défaut l'encodage est utf8 et à en UTF8 ça donne xC3xA0
On obtient donc
Code : x6A x75 x71 x27 xC3 xA0
j u q ' à
On commence a comprendre que notre probleme semble venir d'un mauvais decoupage.
2) StemPhrase exécute en réalité search_StemPhrase (toujours dans search.tools.php.)
La décomposition de la phrase en mots a lieu avec
Code : $words = preg_split('/[\s,!.;:\?()+-\/\\\\]+/', $phrase);
Et la se trouve l'erreur ... (stackoverflow 15137660)
On a une difference entre Lunix et windows:
- Par defaut preg_split utilise l'encodage local (donc pas UTF8 sur Windows).
- Mais html_entity_decode fournie de l'UTF8 !!!
Si en entrée on a du UTF8 (ce qui est notre cas ...) alors la correction est :
=> Rajouter /u a notre paramettre preg_split pour forcer un comportement en UTF8 sur preg_split
En resumé :
Certaines methodes PHP de traitement de texte ne s'alignent pas forcement sur default_charset.
On a ici un html_entity_decode fera du UTF8 (car default_charset = UTF8)
Mais on a un preg_split qui travail avec le charset local ... et donc n'arrivera pas a interpréter/splitter x27 xC3 xA0 correctement.
La solution:
Il faut modifier modules\Search\search.tools.php
Code : $words = preg_split('/[\s,!.;:\?()+-\/\\\\]+/', $phrase);
==>
$words = preg_split('/[\s,!.;:\?()+-\/\\\\]+/u', $phrase);
Note:
Depuis PHP 5.4.0 html_entity_decode fonctione bien par defaut en UTF8 ..
.... mais par acquis de conscience et afin d'eviter un plantage de cms madesimple sur un default_charset different de UTF8
Je recommanderais aussi de modifier
$content = html_entity_decode($content);
avec
$content = html_entity_decode($content,ENT_COMPAT | ENT_HTML401,UTF-8);
Messages : 986
Sujets : 75
Inscription : Jun 2009
Réputation :
0
Bonjour Jsearby,
Chapeau bas et grand merci à vous. Merci c'est sans doute un peu court au vu du temps et des compétences exigées pour ce type de réponse ! Là faut avoir un sérieux background !
Époustouflant !
Win 10 pro 64 - CMSMS 2.2.19 - grincheux parfois...
Messages : 986
Sujets : 75
Inscription : Jun 2009
Réputation :
0
Bonjour Jsearby,
Chapeau bas et grand merci à vous. Merci c'est sans doute un peu court au vu du temps et des compétences exigées pour ce type de réponse ! Là faut avoir un sérieux background !
Époustouflant !
Win 10 pro 64 - CMSMS 2.2.19 - grincheux parfois...
Messages : 986
Sujets : 75
Inscription : Jun 2009
Réputation :
0
C'est déjà modifié sur la future version 2.3. Je sais pas qui a transmis l'info à la vitesse du TGV mais grand merci ! Calguy a été très réactif !
Bon, c'est un autre sujet donc mais reste maintenant le cas de ces tables déclarées avec un interclassement non adapté sous Wampserver... Vu que cela avance dans le bon sens...
Win 10 pro 64 - CMSMS 2.2.19 - grincheux parfois...
Messages : 986
Sujets : 75
Inscription : Jun 2009
Réputation :
0
C'est déjà modifié sur la future version 2.3. Je sais pas qui a transmis l'info à la vitesse du TGV mais grand merci ! Calguy a été très réactif !
Bon, c'est un autre sujet donc mais reste maintenant le cas de ces tables déclarées avec un interclassement non adapté sous Wampserver... Vu que cela avance dans le bon sens...
Win 10 pro 64 - CMSMS 2.2.19 - grincheux parfois...
Messages : 11,013
Sujets : 230
Inscription : Sep 2007
Réputation :
1
Citation :C'est déjà modifié sur la future version 2.3. Je sais pas qui a transmis l'info
sûrement une personne qui lit le forum Fr
par contre en 2.3 -> le jeu de caractères par défaut = UTF-8 sinon Utilisation à vos risques et périls Le Windoze va pas apprécié
Et c'est corrigé aussi pour la v 2.2.8
Messages : 11,013
Sujets : 230
Inscription : Sep 2007
Réputation :
1
Citation :C'est déjà modifié sur la future version 2.3. Je sais pas qui a transmis l'info
sûrement une personne qui lit le forum Fr
par contre en 2.3 -> le jeu de caractères par défaut = UTF-8 sinon Utilisation à vos risques et périls Le Windoze va pas apprécié
Et c'est corrigé aussi pour la v 2.2.8
Messages : 2,487
Sujets : 18
Inscription : Dec 2009
Réputation :
0
Merci Jsearby pour le retour d'infos, et pour le bug report (d'où est parti la résolution sur la forge) ! Le bug report était particulièrement détaillé, d'où la résolution rapide
Messages : 2,487
Sujets : 18
Inscription : Dec 2009
Réputation :
0
Merci Jsearby pour le retour d'infos, et pour le bug report (d'où est parti la résolution sur la forge) ! Le bug report était particulièrement détaillé, d'où la résolution rapide
Messages : 986
Sujets : 75
Inscription : Jun 2009
Réputation :
0
Merci Jce,
Mon petit doigt me dit..
Que veux tu dire par Citation :en 2.3 -> le jeu de caractères par défaut = UTF-8 sinon Utilisation à vos risques et périls Le Windoze va pas apprécié
Je peux traduire par "des milliers de Webmasters risquent rencontrer des problèmes insolubles avec CMSMS à partir de la version 2.3 mais on a averti donc on s'en lave les mains !". Si c'est le cas, cela vaut bien un nouveau sujet ! Seront certainement heureux de voir comment on traite leur cas... C'est une information majeure, si CMSMS abandonne la plateforme Windows, il faut le dire clairement et il faut que ce soit bien intelligible...
@Air Libre
Citation : Le bug report était particulièrement détaillé, d'où la résolution rapide
Là pour le coup je suis loin de partager ton analyse. Y a une paie que le bug est remonté de façon très correcte et y a 8 mois que rien ne bouge, absolument rien! Alors lorsqu'un utilisateur apporte la réponse sur un plateau et que tu parles de résolution rapide c'est un peu ambigüe. "La réponse était très détaillée et pertinente et la solution apportée a été rapidement adoptée et prise en compte" objectivement ce serait un peu plus conforme à la réalité...
La politique c'est un art
Win 10 pro 64 - CMSMS 2.2.19 - grincheux parfois...
Messages : 986
Sujets : 75
Inscription : Jun 2009
Réputation :
0
Merci Jce,
Mon petit doigt me dit..
Que veux tu dire par Citation :en 2.3 -> le jeu de caractères par défaut = UTF-8 sinon Utilisation à vos risques et périls Le Windoze va pas apprécié
Je peux traduire par "des milliers de Webmasters risquent rencontrer des problèmes insolubles avec CMSMS à partir de la version 2.3 mais on a averti donc on s'en lave les mains !". Si c'est le cas, cela vaut bien un nouveau sujet ! Seront certainement heureux de voir comment on traite leur cas... C'est une information majeure, si CMSMS abandonne la plateforme Windows, il faut le dire clairement et il faut que ce soit bien intelligible...
@Air Libre
Citation : Le bug report était particulièrement détaillé, d'où la résolution rapide
Là pour le coup je suis loin de partager ton analyse. Y a une paie que le bug est remonté de façon très correcte et y a 8 mois que rien ne bouge, absolument rien! Alors lorsqu'un utilisateur apporte la réponse sur un plateau et que tu parles de résolution rapide c'est un peu ambigüe. "La réponse était très détaillée et pertinente et la solution apportée a été rapidement adoptée et prise en compte" objectivement ce serait un peu plus conforme à la réalité...
La politique c'est un art
Win 10 pro 64 - CMSMS 2.2.19 - grincheux parfois...
Messages : 2,487
Sujets : 18
Inscription : Dec 2009
Réputation :
0
@pierrepercee - soit, "La réponse était très détaillée et pertinente et la solution apportée a été rapidement adoptée et prise en compte"
Messages : 2,487
Sujets : 18
Inscription : Dec 2009
Réputation :
0
@pierrepercee - soit, "La réponse était très détaillée et pertinente et la solution apportée a été rapidement adoptée et prise en compte"
Messages : 11,013
Sujets : 230
Inscription : Sep 2007
Réputation :
1
Citation :Que veux tu dire par
@ pierrepercee Moi je dis rien je lis et informe en fonction du SVN
Messages : 11,013
Sujets : 230
Inscription : Sep 2007
Réputation :
1
Citation :Que veux tu dire par
@ pierrepercee Moi je dis rien je lis et informe en fonction du SVN
Messages : 986
Sujets : 75
Inscription : Jun 2009
Réputation :
0
JCE,
Je suis allé voir les fichiers concernés et j'ai trouvé ça : Code : [== Indéfini ==]
// recommended test ... default charset
$default_charset = ini_get('default_charset');
$obj = new _tests_\boolean_test('default_charset',(strtolower($default_charset) == 'utf-8'));
$obj->required = 0;
$obj->warn_msg = \__appbase\lang('warn_default_charset',$default_charset);
$tests[] = $obj;
et ça Code : [== Indéfini ==]
$lang['warn_default_charset'] = 'Your current default character-set is: %s. A value other than UTF-8 may cause difficulties with text processing in non english languages';
Qu'on soit clair je ne te reproche strictement rien, au vu du travail abattu ici (par toi et un tout petit nombre) manquerait plus que ça.
Mais là sauf erreur de ma part le commentaire Citation :sinon Utilisation à vos risques et périls Le Windoze va pas apprécié
c'est bien toi qui le produit. Parce que pour une fois j'aurais été moins bougon qu'à l'accoutumé : tester le charset dès l'installation me semble une excellente initiative. S'il faut paramétrer Wampserver ou autre de façon particulière pourquoi pas...
Win 10 pro 64 - CMSMS 2.2.19 - grincheux parfois...
Messages : 986
Sujets : 75
Inscription : Jun 2009
Réputation :
0
JCE,
Je suis allé voir les fichiers concernés et j'ai trouvé ça : Code : [== Indéfini ==]
// recommended test ... default charset
$default_charset = ini_get('default_charset');
$obj = new _tests_\boolean_test('default_charset',(strtolower($default_charset) == 'utf-8'));
$obj->required = 0;
$obj->warn_msg = \__appbase\lang('warn_default_charset',$default_charset);
$tests[] = $obj;
et ça Code : [== Indéfini ==]
$lang['warn_default_charset'] = 'Your current default character-set is: %s. A value other than UTF-8 may cause difficulties with text processing in non english languages';
Qu'on soit clair je ne te reproche strictement rien, au vu du travail abattu ici (par toi et un tout petit nombre) manquerait plus que ça.
Mais là sauf erreur de ma part le commentaire Citation :sinon Utilisation à vos risques et périls Le Windoze va pas apprécié
c'est bien toi qui le produit. Parce que pour une fois j'aurais été moins bougon qu'à l'accoutumé : tester le charset dès l'installation me semble une excellente initiative. S'il faut paramétrer Wampserver ou autre de façon particulière pourquoi pas...
Win 10 pro 64 - CMSMS 2.2.19 - grincheux parfois...
Messages : 11,013
Sujets : 230
Inscription : Sep 2007
Réputation :
1
Citation :Mais là sauf erreur de ma part le commentaire
sinon Utilisation à vos risques et périls Le Windoze va pas apprécié
c'est bien toi qui le produit
C'est le commentaire ( Le Windoze va pas apprécié) qui est une "traduction libre" mais le texte "Utilisation à vos risques et périls " c'est ma traduction de "Use at your own risk" dans le fichier /v2.3_dev/admin/lang/en_US.php
$lang['msg_default_charset'] = 'Your default-charset is %s. A value other than UTF-8 may cause content problems. Use at your own risk';
Mais c'est hors discussion ici - c'est pour la V 2.3.x
Messages : 11,013
Sujets : 230
Inscription : Sep 2007
Réputation :
1
Citation :Mais là sauf erreur de ma part le commentaire
sinon Utilisation à vos risques et périls Le Windoze va pas apprécié
c'est bien toi qui le produit
C'est le commentaire ( Le Windoze va pas apprécié) qui est une "traduction libre" mais le texte "Utilisation à vos risques et périls " c'est ma traduction de "Use at your own risk" dans le fichier /v2.3_dev/admin/lang/en_US.php
$lang['msg_default_charset'] = 'Your default-charset is %s. A value other than UTF-8 may cause content problems. Use at your own risk';
Mais c'est hors discussion ici - c'est pour la V 2.3.x
|