En refaisant ma requête je viens de m'apercevoir que j'ai une erreur fatale lorsque je met un accent dans le moteur de recherche.
Ce qui est bizarre c'est que quand je met par exemple du "blés" avec le s à la fin, ça me sort bien tout ce qui contient blés (actuellement) bles puisque j'enlève les accents. Mais si je mets un "blé" sans S j'obtiens cette erreur:
Fatal error: Uncaught PDOException: SQLSTATE[HY000]: General error: 1267 Illegal mix of collations (latin1_general_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation 'like' in /htdocs/fleurs.php:103 Stack trace: #0 /htdocs/fleurs.php(103): PDOStatement->execute(Array) #1 {main} thrown in /htdocs/fleurs.php on line 103
Dès que le mot recherché fini par un accent il y a cette erreur, mais si il fini par une lettre supplémentaire après l'accent, là pas de soucis :/ Vous auriez une idée?
Voici la requête:
if !empty($_GET['rechuser']))
{
$rechuser = ($_GET['rechuser']);
$avecaccent = array("é", "è", "ê","ô", "ù","û", "â", "à", "ç", "î");
$sansaccent = array("e", "e", "e","o", "u","u", "a", "a", "c", "i");
$rest = substr($rechuser, 0, -1);
$newsearch = str_replace($avecaccent, $sansaccent, $rest);
$rechqueryuser = $bdd->prepare('
SELECT tab_fichesgraines.ch_graines_id,
ch_graines_espece,
ch_graines_sous_espece,
ch_graines_photo,
tab_commentaires.ch_com_id_article
FROM tab_fichesgraines
INNER join tab_commentaires
ON tab_commentaires.ch_com_id_article = tab_fichesgraines.ch_graines_id
WHERE tab_fichesgraines.ch_graines_espece LIKE ?
ORDER BY ch_graines_sous_espece ASC
'
);
$rechqueryuser->execute(array("%$newsearch%"));
Merci beaucoup!
- Edité par Jagguerjack 30 novembre 2020 à 21:17:47
"Tu as renseigné le paramètre charset dans le DSN de ta connexion PDO ?" Je penses que tu parles de ceci ?
$bdd= new PDO('mysql:host=****; dbname=****;charset=utf8', '****', '****', array(PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION));
Par contre je viens de voir dans ma bdd que mes colonnes sont en :
Ça pourrait venir de là?
Je pensais remplacer les accents par les lettres sans accent pour que lorsqu'un membre fait une recherche de ce style "ble" il est quand même le "blé" qui ressorte, j'ai créé une colonne avec tous les noms sans accent pour ça. Du coup ce n'est pas bon?
Corrigé pour la parenthèse merci )
- Edité par Jagguerjack 1 décembre 2020 à 11:02:39
Ca ne peut être qu'une erreur de "recopiage" parce qu'il aurait eu une erreur de syntaxe PHP, son code n'en serait pas exécuté et il n'aura jamais obtenu d'erreur SQL.
> Du coup ce n'est pas bon?
Non, ça ne sert à rien, MySQL s'en charge déjà avec un interclassement suffixé de _ci, et ce que tu fais n'est pas complet non plus.
Je ne comprends pas trop que tes tables soient en latin1 si ton site est en UTF-8. Mais je ne garantis pas que changer l'interclassement (et le jeu de caractères) de tes colonnes fixe le problème. Tout dépend à quoi correspond exactement le "latin1_general_ci,IMPLICIT" et j'ai peur que ce ne soit pas forcément celui de la colonne (la table ou la base ?). Si tu n'as pas peur de casser quelque chose (mais avec le ;charset=utf8 tu ne devrais pas avoir de problème) ou peut faire une sauvegarde avant de ta base, essaie de changer l'interclassement (celle de tab_fichesgraines.ch_graines_espece) pour de l'utf8_general_ci.
Pour la parenthèse ça vient du fait que j'ai enlevé un "if isset" avant j'avais
if(isset($_GET['rechuser']) AND !empty($_GET['rechuser']))
qui ne servait pas sur conseil d'Aurélien mais du coup j'ai oublié la parenthèse.
"Non, ça ne sert à rien, MySQL s'en charge déjà avec un interclassement suffixé de _ci, et ce que tu fais n'est pas complet non plus." Ah, du coup si j'enlève
et que le membre fait une recherche sans accent, les résultats avec accent sortiront? et vice versa? Quand tu dis que ce n'est pas complet c'est a quel niveau?
Je vais essayé de changer l'interclassement et effectuer une sauvegarde de la table avant, j'espère pas faire de bêtise . Thx pour votre aide
RE-EDIT: je mettais trompé de colonne quand j'ai changé l'interclassement. Du coup ta solution fonctionne Julp Merci beaucoup!
Je vais ressayé de voir en changeant l'interclassement sur l'autre colonne ( celle avec accents) et voir si la recherche qu'elle soit avec accent ou sans accent, tous les resultats sont bien tous pris en comptes. Je reviens vous dire ça!
EDIT: Du coup: quand je tappe dans le moteur de recherche: ble = tous les résultats sortent bien avec accents et sans accents. bl= tous les résultats sortent bien avec accents et sans accents. blés= tous les résultats sortent bien avec accents et sans accents. blé = aucun résultat pour cette recherche
Je comprends pas. Même avec le $rest = substr($rechuser, 0, -1); il devrait prendre en compte "bl" comme recherche non? Peut être faut- il que j'ouvre un nouveau post dans le forum? ça n'a plus trop rapport avec la première erreur?
- Edité par Jagguerjack 1 décembre 2020 à 13:26:23
> et que le membre fait une recherche sans accent, les résultats avec accent sortiront? et vice versa?
Oui, ce genre d'interclassement ignore casse et accents.
> Quand tu dis que ce n'est pas complet c'est a quel niveau?
Que tu ne gérais pas les majuscules, les ë, etc
> Je comprends pas. Même avec le $rest = substr($rechuser, 0, -1); il devrait prendre en compte "bl" comme recherche non?
substr est incompatible avec UTF-8, pour blé, le é est encodé sur 2 octets mais tu l'en tronques en plein milieu, entre le premier et le second de ses octets donc ce n'est pas étonnant que ça foire derrière.
De toute façon, tu n'en as plus besoin si tu te reposes (correctement) sur l'interclassement, non ? Si vraiment tu voulais faire je ne sais quoi par rapport au dernier caractère, ici, c'est la fonction mb_substr, qui elle est compatible avec UTF-8 et prend en compte le jeu de caractères, qu'il aurait fallu employer.
J'ai dû un peu trop survoler le post initial pour m'arrêter sur le message d'erreur : je n'aurais pas sinon loupé l'incompatibilité de substr avec UTF-8 et le fait que tu coupais un caractère (point de code) en plein milieu de sa représentation explique totalement l'erreur obtenue. Cela dit, même si tu pouvais quand même avoir des colonnes en latin1, si le site est en UTF-8, c'est tout de même préférable de stocker également les données en UTF-8, surtout que ça évite à MySQL de faire les conversions latin1 (CP1252) <=> UTF-8
Du coup je vais passé les maximum de tables en utf8, mais je vais peut être garder les messages privés en latin? car quand je change les table en utf8 ça me change tous les caractère spéciaux en "?", c'est pas top pour les membres :/. Je vais voir. Sinon je ferais un mail groupé pour leur expliquer, ça sera peut être embêtant pour les messages déjà reçus mais bien mieux pour la suite ? A moins qu'il y ait un moyen pour gérer le changement correctement?
Je vais utiliser le mb_substr pour le coup, c'est pour enlever les pluriels dans les recherches, car avant si je tapais "blettes" les "blette" ne ressortais pas. Du coup j'ai enlevé le dernier caractère et ça marche correctement
"Que tu ne gérais pas les majuscules, les ë, etc" Effectivement c'est pas complet pour les MAJ et autres .
Merci pour tes conseils
- Edité par Jagguerjack 1 décembre 2020 à 21:00:16
> je vais peut être garder les messages privés en latin? car quand je change les table en utf8 ça me change tous les caractère spéciaux en "?", c'est pas top pour les membres :/
En effet. Un '?' ou un '�' ? Au niveau de la base de données (par exemple tu vois aussi ces "?" avec phpMyAdmin) ou c'est uniquement via ton site ?
C'est au niveau de ma BDD aussi dans les colonnes les "é" et "è".. ont étaient remplacé par par des "?"au moment ou j'ai passé la colonne en utf8. Pas vu de "�" mais certainement si je convertis la table "messages" des membres où il y a bien plus de caractère spéciaux que dans ma précédente.
Est ce que ça ne vient pas du fait que je le fais par phpmyadmin? Je me rends dans la structure de la table et je sélectionne la colonne que je passe en utf8.
J'ai vu qu'il existait des commandes dans ce style:
ALTER TABLE tbl_name CONVERT TO CHARACTER SET latin1 COLLATE 'latin1_swedish_ci';
Ça reviendrai au même?
sinon je pourrais essayer? du coup ca serait quelques chose comme ça ?
ALTER TABLE tbl_name CONVERT TO CHARACTER SET utf8 COLLATE 'utf8_general_ci';
Je viens de voir autre chose quand je me suis connecté sur ma BDD. sur la page d’accueil il y à ceci:
Toutes ces requêtes devraient proprement assurer la conversion que je sache. Ce qui me dérange, c'est que le caractère 'é' (pour ne prendre que lui pour exemple) apparaisse bien initialement et qu'il se retrouve substitué par '?' à l'issue de cette conversion. Logiquement pour obtenir '?' tu n'aurais pas eu un 'é' au départ. Ou alors l'inverse, obtenir '�' de ce 'é'.
Juste pour être sûr de bien comprendre deux points :
ça ne concerne que ta table des MP ou c'est plus généralisé ?
le é a bien été observé au niveau de phpMyAdmin ? (parce qu'au niveau du site, les données peuvent être mal encodées mais resortir normalement par un heureux hasard)
Sinon il faudrait tenter d'exporter le contenu de la (ou des) tables pour le réimporter ensuite.
"ça ne concerne que ta table des MP ou c'est plus généralisé ?" Je viens de faire le test sur une autre table. J'ai mis des éèâç, puis je suis allé dans structure et j'ai changer en utf8. et c'est arrivé aussi sur cette table. Des "???" au lieu des caractères.
"le é a bien été observé au niveau de phpMyAdmin ? (parce qu'au niveau du site, les données peuvent être mal encodées mais resortir normalement par un heureux hasard)" oui ca ressort bien dans les tables sur phpmyadmin
Par contre je n'ai pas essayé de faire la conversion via les requête mais en cliquant sur structure et en changeant dans la liste déroulante le latin en utf8
- Edité par Jagguerjack 3 décembre 2020 à 18:37:21
Si je fais le même test pourtant sur phpMyAdmin 4.1.9 et MySQL obsolète (5.0.67), j'ai éèâç avant comme après.
phpMyAdmin génère quelle requête lors de l'opération ? Quelle version de phpMyAdmin ? (elle a l'air moins récente)
Eventuellement tenter de le faire à la main, ouais, mais je pense que la meilleure option en l'état serait l'export/réimport (exporter les données > recréer les tables en utf8 - ça irait plus vite que de les changer > réimporter les données en utf8)
Fonctionnellement, tu peux garder du latin1 (je ne t'oblige pas à passer sur de l'utf8 non plus, ça fonctionnera quand même "bien") mais :
ça fait tout de même faire des conversions "inutiles" à MySQL
tu perds tous les caractères non latins
il n'est pas improbable que tu passes à de l'utf8mb4 tôt ou tard (pour les émojis notamment) donc à un moment ou un autre tu seras +/- obligé de migrer
Voila ce que je peux trouver comme infos sur l'accueil de phpmyadmin:
Je veux bien essayer de passer par l'import export mais je ne l'ai jamais vraiment fait et j'ai peur de mal faire et de perdre tous les membres, listes créée etc... Mais c'est sûr que j'aimerai repartir sur de bonnes bases. Est ce que je peux faire un test? par exemple: >exporter ma table "membres" >créer une fausse table "membres_test" >importer la table "membres" dans la "membres_test" déjà pour voir si tout se passe bien et si je récupère tous les membres?
Est ce que je peux tout faire par phpmyadmin via les onglets exporter / importer? ou bien je vais être amener à faire des requêtes?
Merci encore pour toute ton aide !
- Edité par Jagguerjack 3 décembre 2020 à 20:47:17
Si tu en as la possibilité, le plus simple serait de faire ce test sur une seconde base de données, à part.
Parce que renommer la table, si tu as des contraintes, à moins de préalablement les supprimer quand tu dupliques (la structure de) la table, ça pourrait être problématique.
> Est ce que je peux tout faire par phpmyadmin via les onglets exporter / importer?
Théoriquement, oui mais je pensais plus à l'usage de mysqldump de façon à dumper en UTF-8 et les réimporter (après vérification) comme telles (en commençant le fichier par un SET NAMES utf8;). Parce que je ne sais pas comment phpMyAdmin va se comporter et si on est susceptible de retomber sur le même problème.
"Si tu en as la possibilité, le plus simple serait de faire ce test sur une seconde base de données, à part." Je n'ai qu'une base de donnée sur cet hébergeur. Après j'en ai une seconde mais elle est sur l'hébergement gratuit de Free. Elle ne sont pas identique du coup je pense pas que ce soit faisable si?
"Parce que renommer la table, si tu as des contraintes, à moins de préalablement les supprimer quand tu dupliques (la structure de) la table, ça pourrait être problématique." J'ai pas bien saisie ce que tu veux dire :s. Je pensais pas la renommer mais en créer une nouvelle (sans supprimer l'ancienne dans un premier temps) pour essayer d’importer les donnée de "table" dans "table_test" histoire de voir si j'arrivais à récupérer toutes les données (c'est quelque chose que je n'ai jamais fais). Puis dans un second temps si tout est bien récupéré je fais la manipulation pour tout mettre en utf8. Qu'est ce que tu veux dire "contraintes"?
"mais je pensais plus à l'usage de mysqldump de façon à dumper en UTF-8 et les réimporter (après vérification) comme telles" Je ne connais pas mysqldump et comment dumper . Du coup je vais fouiner sur le net pour voir comment faire car c'est le néant total pour moi cette histoire :).
Une petite question: (avant de faire toutes ces manipulations) Je sais qu'il existe une façon d'exporter la base de donnée entière, avec les tables, les colonnes, les lignes ainsi que leurs contenus. Puis de réimporter, via phpmyadmin le fichier exporté et de tout récréer automatiquement. Les tables, les colonnes et les données. Pour ça on opère de la même façon que pour les tables? il suffit juste de cliquer sur le nom de la base de donnée et d'exporter?
> Elle ne sont pas identique du coup je pense pas que ce soit faisable si?
Etant donné que je n'ai pas pu reproduire les ???, il faudrait rester sur le même environnement.
> J'ai pas bien saisie ce que tu veux dire :s.
Je me suis mal exprimé, par renommer je voulais dire la même chose que toi : créer la même table mais sous un autre nom.
> Qu'est ce que tu veux dire "contraintes"?
Je pensais surtout aux clés étrangères.
> Je ne connais pas mysqldump et comment dumper :euh:.
Erf, l'usage de mysqldump aurait été préférable mais sans un accès console (ssh), tu ne peux pas vraiment l'utiliser.
> Pour ça on opère de la même façon que pour les tables? il suffit juste de cliquer sur le nom de la base de donnée et d'exporter?
Ne teste qu'avec une table déjà :
tu la dumpes (données + structure)
(pour ce test uniquement) tu changes (fonction rechercher/remplacer de ton éditeur) le nom de la table partout
tu changes également les jeux de caractère et interclassement partout de sa structure + éventuellement (pour ce test uniquement) virer toutes les clés étrangères
tu vérifies le jeu de caractères du fichier avec plusieurs éditeurs ou encore mieux un éditeur hexadécimal (si, par exemple, le é est encodé par 0xE9 - c'est du latin1 - contre les deux octets 0xC3 et 0xA9 c'est bien de l'utf8) bien que logiquement il devrait s'agir d'UTF-8
si phpMyAdmin n'a pas mis de SET NAMES au début du fichier tu en rajoutes un qui correspond avec celui dans lequel est encodé le fichier de dump
tu réimportes via phpMyAdmin (en espérant que la bdd n'est pas trop volumineuse)
Tu vérifies que les é sont des é et que tes colonnes sont bien en utf8, si oui, ça a fonctionné et dans ce cas, tu supprimes cette table de test, sauvegardes à nouveau l'intégralité de ta base de données (après avoir mis ton site offline de préférence) et recommence l'opération pour l'intégralité de tes tables (note : séparer structures et données pourrait être plus facile)
"Je pensais surtout aux clés étrangères." D'après ce que j'ai pu voir sur le net, pour avoir des clés étrangères, il aurait fallu que je les mettent en place manuellement. Je n'ai pas créé de relations entre les tables. Je ne pense pas en avoir du coup. La seule chose qui met en relation plusieurs tables ce sont des requêtes avec jointures. Mais je mettrais le site hors ligne pour faire les manip du coup personne n'y aura accès.
"Erf, l'usage de mysqldump aurait été préférable mais sans un accès console (ssh), tu ne peux pas vraiment l'utiliser." Du coup je ne peux pas "dumper"? Mais "Dumper" n'est pas juste sauvegarder? comme je peux le faire directement via phpmyadmin?
Je viens d'exporter une table et j'ai ouvert le fichier sql avec sublime text: Et effectivement je vois du charset: latin1
Je colle sans les données ce que dis le fichier peut être que ça sera plus clair. "pour le coup les é sont des é" et pas des "0xE9" mais je pense qu'ils apparaissent en "0xE9" avec l'éditeur de texte hexadécimal comme tu me conseilles?
-- phpMyAdmin SQL Dump
-- version 5.0.4
-- https://www.phpmyadmin.net/
--
-- Hôte : localhost
-- Généré le : sam. 05 déc. 2020 à 17:41
-- Version du serveur : 10.3.25-MariaDB-0+deb10u1
-- Version de PHP : 7.3.19-1~deb10u1
SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
START TRANSACTION;
SET time_zone = "+00:00";
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8mb4 */;
--
-- Base de données : `*****`
--
-- --------------------------------------------------------
--
-- Structure de la table `tab_fichesgraines`
--
CREATE TABLE `tab_fichesgraines` (
`ch_graines_id` int(11) NOT NULL,
`ch_graines_espece` varchar(255) COLLATE latin1_general_ci NOT NULL,
`ch_graines_sous_espece` varchar(255) COLLATE latin1_general_ci NOT NULL,
`ch_graines_description` text COLLATE latin1_general_ci NOT NULL,
`ch_graines_periode_semi` varchar(255) COLLATE latin1_general_ci NOT NULL,
`ch_graines_periode_recolte` varchar(255) COLLATE latin1_general_ci NOT NULL,
`ch_graines_taille_plant` varchar(255) COLLATE latin1_general_ci NOT NULL,
`ch_graines_photo` text COLLATE latin1_general_ci NOT NULL,
`ch_graines_nophoto` text COLLATE latin1_general_ci NOT NULL,
`ch_graines_classification` int(11) NOT NULL,
`ch_graines_disponibilite` tinyint(1) NOT NULL,
`ch_graines_espece_noaccent` varchar(255) CHARACTER SET utf8 NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci;
--
-- Déchargement des données de la table `tab_fichesgraines`
--
INSERT INTO `tab_fichesgraines`.... etc avec toutes les données à insérer.....
--
-- Index pour les tables déchargées
--
--
-- Index pour la table `tab_fichesgraines`
--
ALTER TABLE `tab_fichesgraines`
ADD PRIMARY KEY (`ch_graines_id`);
--
-- AUTO_INCREMENT pour les tables déchargées
--
--
-- AUTO_INCREMENT pour la table `tab_fichesgraines`
--
ALTER TABLE `tab_fichesgraines`
MODIFY `ch_graines_id` int(11) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=275;
COMMIT;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
"(pour ce test uniquement) tu changes (fonction rechercher/remplacer de ton éditeur) le nom de la table partout" Tu parles bien de changer le nom dans le fichier sql que je viens de coller?
"tu vérifies le jeu de caractères du fichier avec plusieurs éditeurs ou encore mieux un éditeur hexadécimal" j'ai trouvé HxD Hex Editor ça ferait l'affaire?
"si phpMyAdmin n'a pas mis de SET NAMES au début du fichier tu en rajoutes un qui correspond avec celui dans lequel est encodé le fichier de dump" Je ne vois pas de SET NAMES mais je ne sais pas vraiment quoi rajouter.
Excuse moi avec toutes ces questions, d'habitude je suis plus téméraire mais quand il s'agit de la BDD je prend plus de précaution que nécessaire ^^.
En tout cas Merci pour toute ton aide et le temps que tu prends à me lire et me répondre!
- Edité par Jagguerjack 5 décembre 2020 à 18:05:03
En général c'est via les clés étrangères que l'on joint deux tables. Surtout que MySQL met automatiquement un index dessus donc c'est censé être plus performant.
> Mais "Dumper" n'est pas juste sauvegarder?
Oui, dumper = export.
> Comme je peux le faire directement via phpmyadmin?
Oui.
> Tu parles bien de changer le nom dans le fichier sql que je viens de coller?
Oui, via ton éditeur (généralement raccourci Ctrl + F ou Ctrl +R pour la fonctionnalité rechercher/remplacer) afin de chercher tab_fichesgraines et en remplacer toutes les occurrences par tab_fichesgraines_test ou ce que tu veux.
> Et effectivement je vois du charset: latin1
On a un menteur parce que phpMyAdmin dit que le fichier est encodé en UTF-8 :
> /*!40101 SET NAMES utf8mb4 */;
Reste à savoir qui ment. Comme quoi, un éditeur hexadécimal, c'est peut être chiant à utiliser mais c'est le seul qui puisse permettre d'identifier formellement le jeu au final.
> j'ai trouvé HxD Hex Editor ça ferait l'affaire?
Je ne connais pas (et je ne travaille pas sous Windows) mais tant que tu peux lire la retranscription des caractères comme n'importe quel éditeur hexadécimal est censé le faire c'est bon.
> Je ne vois pas de SET NAMES mais je ne sais pas vraiment quoi rajouter.
Il en a mis un mais sous forme de commentaire conditionnel.
Je viens d'ouvrir le fichier avec HxD, Sur une donnée avec accent j'obtiens ceci: ici "Nielle des blés"
J'ai surligné l'accent ( je pense ) et ça donne ceci: et sur la colonne à côté, je pense pour la sélection surligné: (quand je change le curseur de place toute cette colonne change) mais pour le surlignement de l'accent ça donne ce résultat:
"Il en a mis un (SET NAMES) mais sous forme de commentaire conditionnel." Du coup je dois le mettre autre qu'en forme de commentaire?
J'espère que ça peut aider
- Edité par Jagguerjack 5 décembre 2020 à 19:17:00
Je vais changer et importer le fichier dès demain, ça sera plus calme à la maison et j'ai besoin de calme pour pas/moins faire d'erreurs Donc je change tous les: charset: latin1 en utf8 et le COLLATE latin1_general_ci en utf8_general_ci
Bonjour, je viens de faire le test avec une table que j'avais créé pour tester des requêtes. J'avais d'ailleurs essayé de changer une colonne manuellement avant hier et les caractère étaient passé de "éàçÄ" à "????" c'est pour ça qu'une colonne est en utf8.
Donc avant modification de latin à utf8.
-- phpMyAdmin SQL Dump
-- version 5.0.4
-- https://www.phpmyadmin.net/
--
-- Hôte : localhost
-- Généré le : Dim 06 déc. 2020 à 07:47
-- Version du serveur : 10.3.25-MariaDB-0+deb10u1
-- Version de PHP : 7.3.19-1~deb10u1
SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
START TRANSACTION;
SET time_zone = "+00:00";
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8mb4 */;
--
-- Base de données : `****`
--
-- --------------------------------------------------------
--
-- Structure de la table `tab_suivis_test`
--
CREATE TABLE `tab_suivis_test` (
`ch_suivi_id` int(11) NOT NULL,
`ch_suivi_membreid` int(11) NOT NULL,
`ch_suivi_ficheid` int(11) NOT NULL,
`ch_suivi_graines_espece` varchar(255) CHARACTER SET utf8 NOT NULL,
`ch_suivi_graines_sous_espece` varchar(255) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
--
-- Déchargement des données de la table `tab_suivis_test`
--
INSERT INTO `tab_suivis_test` (`ch_suivi_id`, `ch_suivi_membreid`, `ch_suivi_ficheid`, `ch_suivi_graines_espece`, `ch_suivi_graines_sous_espece`) VALUES
(694, 0, 0, 'éàçäê', ''),
(695, 88, 160, 'éàçäê', 'test');
--
-- Index pour les tables déchargées
--
--
-- Index pour la table `tab_suivis_test`
--
ALTER TABLE `tab_suivis_test`
ADD PRIMARY KEY (`ch_suivi_id`);
--
-- AUTO_INCREMENT pour les tables déchargées
--
--
-- AUTO_INCREMENT pour la table `tab_suivis_test`
--
ALTER TABLE `tab_suivis_test`
MODIFY `ch_suivi_id` int(11) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=696;
COMMIT;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
Après modification de latin à utf8.
-- phpMyAdmin SQL Dump
-- version 5.0.4
-- https://www.phpmyadmin.net/
--
-- Hôte : localhost
-- Généré le : Dim 06 déc. 2020 à 07:47
-- Version du serveur : 10.3.25-MariaDB-0+deb10u1
-- Version de PHP : 7.3.19-1~deb10u1
SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
START TRANSACTION;
SET time_zone = "+00:00";
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8mb4 */;
--
-- Base de données : `****`
--
-- --------------------------------------------------------
--
-- Structure de la table `tab_suivis_test`
--
CREATE TABLE `tab_suivis_test` (
`ch_suivi_id` int(11) NOT NULL,
`ch_suivi_membreid` int(11) NOT NULL,
`ch_suivi_ficheid` int(11) NOT NULL,
`ch_suivi_graines_espece` varchar(255) CHARACTER SET utf8 NOT NULL,
`ch_suivi_graines_sous_espece` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
--
-- Déchargement des données de la table `tab_suivis_test`
--
INSERT INTO `tab_suivis_test` (`ch_suivi_id`, `ch_suivi_membreid`, `ch_suivi_ficheid`, `ch_suivi_graines_espece`, `ch_suivi_graines_sous_espece`) VALUES
(694, 0, 0, 'éàçäê', ''),
(695, 88, 160, 'éàçäê', 'test');
--
-- Index pour les tables déchargées
--
--
-- Index pour la table `tab_suivis_test`
--
ALTER TABLE `tab_suivis_test`
ADD PRIMARY KEY (`ch_suivi_id`);
--
-- AUTO_INCREMENT pour les tables déchargées
--
--
-- AUTO_INCREMENT pour la table `tab_suivis_test`
--
ALTER TABLE `tab_suivis_test`
MODIFY `ch_suivi_id` int(11) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=696;
COMMIT;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
Et enfin après la suppression de la table et réimport de la table, j'ai refait un export pour voir comment c'était dans un éditeur:
-- phpMyAdmin SQL Dump
-- version 5.0.4
-- https://www.phpmyadmin.net/
--
-- Hôte : localhost
-- Généré le : Dim 06 déc. 2020 à 07:52
-- Version du serveur : 10.3.25-MariaDB-0+deb10u1
-- Version de PHP : 7.3.19-1~deb10u1
SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
START TRANSACTION;
SET time_zone = "+00:00";
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8mb4 */;
--
-- Base de données : `****`
--
-- --------------------------------------------------------
--
-- Structure de la table `tab_suivis_test`
--
CREATE TABLE `tab_suivis_test` (
`ch_suivi_id` int(11) NOT NULL,
`ch_suivi_membreid` int(11) NOT NULL,
`ch_suivi_ficheid` int(11) NOT NULL,
`ch_suivi_graines_espece` varchar(255) NOT NULL,
`ch_suivi_graines_sous_espece` varchar(255) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
--
-- Déchargement des données de la table `tab_suivis_test`
--
INSERT INTO `tab_suivis_test` (`ch_suivi_id`, `ch_suivi_membreid`, `ch_suivi_ficheid`, `ch_suivi_graines_espece`, `ch_suivi_graines_sous_espece`) VALUES
(694, 0, 0, 'éàçäê', ''),
(695, 88, 160, 'éàçäê', 'test');
--
-- Index pour les tables déchargées
--
--
-- Index pour la table `tab_suivis_test`
--
ALTER TABLE `tab_suivis_test`
ADD PRIMARY KEY (`ch_suivi_id`);
--
-- AUTO_INCREMENT pour les tables déchargées
--
--
-- AUTO_INCREMENT pour la table `tab_suivis_test`
--
ALTER TABLE `tab_suivis_test`
MODIFY `ch_suivi_id` int(11) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=696;
COMMIT;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
Tout à bien fonctionné. Les caractères ne sont pas convertis en "???" ils sont bien restés en tant que tels. Par contre dans le fichier réexporté après toutes les manips on voit que le changement de "COLLATE utf8_general_ci" à disparue c'est normal ?
> Par contre dans le fichier réexporté après toutes les manips on voit que le changement de "COLLATE utf8_general_ci" à disparue c'est normal ?
Je suppose que c'est parce que l'interclassement utf8_general_ci correspond à celui par défaut (via CHARSET=utf8). Si tu fais, sur le serveur en question, un SHOW CHARACTER SET LIKE 'utf8';, en colonne Default collation tu dois retrouver utf8_general_ci
A toi de me le dire de ce que tu observes via phpMyAdmin (ce que tu retrouves en structure des colonnes - jeu/interclassement - et surtout si tes données sont toujours correctement encodées)
> je peux faire la pareil dans les tables en ont besoin?
Tu le fais table par table ? Pas toute la base d'un coup ? Enfin, pourquoi pas, au moins ça permet d'y aller étape par étape et de contrôler chacune d'entre elles au fur et à mesure.
Sur phpmyadmin dans interclassement de la table que où j'ai fait la manip il apparait bien "utf8_general_ci"maintenant, et mes données sont bien encodées. Je vois bien les caractères corrects avec accents.
Oui je pense le faire table par table
Une petite question pour la table Membres. Je ne sais pas si ça vaut le coup de la changer en utf8 pour une raison. Lorsque les membres s'inscrivent leur MDP est crypté avec "password_hash". (du coup avec les caractères en latin1) Ça ne risque pas de mal fonctionner si je passe en utf8? je veux dire lorsqu'ils voudront se reconnecter il y arriveront toujours? ou bien le cryptage va mal supporter le passage en utf8?
MySQL ne fait que stocker le hash, il ne connaît pas la chaîne d'origine (le mot de passe quoi) et encore moins son jeu de caractères.
Le stockage d'un hash devrait employer une colonne de type VARBINARY ou (TINY)BLOB et non VARCHAR ou (TINY)TEXT. La différence étant que ce qui est binaire (*BINARY et *BLOB) reste toujours tel quel, ça n'est jamais converti dans un autre jeu de caractères à aucun moment par MySQL contrairement aux types *CHAR et *TEXT.
Mais les hashs produits par password_hash sont encodés sous forme hexadécimale donc théoriquement de l'ASCII suffirait à les coder et latin1 comme UTF-8 étant des surensembles à l'ASCII, ça n'aurait aucune influence. Ils ne sont pas sous forme "raw", binaire, où une conversion (quand il n'en faut pas) serait susceptible de toute faire foirer. Exemple :
Réponse courte : non. Il n'y a que si ton site passait de latin1 à utf8 que ça aurait pu arriver (encore qu'avec bcrypt on est censé encodé en UTF-8 la chaîne d'entrée).
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
julp.fr ~ PHP < 8.0.0 : activer les erreurs PDO/SQL ~ PHP < 8.1.0 : activer les erreurs mysqli
Activer les erreurs PDO / (julp) htmlspecialchars / FAQ PHP / Pas d'aide par MP
julp.fr ~ PHP < 8.0.0 : activer les erreurs PDO/SQL ~ PHP < 8.1.0 : activer les erreurs mysqli
julp.fr ~ PHP < 8.0.0 : activer les erreurs PDO/SQL ~ PHP < 8.1.0 : activer les erreurs mysqli
julp.fr ~ PHP < 8.0.0 : activer les erreurs PDO/SQL ~ PHP < 8.1.0 : activer les erreurs mysqli
julp.fr ~ PHP < 8.0.0 : activer les erreurs PDO/SQL ~ PHP < 8.1.0 : activer les erreurs mysqli
julp.fr ~ PHP < 8.0.0 : activer les erreurs PDO/SQL ~ PHP < 8.1.0 : activer les erreurs mysqli
julp.fr ~ PHP < 8.0.0 : activer les erreurs PDO/SQL ~ PHP < 8.1.0 : activer les erreurs mysqli
julp.fr ~ PHP < 8.0.0 : activer les erreurs PDO/SQL ~ PHP < 8.1.0 : activer les erreurs mysqli
julp.fr ~ PHP < 8.0.0 : activer les erreurs PDO/SQL ~ PHP < 8.1.0 : activer les erreurs mysqli
julp.fr ~ PHP < 8.0.0 : activer les erreurs PDO/SQL ~ PHP < 8.1.0 : activer les erreurs mysqli
julp.fr ~ PHP < 8.0.0 : activer les erreurs PDO/SQL ~ PHP < 8.1.0 : activer les erreurs mysqli
julp.fr ~ PHP < 8.0.0 : activer les erreurs PDO/SQL ~ PHP < 8.1.0 : activer les erreurs mysqli
julp.fr ~ PHP < 8.0.0 : activer les erreurs PDO/SQL ~ PHP < 8.1.0 : activer les erreurs mysqli
julp.fr ~ PHP < 8.0.0 : activer les erreurs PDO/SQL ~ PHP < 8.1.0 : activer les erreurs mysqli