Catcher une Erreur PHP liee a une extensi on

[WebShaker]

Bonjour.

J'execute une requête d'écriture postgreSQL.
PostgreSQL attend des chaine de caractère codée en UTF-8.

Hors dans certain cas ce que j'envoie n'est pas en UTF-8.

Il se produit une erreur postgreSQL qui génére une "Fatal Error" du PHP.
Donc j'aimerai pouvoir executer quelques chose lorsque cela se produit.

mais ni un try ctach
ni un set_exception_handler

Ne semble fonctionner. Et du coup mon script s'arrète.

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

Je cherche donc le moyen d'éviter que mon script s'arrète dans ce cas et
surtout de pouvoir réaliser un traitement particulier pour ce type de
problème.

Etienne

[Olivier Miakinen]

Bonjour,

Post by WebShaker
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,

[WebShaker]

Post by Olivier Miakinen
Bonjour,
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

[Olivier Miakinen]

Post by WebShaker

Post by Olivier Miakinen
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 ?

Post by WebShaker
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.

Post by WebShaker
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 ?

Post by WebShaker
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,

[WebShaker]

Post by Olivier Miakinen
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...
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?

Post by Olivier Miakinen
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.

Post by Olivier Miakinen
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.

Post by Olivier Miakinen
Ç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

[Christophe]

Post by WebShaker
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
.

[Etienne]

Post by Christophe
Ç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.

[Jean-Francois Ortolo]

Post by Etienne
$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 ===false) 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

[Jean-Francois Ortolo]

Post by Etienne
$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

[Etienne]

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