[PostgreSQL] probleme de charset.

Le
Etienne
Bonjour.

j'ai un problème que j'ai essayé de resoudre au niveau de mon script
avant d'aborder une solution SQL.
Mais bon j'ai pas trouvé de solution alors

j'ai une chaine de caractère qui n'est pas en UTF-8 alors que ma base de
données s'attend a trouver de l'UTF-8.

Je n'ai pas trouvé de solution pour tester la validité de la chaine dans
mon script (il d'agit de chaine très particuliere qui semble etre valide
mais qui ne le sont pas visiblement).
Hors l'insertion me génère une erreur fatale.

Y a t-il un moyen de tester en SQL (sous postgres) la validité de la
chaine avant son utilisation.

J'ai essayé dans une transaction, mais sans succès.
L'erreur est syntaxique et donc la transaction n'est pas opérante.

comment puis-je faire !!!
Merci
Etienne
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Sebastien Lardiere
Le #22338821
Le 08/07/2010 11:07, Etienne a écrit :
Bonjour.

j'ai un problème que j'ai essayé de resoudre au niveau de mon script
avant d'aborder une solution SQL.
Mais bon j'ai pas trouvé de solution alors...

j'ai une chaine de caractère qui n'est pas en UTF-8 alors que ma base de
données s'attend a trouver de l'UTF-8.

Je n'ai pas trouvé de solution pour tester la validité de la chaine dans
mon script (il d'agit de chaine très particuliere qui semble etre valide
mais qui ne le sont pas visiblement).



Qui semble être valide dans quel encodage ? est-ce que l'encodage réel
de la chaine est connu ( latin9 ? ) .

Hors l'insertion me génère une erreur fatale.



Pas FATAL pour pg, quand même ?
Peut-on voir le message d'erreur précis ?




Y a t-il un moyen de tester en SQL (sous postgres) la validité de la
chaine avant son utilisation.



La validité de la chaine, PG la test à l'insertion, justement.

L'utilisation du parametre client_encoding permet de s'en sortir, PG
ayant tout ce qu'il faut pour passer d'un encodage à un autre :


begin ;

set client_encoding = 'latin9' ;
insert into matable ( monchamp ) values 'chaine latin9') ;

commit ;

Avec cela les données seront inserée en UTF8 dans une base en UTF8.

Mais peut-être est-il préférable de corrigé le probleme à la source,
afin de ne travailler qu'en UTF8 de bout en bout ?

--
Sébastien
Etienne
Le #22339001
Le 08/07/2010 11:32, Sebastien Lardiere a écrit :

Qui semble être valide dans quel encodage ? est-ce que l'encodage réel
de la chaine est connu ( latin9 ? ) .



Ben justement j'en sais trop rien.
je traite des millier de chaine. et certaine sont mal converti.
oublions l'histoire de l'encodage. je veux simplement savaoir avant de
faire l'INSERT que le chaine va générer une erreur.

Pas FATAL pour pg, quand même ?
Peut-on voir le message d'erreur précis ?



Non l'erreur est remontée au PHP. c'est lui qui affiche l'erreur.
Malheureusement il s'agit d'une erreur de haut niveau qui interrompt le
script.
impossible de la catcher (enfin si c'est possible, mais ca stop le
script qd meme)

La validité de la chaine, PG la test à l'insertion, justement.



Hum...

L'utilisation du parametre client_encoding permet de s'en sortir, PG
ayant tout ce qu'il faut pour passer d'un encodage à un autre :

begin ;
set client_encoding = 'latin9' ;
insert into matable ( monchamp ) values 'chaine latin9') ;
commit ;



Non. je ne souhiate surtout pas changer d'encoding.
je veux convertir tout ce que je peux en UTF8,
et ignorer les quelques chaine qui vont générer une erreure.

Mais peut-être est-il préférable de corrigé le probleme à la source,
afin de ne travailler qu'en UTF8 de bout en bout ?



Je suis totalement d'accord.

Etienne
tophe
Le #22339061
Le 08/07/2010 11:07, Etienne a écrit :
Bonjour.

j'ai un problème que j'ai essayé de resoudre au niveau de mon script
avant d'aborder une solution SQL.
Mais bon j'ai pas trouvé de solution alors...

j'ai une chaine de caractère qui n'est pas en UTF-8 alors que ma base de
données s'attend a trouver de l'UTF-8.



il faudrait avoir l'erreur exacte parce que UTF-8 ou pas, ce ne sont que
des octets pour la base. Tu es sur de ne pas avoir un banal problème de
quote qui fait planter l'insert ?
Sebastien Lardiere
Le #22339731
Le 08/07/2010 12:22, Etienne a écrit :
Le 08/07/2010 11:32, Sebastien Lardiere a écrit :

Qui semble être valide dans quel encodage ? est-ce que l'encodage réel
de la chaine est connu ( latin9 ? ) .



Ben justement j'en sais trop rien.
je traite des millier de chaine. et certaine sont mal converti.
oublions l'histoire de l'encodage. je veux simplement savaoir avant de
faire l'INSERT que le chaine va générer une erreur.

Pas FATAL pour pg, quand même ?
Peut-on voir le message d'erreur précis ?



Non l'erreur est remontée au PHP. c'est lui qui affiche l'erreur.
Malheureusement il s'agit d'une erreur de haut niveau qui interrompt le
script.
impossible de la catcher (enfin si c'est possible, mais ca stop le
script qd meme)



C'est surement possible de la catcher, avec un try..catch, justement :
http://php.net/manual/en/language.exceptions.php

Et surtout, reproduire le message d'erreur au complet serait interressant;


La validité de la chaine, PG la test à l'insertion, justement.



Hum...



Php a des fonctions pour ça, dans l'extension
http://fr.php.net/manual/en/book.mbstring.php

mb_detect_encoding, par exemple :
http://fr.php.net/manual/en/function.mb-detect-encoding.php

Sinon, il y a des utilitaires sous unix pour ça, mais c'est rarement
magique, la detection d'un charset n'est pas si trivial.


L'utilisation du parametre client_encoding permet de s'en sortir, PG
ayant tout ce qu'il faut pour passer d'un encodage à un autre :



begin ;
set client_encoding = 'latin9' ;
insert into matable ( monchamp ) values 'chaine latin9') ;
commit ;



Non. je ne souhiate surtout pas changer d'encoding.
je veux convertir tout ce que je peux en UTF8,
et ignorer les quelques chaine qui vont générer une erreure.



A tester, mais une proc stock avec une bonne gestion d'exception, ça
doit pouvoir faire le job, il me semble :
http://www.postgresql.org/docs/8.4/static/plpgsql-control-structures.html#PLPGSQL-ERROR-TRAPPING

--
Sébastien
Publicité
Poster une réponse
Anonyme