Catcher une Erreur PHP liee a une extensi on

Bonjour,

Le 01/10/2010 10:36, WebShaker a écrit :

Je n'ai pas trouvé le moyen de tester si ma chaine etait en UTF-8. Sinon
cela aurait résolu mon problème.

En cherchant plus activement, je viens de trouver ceci :
http://fr2.php.net/manual/fr/function.mb-check-encoding.php

Cordialement,
--
Olivier Miakinen

Le 01/10/2010 11:12, Olivier Miakinen a écrit :

Bonjour,

En cherchant plus activement, je viens de trouver ceci :
http://fr2.php.net/manual/fr/function.mb-check-encoding.php

Hum j'ai testé ca ne marche pas.
Les chaines en question sont des mails dont certains sont écrit avec un
charset inconnu :)

Genre tout en utf-8 sauf un caractère.
Ou bien parfois un savant mélange d'utf-8 et d'ISO.

L'idée n'est pas de trouver le charset mais plutot de vérifier que la
chaine est bien en utf-8.
Ces mails sont souvent des vieux spams, mais bon, impossible d'en être sur.

En gros, c'est balo, mais il y a environ 1 mail sur 100.000 que je
n'arrive pas à enregistrer.

Etienne

Le 01/10/2010 17:28, WebShaker a écrit :

En cherchant plus activement, je viens de trouver ceci :
http://fr2.php.net/manual/fr/function.mb-check-encoding.php

Hum j'ai testé ca ne marche pas.

:-(

On aura fait un grand pas dans la maintenance informatique quand plus
personne ne décrira son problème en disant « ça ne marche pas » sans
l'accompagner d'explications sur le triplet { action effectuée, résultat
attendu, résultat obtenu } !

C'est donc à moi d'essayer de te tirer les vers du nez. Est-ce que :
1) Des chaînes considérées comme correctes par mb_check_encoding() sont
ensuite rejetées PostgreSQL ?
2) Des chaînes considérées comme incorrectes par mb_check_encoding()
sont pourtant acceptées par PostgreSQL ?
3) Des chaînes font planter mb_check_encoding(), rendant l'appel à cette
fonction inutile pour éviter de faire planter PostgreSQL ?

Les chaines en question sont des mails dont certains sont écrit avec un
charset inconnu :)

Note que l'intérêt de mb_check_encoding est justement de permettre de
reconnaître quelques charsets prédéfinis.

Genre tout en utf-8 sauf un caractère.
Ou bien parfois un savant mélange d'utf-8 et d'ISO.

Oui, et alors ? Tu veux détecter que ces chaînes sont problématiques
afin de les mettre à la poubelle pour ne pas provoquer d'erreur dans
PostgreSQL, n'est-ce pas ? Est-ce que mb_check_encoding ne te permet pas
justement ce tri ?

L'idée n'est pas de trouver le charset mais plutot de vérifier que la
chaine est bien en utf-8.

Ça tombe bien, c'est justement ce que fait mb_check_encoding().

Alors tant que tu n'auras pas expliqué ce qui te défrise dans son
fonctionnement on aura du mal à te faire de meilleures suggestions.


Cordialement,
--
Olivier Miakinen

Le 01/10/2010 18:46, Olivier Miakinen a écrit :

Le 01/10/2010 17:28, WebShaker a écrit :

On aura fait un grand pas dans la maintenance informatique quand plus
personne ne décrira son problème en disant « ça ne marche pas » sans
l'accompagner d'explications sur le triplet { action effectuée, résultat
attendu, résultat obtenu } !

Bon je vais te sortir une chaine pour que tu puisses voir le problème...

C'est donc à moi d'essayer de te tirer les vers du nez. Est-ce que :

Le problème c'est que j'ai fait des tas d'essais
avec mbconvert mais aussi iconv
les deux montrant des limites dans des cas différents?

Note que l'intérêt de mb_check_encoding est justement de permettre de
reconnaître quelques charsets prédéfinis.

Ben je suppose (mais je vais vérifier) que ca retourne UTF-8.

Oui, et alors ? Tu veux détecter que ces chaînes sont problématiques
afin de les mettre à la poubelle pour ne pas provoquer d'erreur dans
PostgreSQL, n'est-ce pas ? Est-ce que mb_check_encoding ne te permet pas
justement ce tri ?

Non.
Sinon trop de mail partirai a la benne.

Ça tombe bien, c'est justement ce que fait mb_check_encoding().

Non !


Ceci dit, on s'écarte du sujet.
qui était de réussir a intercepté l'erreur PostrgreSQL...

Car finalement j'ai trouvé une solution (pas très bonne) à mon problème
qui consiste a envoyer tous les mails dans tidy avant de les enregister.
Il semble que cela corrige le problème sur les quelques mails qui
plantaient. J'en saurai plus lorsque j'aurai fini d'enregistrer les
millions de mail de mon entreprise.

Ce qui me chagrine tout de même c'est de ne pas être sur que ma
procédure soit solide.
En gros rien ne me garanti qu'un jour je ne vais pas recevoir un mail
qui va faire planter mon script...

PS : je t'envoie une des chaînes si ca t'intéresse.

A+
Etienne

Le 02/10/2010 11:35, WebShaker a écrit :

Ce qui me chagrine tout de même c'est de ne pas être sur que ma
procédure soit solide.
En gros rien ne me garanti qu'un jour je ne vais pas recevoir un mail
qui va faire planter mon script...

PS : je t'envoie une des chaînes si ca t'intéresse.

A+
Etienne

Ça fait 10 ans que je fais des choses dans le genre

pg_query($conn, 'INSERT INTO ...');
if (pg_last_error($conn) {
// la requête a foiré on traite éventuellement le pourquoi
}

enfin pas exactement ça, mais c'est tout comme, et je n'ai jamais vu de
"fatal error" php !

Comment fais tu tes insertions ?

Christophe
.

Le 02/10/2010 22:02, Christophe a écrit :

Ça fait 10 ans que je fais des choses dans le genre

pg_query($conn, 'INSERT INTO ...');
if (pg_last_error($conn) {
// la requête a foiré on traite éventuellement le pourquoi
}

enfin pas exactement ça, mais c'est tout comme, et je n'ai jamais vu de
"fatal error" php !

Hum...
En effet c'est étrange.
J'ai isolé le code et je n'ai plus de fatal error...

je fais donc un test comme celui-la

$conn = pg_pconnect("host=x port=x user=x password=x dbname=x");

pg_query($conn, "BEGIN WORK;n");
pg_query($conn, "INSERT INTO test (data) VALUES ('voilà');n");
pg_query($conn, "INSERT INTO test (data) VALUES ('hop');n");
pg_query($conn, "COMMIT WORK;n");

et effectivement j'ai juste

Warning: pg_query() [function.pg-query]: Query failed: ERROR: invalid
byte sequence for encoding "UTF8": 0xe02729 HINT: This error can also
happen if the byte sequence does not match the encoding expected by the
server, which is controlled by "client_encoding". in
/opt/web/clients/u/ufp/officexpress.fr/public_html/test/iso.php on line 16

Warning: pg_query() [function.pg-query]: Query failed: ERROR: current
transaction is aborted, commands ignored until end of transaction block
in /opt/web/clients/u/ufp/officexpress.fr/public_html/test/iso.php on
line 17

ce qui peut très bien être esquivé grâce à un simple gestionnaire
d'erreur ou bien encore en utilisant le @

Faut que j'investigue un peu là !!!

A bientot.

Le 05/10/2010 23:19, Etienne a écrit :

$conn = pg_pconnect("host=x port=x user=x password=x dbname=x");

pg_query($conn, "BEGIN WORK;n");
pg_query($conn, "INSERT INTO test (data) VALUES ('voilà');n");
pg_query($conn, "INSERT INTO test (data) VALUES ('hop');n");
pg_query($conn, "COMMIT WORK;n");

Bonjour Monsieur

Effectivement, il faut détecter if($conn ==úlse) après le
pg_connect() ( il me semble ).

Et puis, dans le premier insert , n'est-ce pas le à de voilà qui pose
problème ?

Son codage dépend du codage du script source, qui dépend de l'éditeur
utilisé ?

Amicalement.

Jean-François Ortolo

--
Visitez mon site gratuit donnant des Statistiques,
des Pronostics et des Historiques Graphiques
sur les Courses de Chevaux:
http://www.pronostics-courses.fr

Le 05/10/2010 23:19, Etienne a écrit :

$conn = pg_pconnect("host=x port=x user=x password=x dbname=x");

pg_query($conn, "BEGIN WORK;n");
pg_query($conn, "INSERT INTO test (data) VALUES ('voilà');n");
pg_query($conn, "INSERT INTO test (data) VALUES ('hop');n");
pg_query($conn, "COMMIT WORK;n");

Bonjour Monsieur

A part le voilà qui a une lettre accentuée ( voir le codage de
l'éditeur ), pourquoi vous mettez un retour à la ligne ( ;n" ) à la
suite de pg_query() ?

Ne serait-ce pas plutôt :

pg_query($conn, "BEGIN WORK");
pg_query($conn, "INSERT INTO test (data) VALUES ('voilà')");
pg_query($conn, "INSERT INTO test (data) VALUES ('hop')");
pg_query($conn, "COMMIT WORK");


En ce qui me concerne, pour MySQL je met toutes mes instructions SQL
entre doubles quotes ( correct ), et sans point-virgule ni saut de ligne
à la fin.

Quant aux chaînes de caractères constantes 'voilà' et 'hop', la quote
simple, pour une instruction MySQL, sert aussi à délimiter des valeurs
chaînes de caractères,( c'est le cas ici ), ou bien des variables php.

Par exemple, on pourrait écrire :

$c = "voilà";
pg_query($conn, "INSERT INTO test (data) VALUES ('$c')");


Ou bien :

$c = "voilà";
pg_query($conn, "INSERT INTO test (data) VALUES ('" . $c . "')");


Mais :

$c = "voilà";
pg_query($conn, "INSERT INTO test (data) VALUES (" . $c . ")");

fonction nerait certainement, et :

$c = "voilà";
pg_query($conn, "INSERT INTO test (data) VALUES ($c)");

fonctionnerait peut-être, sous toutes réserves( cette syntaxe est à
réserver aux valeurs numériques de $c ).


Comme dans le premier de ces deux cas, les quotes simples sont dans
un ordre SQL, la valeur de la variable $c est quand même substituée,
bien que cette variable est entre quotes simples.

Par contre, dans un cas comem celui-ci :

$c = "voilà";

$p = '$c';

echo $p;

On obtiendrait :

$c

et non pas

voilà

car la variable $c est entre quotes simples dans l'affectation de $p
, donc sa valeur n'est pas substituée.

Monsieur John Gallet, pourrait nous faire un cours de syntaxe php,
non ? ;)

Bien à vous.

Amicalement.

Jean-François Ortolo

--
Visitez mon site gratuit donnant des Statistiques,
des Pronostics et des Historiques Graphiques
sur les Courses de Chevaux:
http://www.pronostics-courses.fr

Le 06/10/2010 15:03, Jean-Francois Ortolo a écrit :

A part le voilà qui a une lettre accentuée ( voir le codage de l'éditeur
), pourquoi vous mettez un retour à la ligne ( ;n" ) à la suite de
pg_query() ?

Le voilà sert justement a générer l'erreur.
C'est le but recherché:
- Générer un erreur
- La traiter proprement.

hum.
;n c'est une habitude que j'ai prise... je ne sais pas trop pourquoi.

Cela ne pose aucun problème.

Etienne