Bonjour, j'utilise comme interclassement sur ma BD "utf8_general_ci". Cependant sur certaines de mes requêtes SQL j'utilise un "COLLATE utf8_bin" afin de différencier les majuscules des minuscules, et cette solution fonctionnait très bien lorsque je travaillais en local (avec Wampserver).

Aujourd'hui j'ai décidé d'héberger mon site (sur Hostinger), et mes requêtes qui utilisent ce COLLATE ne fonctionnent plus, elles ne retournent plus rien.

Quelqu'un aurait une idée, afin de résoudre ce problème ? Merci d'avance.

-
Edité par Kévin_ 27 avril 2021 à 16:36:03

Bonjour,

Kévin_ a écrit:

mes requêtes qui utilisent ce COLLATE ne fonctionnent plus, elles ne retournent plus rien

Même pas une erreur ?

Cela peut provenir d'une version "obsolète" de MySQL (genre 5.1) chez l'hébergeur, contre une version récente sur WAMP (5.7 voire 8).

Je ne sais pas comment résoudre le problème sauf à modifier tes requêtes pour utiliser des UPPERCASE dans tes comparaisons ...

Non, aucune erreur 

J'utilisais la version 5.7.26 avec WAMP, je ne connais pas la version utilisée par Hostinger (je ne sais pas comment la voir). Sinon comment je pourrai faire avec des UPPERCASE ?

EDIT :

J'ai trouvé ceci sur mon tableau de bord Hostinger :

-
Edité par Kévin_ 27 avril 2021 à 17:25:25

10.4 c'est une version MariaDB (fork de MySQL), datant de juin 2019 (un peu vieille mais pas tant) ... qui correspondrait à MySQL 5.7 ... Cela me paraît bizarre que COLLATE pose un souci ...

Peux-tu poster le code où tu utilises le COLLATE ?

Voici le code :

if(isset($valider)){
        // Vérifie que les identifiants sont correctes
        $req_login=$pdo->prepare("SELECT * FROM users WHERE login=? COLLATE utf8_bin AND password=? limit 1");
        $req_login->setFetchMode(PDO::FETCH_ASSOC);
        $req_login->execute(array($login,md5($password)));
        $tlog=$req_login->fetchAll();
        if(count($tlog)==0)
            $message="Nom d'utilisateur ou mot de passe incorrect";
        else{
            // Passage de variables en session si connexion
            $_SESSION["autoriser"] = "oui";
            $_SESSION["prenom"] = $tlog[0]["prenom"];
            $_SESSION["login"] = $tlog[0]["login"];
            $_SESSION["entite"] = $tlog[0]["entites"];
            $_SESSION["niveau"] = $tlog[0]["level"];
            $_SESSION["admin"] = $tlog[0]["admin"];
            header("location:session.php");
        }
    }

Et à chaque tentative de connexion sur le site hébergé, ça me met mon message d'erreur "Nom d'utilisateur ou mot de passe incorrect", alors que sur Wamp je n'ai pas ce problème. Lorsque j'enlève le COLLATE sur Hostinger, je n'ai plus le souci (cependant les minuscules-majuscules ne sont plus prises en compte).

PS : je sais que md5 n'est pas recommandé pour les mots de passe, je le changerai à therme.

-
Edité par Kévin_ 27 avril 2021 à 18:07:49

Kévin_ a écrit:

Non, aucune erreur

Es-tu bien sûr d'avoir activé les erreurs PHP et PDO ?

Ensuite vérifie l'encodage général de la base de données :

SELECT * FROM informatio_schema.SCHEMATA

Il est possible que la base soit créée en utf8mb4, qui ne fonctionnera pas avec utf8_bin, mais avec utf8mb4_bin :

SELECT *
FROM users
WHERE
    login = ? COLLATE utf8mb4_bin
    AND password = ?
LIMIT 1

Je pensais pas qu'il y avait besoin de les activer , et en effet avec "utf8mb4_bin" cela fonctionne. Est-il possible de reconvertir en utf8 la base (à moins que'utf8mb4 soit mieux) ?

Cela signifie que tu n'avais pas activé les erreurs PDO, car tu devais avoir une erreur "Invalid collation for utf8mb4 schema"

En mode développement (ou debuggage) c'est impératif ...

Pour PHP : https://www.php.net/manual/fr/function.error-reporting.php

Pour PDO : https://www.php.net/manual/fr/pdo.error-handling.php

Dans une prochaines version de PHP, les erreurs devraient être activées par défaut ... à suivre ...

Kévin_ a écrit:

Est-il possible de reconvertir en utf8 la base (à moins que'utf8mb4 soit mieux) ?

Pour changer le charset de ta base :

ALTER DATABASE nom_de_la_base CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

Attention, je ne pense pas que tu puisses faire cela chez toi hébergeur (droits limités), seulement sur ton serveur local.

Sinon, l'encodage UTF8 utilise 4 octets pour stocker un caractère. MySQL dans son imperfection avait implémenté UTF8 seulement sur 3 octets (on pourrait dire utf8mb3). utf8mb4 a été mis en place dans MySQL assez récemment pour compenser ce problème qui créé des erreurs notamment sur les caractères "exotiques" nécessitant réellement 4 octets pour être stockés ...

Pour des caractères de la langue française (ou des langues latines en général) utf8mb3 est suffisant, tu ne rencontreras pas de souci avec, mais si un jour tu stockes du chinois, de l'arabe ou autre caractères exotiques, alors tu auras des soucis ...

Il est donc préférable de migrer ta base en utf8mb4 pour la pérennité.

Merci beaucoup de ton aide, tu m'as appris beaucoup, et aussi résolu mon problème !