Page 1 sur 1
Faire un SELECT case-sensitive
Posté : 10 janv. 2008, 18:06
par VaN
Bonjour,
Je viens de m'appercevoir que SQL n'était pas case-sensitive, et cela me pose un problème, avec un formulaire d'ouverture de session, sur lequel je peux me logger aussi bien en fournissant 'Van' que 'VaN' comme login. Or, à long terme, il se pourrait que deux utilisateurs ait le meme login, par exemple 'toto' et 'ToTo'. Est-il possible de transformer ma requete SQL, pour qu'elle gere les majuscules/minuscules ?
Posté : 10 janv. 2008, 18:16
par Calimero
Bonjour,
As-tu bien lu le message en gras et en rouge qui s'affichait sur ton écran quand tu as posté ce message dans ce forum ? Pour mémoire :
Code : Tout sélectionner
Rappel pratique - n'oubliez pas de :
1. suivre ces quelques conseils de débogage
2. préciser quel SGBD vous utilisez ainsi que sa version
3. utiliser les balises [code] et pour afficher vos requêtes SQL
4. poster le schéma des tables pertinentes à votre requête sous la forme d'une instruction "CREATE TABLE" (fonction "Exporter" de phpMyAdmin)
5. si nécessaire, poster un échantillon des données sous la forme d'une instruction "INSERT INTO"
Attention, suivre ces consignes est obligatoire. Merci de les lire attentivement.
[/code]
(C'est simple : aide-nous, et on t'aidera
). Merci d'avance.
Posté : 10 janv. 2008, 18:20
par VaN
phpMyAdmin - 2.9.1.1
* Version du client MySQL: 5.0.22
Je pense que c'est la seule information pertinente, dans celles que tu viens de citer.
Je vais aussi copier ma requete, bien qu'elle ne soit d'aucune utilité, vu que c'est une question d'ordre général, qui peut s'appliquer à n'importe quelle requete j'imagine.
Code : Tout sélectionner
$sql = sprintf("SELECT user_id, user_login, user_level FROM users WHERE user_pass ='%s' AND user_login ='%s'",
mysql_real_escape_string($mdp),
mysql_real_escape_string($login));
Posté : 10 janv. 2008, 18:23
par Sékiltoyai
La structure de ta table aussi…
Posté : 10 janv. 2008, 18:25
par VaN
La structure de ta table aussi…
here it is :
Posté : 10 janv. 2008, 18:30
par Calimero
En l'occurence ta requête fonctionne en case-insensitive mais ce n'est pas dans la requête, mais dans le type de champ que se trouve la réponse (c'est entre autres pour cela qu'il y a plusieurs types de champ texte dans MySQL).
Si tu passes tes champs user_login et user_pass en type CHAR ou VARCHAR, tout marchera en case-sensitive.
Posté : 10 janv. 2008, 18:35
par VaN
après lecture du manuel SQL, je crois comprendre que la différence en CHAR et VARCHAR est une histoire de remplissage d'octets libre (par rapport au nombre d'octets attribués au champ). Quel est le type le plus pertinent, pour des champs sauvegardant des login/pass ?
Posté : 10 janv. 2008, 18:41
par Calimero
après lecture du manuel SQL, je crois comprendre que la différence en CHAR et VARCHAR est une histoire de remplissage d'octets libre (par rapport au nombre d'octets attribués au champ). Quel est le type le plus pertinent, pour des champs sauvegardant des login/pass ?
Tu as raison. Opte pour un VARCHAR. En effet, l'autre pourrait poser problème dans certains cas particuliers (mot de passe comportant un espace final, par exemple).
Posté : 10 janv. 2008, 18:43
par VaN
Ok merci. Je pense définir le nombre d'octets sur 20, ça me semble plus que correct pour un login. j'imagine qu'il faut aussi penser à vérifier la longueur du login au moment de l'inscription, via une fonction PHP ?
EDIT : ça ne semble par marcher. Je viens de tester, je peux toujours me logger avec mon login, écrit en minuscule.
EDIT #2 : C'est en fait VARCHAR qui ne fonctionne pas comme mentionné. CHAR , lui, semble etre case-sensitive, apres test. Pas VARCHAR.
Posté : 11 janv. 2008, 10:23
par mojorisin
Salut,
le problème viens de l'interclassement utilisé par tes tables : tu utilises un latin1_swedish_ci ou le "ci" veut dire case insensitive.
Modifies tes champs pour du latin1_general_cs par exemple ou "cs" veut dire case sensitive.
Ensuite cela devrait fonctionner comme tu le souhaites.
Si ce n'est toujours pas le cas il faut regarder du coté de l'interclassement de la connexion au serveur.
Pour plus d'information il faut que tu lise le manuel mysql sur l'interclassement et les collations.
Jeux de caractères et collation : généralités
internationalisation
Posté : 11 janv. 2008, 12:05
par Xenon_54
Salut,
le problème viens de l'interclassement utilisé par tes tables : tu utilises un latin1_swedish_ci ou le "ci" veut dire case insensitive.
Modifies tes champs pour du latin1_general_cs par exemple ou "cs" veut dire case sensitive.
Je plussois. C'était la réponse que je voulais donner.
Posté : 11 janv. 2008, 12:16
par Calimero
Salut,
le problème viens de l'interclassement utilisé par tes tables : tu utilises un latin1_swedish_ci ou le "ci" veut dire case insensitive.
Modifies tes champs pour du latin1_general_cs par exemple ou "cs" veut dire case sensitive.
Je plussois. C'était la réponse que je voulais donner.
Tu aurais dû le faire. Je réalise dans ce post que mes connaissances sur le sujet sont approximatives (basées uniquement sur l'expérience) et que j'ai besoin d'un bon rafraichissement sur la théorie. Je m'en vais lire la documentation pour combler mes lacunes.
Comme quoi, on a beau être ViPHP, on peut toujours apprendre des choses
Posté : 11 janv. 2008, 21:16
par VaN
Salut,
le problème viens de l'interclassement utilisé par tes tables : tu utilises un latin1_swedish_ci ou le "ci" veut dire case insensitive.
Modifies tes champs pour du latin1_general_cs par exemple ou "cs" veut dire case sensitive.
Ensuite cela devrait fonctionner comme tu le souhaites.
Si ce n'est toujours pas le cas il faut regarder du coté de l'interclassement de la connexion au serveur.
Pour plus d'information il faut que tu lise le manuel mysql sur l'interclassement et les collations.
Jeux de caractères et collation : généralités
internationalisation
parfait, Latin1_general_cs marche parfaitement, merci. Une bonne info ça, puisque ça me permettra, lorsque je créérai d'autres tables USERS, de spécifier ces champs de cette maniere.