Construire une requête SQL Comment isoler les guillemets dans une requête. par Django (Oznog) Blais, Trucsweb (13 Décembre 2000)
Une base de données n’a pas vraiment de problème avec les guillemets et les apostrophes. Et c’est tout à fait faux de dire que le langage ou les requêtes SQL n’acceptent pas les apostrophes. L’interprétation d’une chaîne de caractères qui contient des guillemets n’est pas non plus un problème.
Qu'est-ce qu'il y a de spéciale avec une requête SQL c'est qu'elle est elle-même
une chaîne de caractère. Vous savez tous qu'une chaîne de caractère est généralement
construite à l'aide de guillemets ou d'apostrophe pour délimiter le début et la
fin de la chaîne. Alors quand il est question de chaîne à l'intérieur d'une autre
chaîne il y a nécessairement une méthode à suivre.
La méthode n'a d'ailleurs rien à voir avec les requêtes SQL, mais bien avec le
langage qui manipule une requête SQL. En outre, chaque langage à sa propre façon
de manipuler les chaînes de caractères indépendamment de l'utilisation du langage
SQL.
Prenons une requête SQL simple, noter que c'est une chaîne de caractère, qu'il
faut donc la délimiter pas des guillemets.
Requete = "SELECT * FROM tutoriels WHERE no=1"
Cet exemple ne pose aucun problème parce qu'il n'y a aucune autre chaîne imbriquée
à l'intérieur, simplement parce que la recherche est effectuée sur un nombre (no=1).
Mais si vous désirez faire une requête sur un champ " texte
" vous devrez ajouter les apostrophes autour de la chaîne à rechercher.
Requete = "SELECT * FROM tutoriels WHERE titre='titre'"
Puisque notre requête est elle même la construction d'une chaîne de caractère
qui va devoir inclure l'identification d'une autre chaîne (et je précise bien
L'IDENTIFICATION d'une autre chaîne et non pas la
fusion des deux chaînes) il faut utiliser un IDENTIFIANT différent de celui qui
identifie notre requête. C'est pourquoi nous utilisons les guillemets pour identifier
la chaîne " requête " et l'apostrophe pour identifier la chaîne de recherche.
Le contraire est aussi possible :
Requete = 'SELECT * FROM tutoriels WHERE titre="titre"'
Jusque là tout va bien mais si la chaîne de recherche contient une apostrophe
ou un guillemet la construction de la chaîne ne sera pas bien interprétée.
Requete = "SELECT * FROM tutoriels WHERE titre='L'apostrophe
démystifiée'"
Ainsi, cette requête provoquera une erreur parce qu'elle ne comprendra pas tout
ce qui suit l'apostrophe du L. Or donc, " apostrophe
démystifiée' " sera un intrus dans la construction terminée par le guillemet.
En résumé, indépendamment du SQL, tout langage qui manipule une chaîne de caractères
qui contient le même symbole réservé utilisé pour délimiter la chaîne (comme l'apostrophe
ou le guillemet) provoquera une erreur.
Var = 'l'apostrophe'; provoquera
une erreur en Javascript.
C'est pourquoi tous les langages de programmation utilisent une autre mnémonique
pour indiquer que le caractère qui suit ne doit pas être interprété comme un symbole
réservé mais bien comme un simple caractère.
Dans la plupart des langages, comme le Javascript, le Java ou JSP, C, etc, c'est
la barre oblique ou " slash " \ qui est utilisée.
Même chose qu'avec les expressions régulières. Ainsi la barre oblique dans cette
chaîne indique que l'apostrophe doit être interprétée comme un caractère. ex :
" L\'apostrophe "
En ASP ce n'est pas pareil, il faut doubler le caractère, ex : " L''apostrophe
". Sacré Microsoft !
Exemple :
"Un ""mot""
entre guillemets" ou 'L''apostrophe'
En pratique : Une requête.
Vous devez pointer un enregistrement dans une base de données en SQL avec le ASP
et l'argument est une chaîne de caractère. Votre recherche s'effectue sur le titre
d'un tutoriel par exemple et vous désirez trouver l'enregistrement " L'apostrophe
démystifiée ".
Requete = "SELECT * FROM tutoriels WHERE titre='L''apostrophe
démystifiée'"
Ou
ntitre = "L''apostrophe démystifiée"
Requete = "SELECT * FROM tutoriels WHERE ntitre='"
& titre & "'"
En pratique : Mise à jour.
La mise à jour c'est la même chose seulement si vous construisez une chaîne SQL,
généralement avec " INSERT INTO ".
ntitre = "L''apostrophe démystifiée"
ntexte = "le texte…"
Requete = "INSERT INTO tutoriels (titre,texte)"
Requete = Requete & "VALUES ('" & ntitre
& "','" & ntexte
& "')"
Si vous n'utilisez pas de chaîne SQL et modifier directement un champ, vous n'avez
pas besoin de doubler les guillemets.
Exemple :
ntitre = "L'apostrophe démystifiée"
ntexte = "le texte…"
connexion.AddNew
connexion.Fields("titre") = ntexte
connexion.Fields("texte") = ntitre
connexion.update
Non seulement cela fonctionne mais si vous aviez doublé l'apostrophe, les deux
apostrophes seraient sauvées dans la base.
Automatiser le tout.
Une bonne façon de faire et de créer une petite routine pour convertir les chaînes
de caractères.
Exemple :
Function DoubleGuillemets(chaine)
chaine = Replace(chaine, """, """")
DoubleGuillemets = chaine
End Function
Function DoubleApost(chaine)
chaine = Replace(chaine, "'", "''")
DoubleApost = chaine
End Function
ntitre = 'L'apostrophe'
DoubleGuillemets (ntitre)
' ntitre est contient maintenant des guillemets doubles.
Noter que la fonction " Replace " en ASP a très mauvaise
réputation, lente etc. Je vous conseil donc de créer votre propre replace qui
est considéré plus performant.
Function DoubleApost(chaine)
Dim i
Dim modif
For i = 1 to len(chaine)
If mid(chaine,i,1)="'" then
modif = modif & "''"
Else
modif = modif & mid(chaine,i,1)
End if
Next
DoubleApost = modif
End Function
Function DoubleGuillemets(chaine)
Dim i
Dim modif
For i = 1 to len(chaine)
If mid(chaine,i,1)="'" then
modif = modif & "''"
Else
modif = modif & mid(chaine,i,1)
End if
Next
DoubleGuillemets = modif
End Function
Petit conseil
Ne sauvegardez jamais dans une base une chaîne modifiée (par exemple avec des
doubles guillemets) pensant par la suite éviter un traitement. Sauver toujours
vos informations le plus brut possible. Par exemple, n'ajouter pas les balises
HREF dans un texte qui comporte des hyperliens. C'est lors de l'affichage d'un
texte qu'il faut le manipuler. Ça semble contraire aux pratiques du programmeur
de refaire toujours le même traitement qui pourrait être fait une seule fois mais
une loi l'emporte cette fois-ci. C'est la loi de la portabilité. En effet, on
ne sait jamais ce qui peut arriver à une base de données ni ce que les langages
de demain vont nous apporter. Un texte brut sera toujours valide alors qu'un texte
altéré pour usage local ne le sera pas.
|
