Re: [Dolibarr-dev] [patch ?] dolibarr et encodage de caractères BDD

[Laurent Destailleur (Eldy)]

Fabrice Delliaux a écrit :

> Bonjour,
>
> Je me permet d'envoyer ce mail au format html, afin d'y insérer
> quelques images, de façon à ce que vous puissiez visualiser le problème.

Merci pour ce patch et les explications techniques qui vont avec.

Pour ce qui est du pb affichage sur les écran d'install, je pense qu'il
suffit d'ajouter un forcage de l'entete en iso pour indiquer que la
page est en iso (les pages dolibarr sont en effet créés et générées en
iso). Le fait d'avoir apache mis en utf8 par defaut doit donc etre
compensé par une ligne d'en-tete pour avertir le serveur web et
navigateur du codage de la page. Ceci avait été fait sur les pages
Dolibarr mais pas sur les pages de l'install.
J'ai ajouté une ligne dans install/inc.php:
header("Content-type: text/html; charset=iso-8859-1");
Tu me diras si cela suffit pour faire disparaitre l'erreur de ta
première copie écran.


Pour les pb affichage au sein de Dolibarr meme, ton patch devrait faire
effet.
Par contre, faire le décodage à l'affichage est un peu lourd. Tu as une
solution plus simple et plus propre. Les données en mémoire doivent deja
etre en iso, ainsi pas de problème en ce qui concerne l'affichage sur
des pages forcée en iso. Par contre c'est dans les methode métiers qui
lisent les données de la base qu'il faut décoder (ou bien dans las pages
qui effectue les accès aux base quand aucune méthode métier n'est utilisée).

Donc il faudrait faire un truc du genre dans toutes les methodes fetch
ou dans tous les récupération de select (par exemple societe->fetch) :
Lorsqu'on lit le resultat d'un resultset $obj (obtenu par un mysql_query
en général)
               $this->nom = $obj->nom
On devrait mettre
               $this->nom = dolibarr_utf8_decode($obj->nom).


et que dolibarr_utf8_decode soit une fonction globale qui contienne
l'appel à utf8_decode.

Ainsi, c'est dès la source que la varialble est décodé et le reste du
code est bon. Pour moi ce décodage doit ce faire dès la lecture du
paramètre. On a ainsi dans les instances de classes toutjours le meme
contenu quelque soit la config de la base. Et l'exploitation des ces
instances devient plus claire car par principe on sait que c'est de
l'iso. On en manipule que de l'iso et toutes les données en mémoire,
meme lorsqu'elle viennent d'une autre base sont codées de la meme manière.
De plus, il faut faire l'inverse au moment des insert et update.

Mais il faut mettre le codage/décodage de la base au plus près de la
couche d'accès a la base (car c'est pour répondre à un codage base
qu'on doit faire ce codage/décodage à chaque fois).

PS: Je me demande meme si cela n'est pas possible de le mettre au sein
du driver mysql.lib.php. Mais je n'ai rien trouvé pour dire à mysql que
le résultat d'un mysql_query doit etre convertit par la couche php.
Aussi l'utilisation des get et set risque de devoir se faire sur chaque
méthode métier. Par contre, ce serait mieux de placer ces get et set
juste après le select ou au moment de fabriquer le update ou insert et
non au moment des affichages.

Note: il n'est jamais trop tard pour partir sur cette voie. Cela reste
compatible avec la patch intégré (au pire ce sera décodé 2 fois) et n'a
pas d'effet généant pour ceux qui sont en iso.



--
Laurent Destailleur.
---------------------------------------------------------------
EMail: address@hidden
Web: http://www.destailleur.fr
IM: IRC=Eldy, Jabber=Eldy

AWStats (Author) : http://awstats.sourceforge.net
Dolibarr (Contributor) : http//www.dolibarr.com
CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net
AWBot (Author) : http://awbot.sourceforge.net