Forum CMS Made Simple FR
Erreur d'encodage - Version imprimable

+- Forum CMS Made Simple FR (https://forum.cmsmadesimple.fr)
+-- Forum : Général (https://forum.cmsmadesimple.fr/forum-3.html)
+--- Forum : Général (https://forum.cmsmadesimple.fr/forum-10.html)
+--- Sujet : Erreur d'encodage (/thread-4049.html)

Pages : 1 2

Erreur d'encodage - pierrepercee - 08/03/2018

JCE,

Tu as raison, ça vient de Windows ! Non je blague Smile 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....

Erreur d'encodage - jce76350 - 08/03/2018

Citation :Je pense que le soucis vient de Windows ...
j'ai essayé avec conviction mais ça marche pas ... Wink j'ai voulu parodier une réponse ... :p

Erreur d'encodage - airelibre - 08/03/2018

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

Erreur d'encodage - Eric11 - 09/03/2018

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

Erreur d'encodage - airelibre - 09/03/2018

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

Erreur d'encodage - jsearby - 21/03/2018

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);

Erreur d'encodage - pierrepercee - 21/03/2018

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 ! Smile

Erreur d'encodage - pierrepercee - 21/03/2018

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... Smile

Erreur d'encodage - jce76350 - 21/03/2018

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 Wink
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

Erreur d'encodage - airelibre - 22/03/2018

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

Erreur d'encodage - pierrepercee - 22/03/2018

Merci Jce,

Mon petit doigt me dit.. Smile
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

Erreur d'encodage - airelibre - 22/03/2018

@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"

Erreur d'encodage - jce76350 - 22/03/2018

Citation :Que veux tu dire par
@ pierrepercee Moi je dis rien je lis et informe en fonction du SVN

Erreur d'encodage - pierrepercee - 22/03/2018

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...

Erreur d'encodage - jce76350 - 22/03/2018

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