Re: Problème d'accents.... client ou serveur ?

On 19/03/2013 23:50, Doug Ross wrote:
> Le 19/03/2013 23:32, Guillaume Lelarge a écrit :
>> On Tue, 2013-03-19 at 22:56 +0100, Doug Ross wrote:
>>> Bonsoir,
>>>
>>> Je suis en train de construire un script perl pour interagir via
>>> xml-rpc
>>> avec une base postresql 9.1.8 utilisée pour OpenERP 6.1
>>> AprÚs quelques tâtonnements j'arrive a créer/mette à jour des objet
>>> OpenERP (produits, contacts, etc..).
>>>
>>> Mon soucis maintenant ce sont les mots accentués.
>>> Je n'arrive pas à déterminer où se situe le pb :(
>>>
>>> Si je crée un produit (ex: chaussure été) depuis l'interface web,
>>> les
>>> accents sont correctement stockés dans la base (enfin je suppose vu
>>> que
>>> ça fonctionne).
>>> Si je récupÚre le champ "name" de ce produit (qui contient vu de la
>>> ligne de commande non plus des accents mais des "codes") et le
>>> réutilise
>>> pour crée un 2eme produit "maillot été", alors dans l'interface
>>> web je
>>> n'ai plus les accents mais des "codes cabalistiques".
>>>
>>> Ma configuration :
>>> Client web Firefox 17.0.4 ESR sur W7
>>> PGSQL 9.1.8 + OpenERP 6.1 + perl 5.14.2 sur Ubuntu 12.04.2 avec les
>>> locales suivantes de définies :
>>> LANG=fr_FR.UTF-8
>>> LANGUAGE=
>>> LC_CTYPE="fr_FR.UTF-8"
>>> LC_NUMERIC="fr_FR.UTF-8"
>>> LC_TIME="fr_FR.UTF-8"
>>> LC_COLLATE="fr_FR.UTF-8"
>>> LC_MONETARY="fr_FR.UTF-8"
>>> LC_MESSAGES="fr_FR.UTF-8"
>>> LC_PAPER="fr_FR.UTF-8"
>>> LC_NAME="fr_FR.UTF-8"
>>> LC_ADDRESS="fr_FR.UTF-8"
>>> LC_TELEPHONE="fr_FR.UTF-8"
>>> LC_MEASUREMENT="fr_FR.UTF-8"
>>> LC_IDENTIFICATION="fr_FR.UTF-8"
>>> LC_ALL=
>>>
>>> CÎté pgsql j'ai réussi à trouver ça :
>>> List of databases
>>> Name | Owner | Encoding | Collate | Ctype | Access
>>> privileges
>>> -----------+----------+----------+-------------+-------------+-----------------------
>>>
>>> Base1 | openerp | UTF8 | fr_FR.UTF-8 | fr_FR.UTF-8 |
>>>
>>> Je pense donc que je suis bien en UTF8 "partout" sur le serveur et
>>> pourtant..... mon script perl local via xml-rpc ne "voit" ni "n'écrit"
>>> correctement les caractÚres accentués.
>>>
>>> Avez-vous déjà rencontré ce type de pb ?
>>> Avez-vous une piste de recherche à me donner pour continuer
>>> d'investiguer et arriver à identifier le pb ?
>>>
>> Votre script envoie bien les données en UTF-8 ? si vous regardez vos
>> données à partir de psql, sont-elles bien affichées ?
>>
>>
> Bonsoir, merci de votre réponse.
>
> Alors dans la table voici ce que j'ai :
> Base3=# select * from "product_category";
> id | parent_left | parent_right | create_uid | create_date |
> write_date | write_uid | name | sequence | parent_id | type
> ----+-------------+--------------+------------+----------------------------+------------+-----------+--------------------------+----------+-----------+--------
>
> 23 | 1 | 2 | 1 | 2013-03-19 20:46:50.303606 | | | Pêle-Mêle | 0 | 1 |
> normal
> 40 | 3 | 4 | 1 | 2013-03-19 22:19:03.277378 | | | Pêle-Mêle | | 1 |
> normal
> 1 | 0 | 79 | 1 | 2013-03-19 20:34:06.41676 | | | All products | | |
> normal
> 31 | 80 | 81 | 1 | 2013-03-19 21:02:07.34055 | | | Avec aacent été | 0
> | | normal
> 41 | 5 | 6 | 1 | 2013-03-19 22:26:53.070303 | | | Pêle-Mêle éÃ
> çêâô | | 1 | normal
> (5 rows)
>
> Les enregistrements 23 et 31 on été créés depuis l'interface web, le 1
> existe d'origine, 40 et 4& on été créés en XML-RPC
>
>
sur mon pc (en utf8):

echo 'Pêle-Mêle' | iconv -f iso8859-15 -t utf8
Pêle-Mêle

Les encodages bizarres qu'on voit pour 40 et 41 sont le résultat d'un
programme qui croit recevoir du latin9 (ou du cp1252, é a le même
encodage dans les deux), alors qu'il a reçu de l'utf8, et qui le
convertit en utf8 pour le stocker.

Y a donc qq chose côté perl à regarder… peut-être une chaîne qui est de
l'utf8 et qu'il croit être du latin9 ? (la fonction is_utf8 est pratique
dans ce genre de cas). Vérifier aussi que l'encodage spécifié dans le
fichier xml (le bout de code print $q->header( -type => 'text/xml',
-charset => 'UTF-8' ); de la doc d'XML::RPC) correspond bien à
l'encodage réel du XML passé. Il y a le client_encoding qui pourrait
être forcé à une mauvaise valeur (latin1 ou latin9) pour le programme
perl, qui pourrait aussi rajouter cette conversion.