insertion des caracteres : ’ et ‘ dans la bd

Bonjour,

j'ai dans ma servlet une requête SQL "insert into" pour enregister des données dans une table d'une base de données mysql.

tous les caractères spéciaux s'enregistrent bien : é, è, à, ' et " (j'ai programmé une methode comme addslashes de php pour remplacer ' par \' et " par \", et ça marche bien).

sauf les deux caractères : ’ et ‘, ils sont remplacé dans la bd par : ?

j'ai essayé la même requête en php pour la même table de la même bd et ça marche bien, il n y a aucun probleme avec ces deux caracteres, alors je suppose que le probleme est en java et pas en mysql

il y a quelque'un qui peut m'aider ?

(j'utilise eclipse, tomcat 6.0 et mysql 4 sous windows xp)

merci d'avance

bon d'abord les truc à la addslashes on évite, c'est source de sql injection, on préfère les prépared statements qui sont bien plus correct.

Ensuite, pour ton caractère, il faut voir à quel niveau il est mangé.

Ca peut etre lors du transfert client web -> servlet (peu probable si les é è marchent)
Ca peut etre un mauvais encodage etre ton driver jdbc et ton serveur sql (toujour si possible, préférer l'utf-8 des deux coté)
Ca peut la table en question qui a été stockée avec un encodage ne reconnaissant pas ces caractère particulier.

Vu ta descrition, c'est probablement le deuxième cas. Essaie de mettre une "characterEncoding=utf-8" dans ton url jdbc

problème résolu grâce à toi tchize.

j'avais l'encodage latin1 (iso-8859-1) dans ma bd, alors ça marche par php et ça marche pas par java, même lorsque j'ai met characterEncoding=utf8 dans l'url de jdbc.

alors j'ai dù changer les deux :
1. créer la base avec l'interclassement et le jeu de caractères UTF8 : CREATE DATABASE nombd CHARACTER SET utf8 COLLATE utf8_general_ci

2. ajouter l'encodage dans l'url jdbc :
jdbc:mysql://hostname:port/database?autoReconnect=true&useUnicode=true&characterEncoding=utf8

tu peux m'expliquer un peu comment addslashes laisse des failles sql injection ? et comment je dois les corriger avec prépared statements, parce que j'utilise toujours addslashes pour sécuriser cette vulnérabilité.

Merci beaucoup Tchize.

étonnant que çà aie passé en php, il a probablement du faire une correction, car les charset ISO-8859-1 ne contient simplement pas les deux caractère mentionné. Il y a bien des ' et `, mais pas de ’ ni de ‘ http://fr.wikipedia.org/wiki/ISO_885....A0_ISO-8859-1

Pour le addslashes, le problème c'est qu'il "slashe" des caractères considérés comme dangereux dans les database sql. Hors, de mémoire, on a eu un trou monumental de sécurité à un moment donné avec cette fonction. Quand on a découvert que le guillemet inversé (ou qqch de similaire) pouvait aussi être utilisé comme séparateur avec msql et que addslashes ne le connaissait pas.

Disons en gros que çà requiert
1) que ta fonction addslashes que t'as codé fonctionne correctement dans TOUS les cas de figure (comme c'est un parsing partant de présupposés, c'est déjà un gros risque)
2) que le set de caractères dit dangereux soit connu entièrement
3) que le programmeur n'oublie pas par mégarde un appel sur un des paramètres (une distraction çà arrive).

Un prepared statement, au contraire, n'as pas ces risques, puisqu'on passe les paramètres à part de la requete. Ils sont donc complètement isolé dès le départ et sans traitement particulier:

Code:

---

1 2 3

PreparedStatement pstmt = con.prepareStatement("UPDATE EMPLOYEE SET SALARY = ? WHERE ID = ?"); pstmt.setBigDecimal(1, 153833.00) pstmt.setInt(2, 110592)

---

Note que tu as aussi l'avantage que les variable sont typées. Par exemple, si tu doit jouer avec un date, tu fais un setDate(index,valeur) et t'as pas à te soucier de la représentation interne à la db, tu passe simplement un java.sql.Date.

voila ma solution, je vais transformer ma fonction addslashes à mysql_real_escape_string, par ajouter un slash aux tous les caractères spéciaux de mysql : NULL, \x00, \n, \r, \, ', " et \x1a.

Tu pense que c'est suffisant ?

personnellement, je trouve les prepared statements plus facile à lire, plus facile à écrire et plus sécurisant. Maintenant, question de choix personnel.