Signature electronique unicode : BOM pose problème

(re) Bonjour

J'ai un soucis d'encodage, voici les étapes qui m'y amènent :

- Réception d'une base de données XLS d'un client
- Reformatage en fichier CSV avec notepad en UTF-8 (fichier->enreigstrez-sous)
- Script PHP d'intégration en base de données qui parcourt le fichier CSV (script PHP encodé en UTF-8 de même que la base de données qui est en UNICODE sous postgresql)
- Les lignes du fichier CSV sont associées à un numéro de département. J'ai intégré les départements français dans une table avec deux colonnes :dep_id (identifiant au format "Text" -pour être tranquille-) et dep_lib (libellé).
- En parcourant le fichier CSV, je vérifie que le numéro de département de chaque ligne correspond bien à un département français enregistré dans la table des département, je fais une requête SQL:

SELECT count(*) as nb_dep FROM departement WHERE dep_id='1';

- Exemple parfait ici car c'est l'unique requête SQL qui ne me renvoie aucun résultat . SEUL l'identifiant "1" (département de l'AIN) pourtant enregistré dans la table n'est pas correctement traité par le moteur.

Pourquoi?

Parceque j'ai repéré (pour toutes les lignes ayant le département "1" !!! Etrange quand même...) qu'il y avait un BOM juste avant le chiffre à savoir :



J'ai pu récupérer ce caractère en ayant fait un copier du chiffre "1" à l'écran après avoir afficher le contenu de ma table des départements puis un coller dans un forum en l'ayant encadrer par des balises propres pour l'affichage du code. Quand j'ai vu ce caractère (que je ne voyais nulle part ailleurs) j'en ai déduis que c'était le problème.

Et maintenant....
Comment supprimer ce BOM sachant que j'ai essayé:
- De réécrire le chiffre "1" complètement avec les caractères qui y étaient attachés.
- d'enregistrer le fichier en ANSI (sans bom) mais niet...marche pô

Merci de m'éclairer
Modifié par speedev (29 Oct 2007 - 14:14)

J'essaye ci-dessous de copier-coller une requête contenant le code pour voir si la BOM apparait :

SELECT count(*) as nb_dep FROM departement WHERE dep_id='1'

non, donc la BOM serait en base de données et non dans mon CSV?
Modifié par speedev (29 Oct 2007 - 14:29)

Petits tests :

Directement depuis pgadmin j'exécute cette requête :

select dep_lib from departement where dep_id='2'

Qui me renvoie "Aisne"
puis

select dep_lib from departement where dep_id='1'

Qui me renvoie "Aucun résultat"

Ce qui confirme mon script PHP qui boucle sur tous les départements et qui renvoie aucun résultat pour le chiffre 1.

Et après ces tests, je remarque que la BOM est dans la table departement. Pourtant j'ai beau essayer de faire "insérer" sur pgadmin et de taper directement manuellement "1" et "Ain", cette BOM y est toujours présente!

Cela pourrait-il venir de postgresql 7.4 ou bien de pgadmin ??

Help
Modifié par speedev (29 Oct 2007 - 14:38)

J'ai trouvé une info intéressante sur PHP.net

http://php.benscom.com/manual/fr/ref.mbstring.php

a écrit :
PHP can input and output Unicode, but a little different from what Microsoft means: when Microsoft says "Unicode", it unexplicitly means little-endian UTF-16 with BOM(FF FE = chr(255).chr(254)), whereas PHP's "UTF-16" means big-endian with BOM. For this reason, PHP does not seem to be able to output Unicode CSV file for Microsoft Excel. Solving this problem is quite simple: just put BOM infront of UTF-16LE string.

Example:

$unicode_str_for_Excel = chr(255).chr(254).mb_convert_encoding( $utf8_str, 'UTF-16LE', 'UTF-8');

Effectivement si je pouvais rajouter une BOM devant mes valeurs de comparaisons, le "1" serait reconnu seulement....pas les autres
De plus je ne parviens pas à insérer cette BOM et à la convertir car mb_convert_encoding() n'existe pas sous PHP4.
Modifié par speedev (29 Oct 2007 - 14:53)

Hello,

Pour le fichier CSV que tu as utilisé pour peupler ta base, tu l'avais édité avec le notepad de Windows ou bien avec Notepad++?

Le notepad (bloc-notes) de Windows enregistre les fichiers en UTF-8 avec BOM. Ça n'est pas un bon choix d'éditeur de texte (ou de code) pour travailler en UTF-8, ou à vrai dire avec tout autre encodage que Windows-1252 (appelé «ANSI» par ce logiciel). J'aurais tendance à dire également que Notepad++ n'est pas mieux, voire pire, pour ce qui est de la gestion des encodages. Pour ma part, je reste aussi éloigné que possible de ces deux logiciels quand il s'agit de gérer correctement les encodages.

Bref, pour la prochaine fois: utiliser un bon éditeur.

Pour en revenir au cas présent, il semblerait que les octets du BOM soient enregistrés dans un de tes champs. J'aurais tendance à dire qu'il suffit de corriger manuellement, mais si ça n'a pas l'air de marcher... est-ce que pgadmin modifierait la valeur mais conserverait le BOM dans tous les cas?

Peut-être faudrait-il changer cette valeur via une requête SQL directement.
À la rigueur, on pourrait imaginer ouvrir une connexion en latin1, modifier la valeur («1» en latin1 a la même valeur numérique qu'en UTF-8 sans BOM), et voilà.
Bon, là je dis un peu n'importe quoi au pif, c'est pour donner des idées.

a écrit :
Bref, pour la prochaine fois: utiliser un bon éditeur.

Je ne suis pas spécialement d'accord avec toi car cela fait quelques années que je travaille avec le bloc note de windows au format UTF-8 et n'ai jamais rencontré de soucis avec les BOM. Je fais régulièrement des EDI avec mes clients et n'ai pas rencontré ce soucis. Je ne trouve pas plus d'intérêt à utiliser notepad++ par rapport à mon utilisation actuelle des encodages. Sommairement je passe toujours de l'iso vers l'utf-8.

De plus, le problème ne vient pas de mon CSV mais bel et bien (je pense) de postgresql 7.4.9 ou de pgadmin 3 car en insérant manuellement une nouvelle valeur dans la base, une BOM est intégrée juste avant le chiffre (si la valeur est un "1" ou "01").

A noter que ce problème est fréquent pour les utilisateurs de dreamweaver qui ont la case "Inclure une signature unicode (BOM)" de cochée dans les préférences. Ce qui n'est pas mon cas.

Donc, je pense sérieusement que ce problème d'encodage provient de la version de postgresql ou bien de Pgadmin, j'ai fais quelques recherches mais n'ai encore trouvé aucune piste là dessus. Peut-être une petite piste concernant un post qui déclare la version 7.4.9 de postgresql et quelques autres comme étant des sources de problème d'encodage, mais rien de très clair.

Merci !
Modifié par speedev (29 Oct 2007 - 15:49)

speedev a écrit :
Je ne suis pas spécialement d'accord avec toi car cela fait quelques années que je travaille avec le bloc note de windows au format UTF-8 et n'ai jamais rencontré de soucis avec les BOM.

Ça m'étonne, car d'après mes tests par le passé et ceux que je viens de faire à l'instant, le notepad (bloc-notes) de Windows gère quatre encodages:

- «ANSI» (du Windows-1252, aussi appelé CP-1252);
- «Unicode» (à priori de l'UTF-16 Little Endian);
- «Unicode big endian» (à priori de l'UTF-16 Big Endian);
- «UTF-8» (UTF-8 avec BOM).

Le bloc-notes de Windows ne gère donc pas (sauf erreur de ma part) les encodages suivants:
- ISO-8859-1;
- ISO-8859-15;
- UTF-8 sans BOM.

J'ai fait un test à l'instant en enregistrant un fichier texte tout simple en UTF-8 sans BOM avec un éditeur de code qui a une bonne gestion des encodages (en l'occurrence, il s'agit de Komodo Edit). J'ai vérifié via Firefox (en affichant en iso-8859-1), et via un éditeur hexadécimal: pas de BOM. J'ouvre le même fichier avec le Bloc-notes de Windows, et fait «Enregistrer sous» en choisissant «UTF-8»: paf, ajout d'un BOM.

Mais peut-être que cela peut se configurer quelque part?

speedev a écrit :
Sommairement je passe toujours de l'iso vers l'utf-8.

Vu que ni les encodages ISO-8859-x ni l'UTF-8 sans BOM ne sont gérés par le bloc-notes de Windows, je m'étonne qu'il n'y ait pas eu de problème plus tôt...

Maintenant, un bug ou une subtilité de Postgresql n'est pas exclu.
Modifié par Florent V. (29 Oct 2007 - 15:34)

Je viens de contrôler directement sur le serveur avec l'hébergeur de mon applicatin qui s'étonne de cette fameuse BOM présente uniquement sur la première ligne de mes fichiers CSV.
BOM nommée : EF BB BF

On a fait quelques essais :

requête en mode console sur le serveur : Insert into =>pas de bom
Insertion manuelle sur phppgadmin : Insert into => bom !
Script php d'intégration : insert into => paf! heu non... bom !

Fort étonnant...
Et la BOM n'est présente que sur la première ligne de mon fichier.

Comme solution temporaire je vais ignorer la première ligne jusqu'à trouver le soucis exact.

Je vais tester komodo Edit, au cas où...

Merci de ton étude Florent