Je suis en train de developper un moteur de recherche web en arabe et j'ai
quelques problemes.
Quand mon crawler telecharge une page, je peux appliquer une expression
reguliere pour extraire les mots arabes seulement, pour empecher certains
caracteres speciaux de rester en debut ou en fin de mot. Mon crawler arrive
donc a construire l'index de recherche au fur et a mesure du telechargement
des pages web.
Le probleme est survenu quand j'ai voulu separer le crawler du moteur
d'indexation (pour ne pas ralentir le crawler). Maintenant le crawler ne
fait que stocker le texte des pages telechargées. Le moteur d'indexation
extrait le texte de la base de données et applique la meme expression
reguliere en arabe (equivalente de $variable =~ m/([abcdef.....xyz]+)/)
J'utilise utf8 (use utf8) dans le programme perl et toutes mes tables sont
en utf8_general_ci
Quand je supprime use utf8 du programme d'indexation, l'expression regulire
arabe fonctionne, les mots sont indexés, mais ils ne sont pas reconnus en
tant que mots arabes. Quand je fais une recherche avec mon interface web php
ca ne donne aucun resultat sachant que le mot que je cherche existe dans le
texte indexé (j'ai bien mit chatset=utf8 dans mon html).
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
Paul Gaborit
À (at) Mon, 6 Nov 2006 14:49:57 +0100, "JalaL" écrivait (wrote):
Je suis en train de developper un moteur de recherche web en arabe et j'ai quelques problemes.
Quand mon crawler telecharge une page, je peux appliquer une expression reguliere pour extraire les mots arabes seulement, pour empecher certains caracteres speciaux de rester en debut ou en fin de mot. Mon crawler arrive donc a construire l'index de recherche au fur et a mesure du telechargement des pages web.
Le probleme est survenu quand j'ai voulu separer le crawler du moteur d'indexation (pour ne pas ralentir le crawler). Maintenant le crawler ne fait que stocker le texte des pages telechargées. Le moteur d'indexation extrait le texte de la base de données et applique la meme expression reguliere en arabe (equivalente de $variable =~ m/([abcdef.....xyz]+)/)
J'utilise utf8 (use utf8) dans le programme perl et toutes mes tables sont en utf8_general_ci
Quand je supprime use utf8 du programme d'indexation, l'expression regulire arabe fonctionne, les mots sont indexés, mais ils ne sont pas reconnus en tant que mots arabes. Quand je fais une recherche avec mon interface web php ca ne donne aucun resultat sachant que le mot que je cherche existe dans le texte indexé (j'ai bien mit chatset=utf8 dans mon html).
Est ce que quelqu'un a une idée.
Sans voir les bouts de codes en cause, on ne peut que faire quelques suppositions.
A priori, la seule différence entre les deux situations semble être le passage par un fichier de stockage dans le cas où ça ne marche pas. Ce fichier est-il écrit et relu en tant que fichier UTF8 ? Si c'est du HTML, l'annonce "charset=utf8" n'est prise en compte que par certains analyseur spécialisés HTML...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) Mon, 6 Nov 2006 14:49:57 +0100,
"JalaL" <nospam@nospam.com> écrivait (wrote):
Je suis en train de developper un moteur de recherche web en arabe et j'ai
quelques problemes.
Quand mon crawler telecharge une page, je peux appliquer une expression
reguliere pour extraire les mots arabes seulement, pour empecher certains
caracteres speciaux de rester en debut ou en fin de mot. Mon crawler arrive
donc a construire l'index de recherche au fur et a mesure du telechargement
des pages web.
Le probleme est survenu quand j'ai voulu separer le crawler du moteur
d'indexation (pour ne pas ralentir le crawler). Maintenant le crawler ne
fait que stocker le texte des pages telechargées. Le moteur d'indexation
extrait le texte de la base de données et applique la meme expression
reguliere en arabe (equivalente de $variable =~ m/([abcdef.....xyz]+)/)
J'utilise utf8 (use utf8) dans le programme perl et toutes mes tables sont
en utf8_general_ci
Quand je supprime use utf8 du programme d'indexation, l'expression regulire
arabe fonctionne, les mots sont indexés, mais ils ne sont pas reconnus en
tant que mots arabes. Quand je fais une recherche avec mon interface web php
ca ne donne aucun resultat sachant que le mot que je cherche existe dans le
texte indexé (j'ai bien mit chatset=utf8 dans mon html).
Est ce que quelqu'un a une idée.
Sans voir les bouts de codes en cause, on ne peut que faire quelques
suppositions.
A priori, la seule différence entre les deux situations semble être le
passage par un fichier de stockage dans le cas où ça ne marche pas. Ce
fichier est-il écrit et relu en tant que fichier UTF8 ? Si c'est du
HTML, l'annonce "charset=utf8" n'est prise en compte que par certains
analyseur spécialisés HTML...
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) Mon, 6 Nov 2006 14:49:57 +0100, "JalaL" écrivait (wrote):
Je suis en train de developper un moteur de recherche web en arabe et j'ai quelques problemes.
Quand mon crawler telecharge une page, je peux appliquer une expression reguliere pour extraire les mots arabes seulement, pour empecher certains caracteres speciaux de rester en debut ou en fin de mot. Mon crawler arrive donc a construire l'index de recherche au fur et a mesure du telechargement des pages web.
Le probleme est survenu quand j'ai voulu separer le crawler du moteur d'indexation (pour ne pas ralentir le crawler). Maintenant le crawler ne fait que stocker le texte des pages telechargées. Le moteur d'indexation extrait le texte de la base de données et applique la meme expression reguliere en arabe (equivalente de $variable =~ m/([abcdef.....xyz]+)/)
J'utilise utf8 (use utf8) dans le programme perl et toutes mes tables sont en utf8_general_ci
Quand je supprime use utf8 du programme d'indexation, l'expression regulire arabe fonctionne, les mots sont indexés, mais ils ne sont pas reconnus en tant que mots arabes. Quand je fais une recherche avec mon interface web php ca ne donne aucun resultat sachant que le mot que je cherche existe dans le texte indexé (j'ai bien mit chatset=utf8 dans mon html).
Est ce que quelqu'un a une idée.
Sans voir les bouts de codes en cause, on ne peut que faire quelques suppositions.
A priori, la seule différence entre les deux situations semble être le passage par un fichier de stockage dans le cas où ça ne marche pas. Ce fichier est-il écrit et relu en tant que fichier UTF8 ? Si c'est du HTML, l'annonce "charset=utf8" n'est prise en compte que par certains analyseur spécialisés HTML...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
JalaL
"Paul Gaborit" a écrit dans le message de news:
À (at) Mon, 6 Nov 2006 14:49:57 +0100, "JalaL" écrivait (wrote):
Je suis en train de developper un moteur de recherche web en arabe et j'ai quelques problemes.
Quand mon crawler telecharge une page, je peux appliquer une expression reguliere pour extraire les mots arabes seulement, pour empecher certains caracteres speciaux de rester en debut ou en fin de mot. Mon crawler arrive donc a construire l'index de recherche au fur et a mesure du telechargement des pages web.
Le probleme est survenu quand j'ai voulu separer le crawler du moteur d'indexation (pour ne pas ralentir le crawler). Maintenant le crawler ne fait que stocker le texte des pages telechargées. Le moteur d'indexation extrait le texte de la base de données et applique la meme expression reguliere en arabe (equivalente de $variable =~ m/([abcdef.....xyz]+)/)
J'utilise utf8 (use utf8) dans le programme perl et toutes mes tables sont en utf8_general_ci
Quand je supprime use utf8 du programme d'indexation, l'expression regulire arabe fonctionne, les mots sont indexés, mais ils ne sont pas reconnus en tant que mots arabes. Quand je fais une recherche avec mon interface web php ca ne donne aucun resultat sachant que le mot que je cherche existe dans le texte indexé (j'ai bien mit chatset=utf8 dans mon html).
Est ce que quelqu'un a une idée.
Sans voir les bouts de codes en cause, on ne peut que faire quelques suppositions.
A priori, la seule différence entre les deux situations semble être le passage par un fichier de stockage dans le cas où ça ne marche pas. Ce fichier est-il écrit et relu en tant que fichier UTF8 ? Si c'est du HTML, l'annonce "charset=utf8" n'est prise en compte que par certains analyseur spécialisés HTML...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
Il doit y avoir une transformation de l'encodage pendant l'insertion dans la base mysql.
J'ai reussi a contourner ce probleme en utilisant la fonction encode_entities qui transforme les caracteres arabes en ģ avant de stocker le texte dans la base de données... ensuite j'utilise decode_entities dans le moteur d'indexation pour transformer les ģ en caracteres arabes et tout fonctionne comme prevu.
"Paul Gaborit" <Paul.Gaborit@invalid.invalid> a écrit dans le message de
news: wt9irhs37bm.fsf@marceau.enstimac.fr...
À (at) Mon, 6 Nov 2006 14:49:57 +0100,
"JalaL" <nospam@nospam.com> écrivait (wrote):
Je suis en train de developper un moteur de recherche web en arabe et
j'ai
quelques problemes.
Quand mon crawler telecharge une page, je peux appliquer une expression
reguliere pour extraire les mots arabes seulement, pour empecher certains
caracteres speciaux de rester en debut ou en fin de mot. Mon crawler
arrive
donc a construire l'index de recherche au fur et a mesure du
telechargement
des pages web.
Le probleme est survenu quand j'ai voulu separer le crawler du moteur
d'indexation (pour ne pas ralentir le crawler). Maintenant le crawler ne
fait que stocker le texte des pages telechargées. Le moteur d'indexation
extrait le texte de la base de données et applique la meme expression
reguliere en arabe (equivalente de $variable =~ m/([abcdef.....xyz]+)/)
J'utilise utf8 (use utf8) dans le programme perl et toutes mes tables
sont
en utf8_general_ci
Quand je supprime use utf8 du programme d'indexation, l'expression
regulire
arabe fonctionne, les mots sont indexés, mais ils ne sont pas reconnus en
tant que mots arabes. Quand je fais une recherche avec mon interface web
php
ca ne donne aucun resultat sachant que le mot que je cherche existe dans
le
texte indexé (j'ai bien mit chatset=utf8 dans mon html).
Est ce que quelqu'un a une idée.
Sans voir les bouts de codes en cause, on ne peut que faire quelques
suppositions.
A priori, la seule différence entre les deux situations semble être le
passage par un fichier de stockage dans le cas où ça ne marche pas. Ce
fichier est-il écrit et relu en tant que fichier UTF8 ? Si c'est du
HTML, l'annonce "charset=utf8" n'est prise en compte que par certains
analyseur spécialisés HTML...
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
Il doit y avoir une transformation de l'encodage pendant l'insertion dans la
base mysql.
J'ai reussi a contourner ce probleme en utilisant la fonction
encode_entities qui transforme les caracteres arabes en ģ avant de
stocker le texte dans la base de données... ensuite j'utilise
decode_entities dans le moteur d'indexation pour transformer les ģ en
caracteres arabes et tout fonctionne comme prevu.
À (at) Mon, 6 Nov 2006 14:49:57 +0100, "JalaL" écrivait (wrote):
Je suis en train de developper un moteur de recherche web en arabe et j'ai quelques problemes.
Quand mon crawler telecharge une page, je peux appliquer une expression reguliere pour extraire les mots arabes seulement, pour empecher certains caracteres speciaux de rester en debut ou en fin de mot. Mon crawler arrive donc a construire l'index de recherche au fur et a mesure du telechargement des pages web.
Le probleme est survenu quand j'ai voulu separer le crawler du moteur d'indexation (pour ne pas ralentir le crawler). Maintenant le crawler ne fait que stocker le texte des pages telechargées. Le moteur d'indexation extrait le texte de la base de données et applique la meme expression reguliere en arabe (equivalente de $variable =~ m/([abcdef.....xyz]+)/)
J'utilise utf8 (use utf8) dans le programme perl et toutes mes tables sont en utf8_general_ci
Quand je supprime use utf8 du programme d'indexation, l'expression regulire arabe fonctionne, les mots sont indexés, mais ils ne sont pas reconnus en tant que mots arabes. Quand je fais une recherche avec mon interface web php ca ne donne aucun resultat sachant que le mot que je cherche existe dans le texte indexé (j'ai bien mit chatset=utf8 dans mon html).
Est ce que quelqu'un a une idée.
Sans voir les bouts de codes en cause, on ne peut que faire quelques suppositions.
A priori, la seule différence entre les deux situations semble être le passage par un fichier de stockage dans le cas où ça ne marche pas. Ce fichier est-il écrit et relu en tant que fichier UTF8 ? Si c'est du HTML, l'annonce "charset=utf8" n'est prise en compte que par certains analyseur spécialisés HTML...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
Il doit y avoir une transformation de l'encodage pendant l'insertion dans la base mysql.
J'ai reussi a contourner ce probleme en utilisant la fonction encode_entities qui transforme les caracteres arabes en ģ avant de stocker le texte dans la base de données... ensuite j'utilise decode_entities dans le moteur d'indexation pour transformer les ģ en caracteres arabes et tout fonctionne comme prevu.
Paul Gaborit
À (at) Mon, 6 Nov 2006 17:26:51 +0100, "JalaL" écrivait (wrote):
Il doit y avoir une transformation de l'encodage pendant l'insertion dans la base mysql.
J'ai reussi a contourner ce probleme en utilisant la fonction encode_entities qui transforme les caracteres arabes en ģ avant de stocker le texte dans la base de données... ensuite j'utilise decode_entities dans le moteur d'indexation pour transformer les ģ en caracteres arabes et tout fonctionne comme prevu.
C'est donc bien un problème d'encodage... Votre base MySQL est-elle configurée pour gérer l'UTF8 ? Normalement, DBI (et le DBD correspondant) le gère bien mais encore faut-il que mysql l'accepte.
PS: je ne sais pas si ça a changé avec les dernières version de MySQL mais si votre base existe déjà (et contient déjà beaucoup d'information) et n'est pas en UTF8, la bascule est très fastidieuse voire dangereuse. N'oubliez pas de faire un dump des bases existantes avant de tenter la manoeuvre...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) Mon, 6 Nov 2006 17:26:51 +0100,
"JalaL" <nospam@nospam.com> écrivait (wrote):
Il doit y avoir une transformation de l'encodage pendant l'insertion
dans la base mysql.
J'ai reussi a contourner ce probleme en utilisant la fonction
encode_entities qui transforme les caracteres arabes en ģ
avant de stocker le texte dans la base de données... ensuite
j'utilise decode_entities dans le moteur d'indexation pour
transformer les ģ en caracteres arabes et tout fonctionne
comme prevu.
C'est donc bien un problème d'encodage... Votre base MySQL est-elle
configurée pour gérer l'UTF8 ? Normalement, DBI (et le DBD
correspondant) le gère bien mais encore faut-il que mysql l'accepte.
PS: je ne sais pas si ça a changé avec les dernières version de MySQL
mais si votre base existe déjà (et contient déjà beaucoup
d'information) et n'est pas en UTF8, la bascule est très fastidieuse
voire dangereuse. N'oubliez pas de faire un dump des bases existantes
avant de tenter la manoeuvre...
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) Mon, 6 Nov 2006 17:26:51 +0100, "JalaL" écrivait (wrote):
Il doit y avoir une transformation de l'encodage pendant l'insertion dans la base mysql.
J'ai reussi a contourner ce probleme en utilisant la fonction encode_entities qui transforme les caracteres arabes en ģ avant de stocker le texte dans la base de données... ensuite j'utilise decode_entities dans le moteur d'indexation pour transformer les ģ en caracteres arabes et tout fonctionne comme prevu.
C'est donc bien un problème d'encodage... Votre base MySQL est-elle configurée pour gérer l'UTF8 ? Normalement, DBI (et le DBD correspondant) le gère bien mais encore faut-il que mysql l'accepte.
PS: je ne sais pas si ça a changé avec les dernières version de MySQL mais si votre base existe déjà (et contient déjà beaucoup d'information) et n'est pas en UTF8, la bascule est très fastidieuse voire dangereuse. N'oubliez pas de faire un dump des bases existantes avant de tenter la manoeuvre...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
JalaL
"Paul Gaborit" a écrit dans le message de news:
À (at) Mon, 6 Nov 2006 17:26:51 +0100,
C'est donc bien un problème d'encodage... Votre base MySQL est-elle configurée pour gérer l'UTF8 ? Normalement, DBI (et le DBD correspondant) le gère bien mais encore faut-il que mysql l'accepte.
PS: je ne sais pas si ça a changé avec les dernières version de MySQL mais si votre base existe déjà (et contient déjà beaucoup d'information) et n'est pas en UTF8, la bascule est très fastidieuse voire dangereuse. N'oubliez pas de faire un dump des bases existantes avant de tenter la manoeuvre...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
J'utilise Mysql fournit avec Fedora 5 (5.1.22) il supporte utf8... je vais essayer de tester ca sur une autre version.
"Paul Gaborit" <Paul.Gaborit@invalid.invalid> a écrit dans le message de
news: wt9ejsg3450.fsf@marceau.enstimac.fr...
À (at) Mon, 6 Nov 2006 17:26:51 +0100,
C'est donc bien un problème d'encodage... Votre base MySQL est-elle
configurée pour gérer l'UTF8 ? Normalement, DBI (et le DBD
correspondant) le gère bien mais encore faut-il que mysql l'accepte.
PS: je ne sais pas si ça a changé avec les dernières version de MySQL
mais si votre base existe déjà (et contient déjà beaucoup
d'information) et n'est pas en UTF8, la bascule est très fastidieuse
voire dangereuse. N'oubliez pas de faire un dump des bases existantes
avant de tenter la manoeuvre...
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
J'utilise Mysql fournit avec Fedora 5 (5.1.22) il supporte utf8... je vais
essayer de tester ca sur une autre version.
C'est donc bien un problème d'encodage... Votre base MySQL est-elle configurée pour gérer l'UTF8 ? Normalement, DBI (et le DBD correspondant) le gère bien mais encore faut-il que mysql l'accepte.
PS: je ne sais pas si ça a changé avec les dernières version de MySQL mais si votre base existe déjà (et contient déjà beaucoup d'information) et n'est pas en UTF8, la bascule est très fastidieuse voire dangereuse. N'oubliez pas de faire un dump des bases existantes avant de tenter la manoeuvre...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
J'utilise Mysql fournit avec Fedora 5 (5.1.22) il supporte utf8... je vais essayer de tester ca sur une autre version.
JalaL
Je me demande s'il y a une variable ou conftion du module DBI qui specifie l'encodage a passer a mysql. On dirait que la fonction do() reconvertit mon texte passé dans la requete sql en utf8 meme s'il est deja en utf8
Je me demande s'il y a une variable ou conftion du module DBI qui specifie
l'encodage a passer a mysql. On dirait que la fonction do() reconvertit mon
texte passé dans la requete sql en utf8 meme s'il est deja en utf8
Je me demande s'il y a une variable ou conftion du module DBI qui specifie l'encodage a passer a mysql. On dirait que la fonction do() reconvertit mon texte passé dans la requete sql en utf8 meme s'il est deja en utf8
Emmanuel Florac
Le Tue, 07 Nov 2006 14:12:20 +0100, JalaL a écrit :
Je me demande s'il y a une variable ou conftion du module DBI qui specifie l'encodage a passer a mysql. On dirait que la fonction do() reconvertit mon texte passé dans la requete sql en utf8 meme s'il est deja en utf8
C'est curieux, tu utilises les placeholders dans tes requêtes ou pas?
-- Mais monsieur, voudriez-vous que je me l'écorchasse? Barbey d'Aurevilly.
Le Tue, 07 Nov 2006 14:12:20 +0100, JalaL a écrit :
Je me demande s'il y a une variable ou conftion du module DBI qui specifie
l'encodage a passer a mysql. On dirait que la fonction do() reconvertit mon
texte passé dans la requete sql en utf8 meme s'il est deja en utf8
C'est curieux, tu utilises les placeholders dans tes requêtes ou pas?
--
Mais monsieur, voudriez-vous que je me l'écorchasse?
Barbey d'Aurevilly.
Le Tue, 07 Nov 2006 14:12:20 +0100, JalaL a écrit :
Je me demande s'il y a une variable ou conftion du module DBI qui specifie l'encodage a passer a mysql. On dirait que la fonction do() reconvertit mon texte passé dans la requete sql en utf8 meme s'il est deja en utf8
C'est curieux, tu utilises les placeholders dans tes requêtes ou pas?
-- Mais monsieur, voudriez-vous que je me l'écorchasse? Barbey d'Aurevilly.
JalaL
"Emmanuel Florac" a écrit dans le message de news:
C'est curieux, tu utilises les placeholders dans tes requêtes ou pas?
-- Mais monsieur, voudriez-vous que je me l'écorchasse? Barbey d'Aurevilly.
Non, devrais-je le faire ?
Les place holders ces les ? qu'on met a la place des valeurs recherchées dans prepare() et qu'on remplace par les valeurs qu'on cherche dans execute() ?
"Emmanuel Florac" <eflorac@imaginet.fr> a écrit dans le message de news:
pan.2006.11.07.21.28.22.249459@imaginet.fr...
C'est curieux, tu utilises les placeholders dans tes requêtes ou pas?
--
Mais monsieur, voudriez-vous que je me l'écorchasse?
Barbey d'Aurevilly.
Non, devrais-je le faire ?
Les place holders ces les ? qu'on met a la place des valeurs recherchées
dans prepare() et qu'on remplace par les valeurs qu'on cherche dans
execute() ?
"Emmanuel Florac" a écrit dans le message de news:
C'est curieux, tu utilises les placeholders dans tes requêtes ou pas?
-- Mais monsieur, voudriez-vous que je me l'écorchasse? Barbey d'Aurevilly.
Non, devrais-je le faire ?
Les place holders ces les ? qu'on met a la place des valeurs recherchées dans prepare() et qu'on remplace par les valeurs qu'on cherche dans execute() ?
Emmanuel Florac
Le Wed, 08 Nov 2006 13:17:23 +0100, JalaL a écrit :
Non, devrais-je le faire ?
En tout cas c'est vivement recommandé dans toutes les docs sur DBI.
Les place holders ces les ? qu'on met a la place des valeurs recherchées dans prepare() et qu'on remplace par les valeurs qu'on cherche dans execute() ?
Oui, c'est ça. Peut-être que si tu laisses DBI faire la manip, ça évitera la double-conversion? (je cherche, je cherche :)
-- "Dope will get you through times of no money better than money will get you through times of no dope." Freewheelin' Franklin
Le Wed, 08 Nov 2006 13:17:23 +0100, JalaL a écrit :
Non, devrais-je le faire ?
En tout cas c'est vivement recommandé dans toutes les docs sur DBI.
Les place holders ces les ? qu'on met a la place des valeurs recherchées
dans prepare() et qu'on remplace par les valeurs qu'on cherche dans
execute() ?
Oui, c'est ça. Peut-être que si tu laisses DBI faire la manip, ça
évitera la double-conversion? (je cherche, je cherche :)
--
"Dope will get you through times of no money better
than money will get you through times of no dope."
Freewheelin' Franklin
Le Wed, 08 Nov 2006 13:17:23 +0100, JalaL a écrit :
Non, devrais-je le faire ?
En tout cas c'est vivement recommandé dans toutes les docs sur DBI.
Les place holders ces les ? qu'on met a la place des valeurs recherchées dans prepare() et qu'on remplace par les valeurs qu'on cherche dans execute() ?
Oui, c'est ça. Peut-être que si tu laisses DBI faire la manip, ça évitera la double-conversion? (je cherche, je cherche :)
-- "Dope will get you through times of no money better than money will get you through times of no dope." Freewheelin' Franklin