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.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Sebastien Lardiere
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
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 ?
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 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
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 ?
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 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 ?
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 ?
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 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
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
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
