Je doute que ce soit tout passé par les bons niveaux d’utf8.
En effet il y a une grande différence au niveau de mysql entre utf8_general_ci, utf8mb3_general_ci et utf8_general_ci (sans parler des versions en _unicode_ci)
(et l’utilisation de caractères arabes entre peut-être encore dans une autre catégorie)
cf. MySQL :: MySQL 8.0 Reference Manual :: 10.10.1 Unicode Character Sets
Peut-être que mon petit retour d’expérience peut t’aider :
j’avais une base d’origine mal encodée : c’était du latin1 encapsulée dans le l’utf8_general_ci (résultat d’une vieille installation spip2 mal migrée en spip3).
Du coup la migration vers une installation propre cassait tous les accents.
J’ai recréé la base pour que toutes les tables soient en utf8mb4_general_ci.
Pour cela j’ai exporté la structure des tables de la base d’origine et modifié la requête SQL pour que tous le encodages soient bons.
Puis j’ai exécuté la requête corrigée sur une nouvelle base de données.
J’ai vérifié que l’encodage par défaut dans my.cnf est bon dans /etc/mysql/mariadb.conf.d/50-server.cnf:
character-set-server = utf8mb4
collation-server = utf8mb4_general_ci
(je suis en mariadb 10.6.7)
Ensuite j’ai exporté les données initiales avec la commande
mysqldump -p mabase --set-charset --default-character-set=latin1 --no-create-db --no-create-info > donnees.sql
Un export sans préciser de charset cassait tous les accents car le contenu était mal interprété.
J’ai vérifié dans le fichier sql que les accents étaient bons et j’ai modifié début du fichier pour qu’il contienne
SET NAMES utf8mb4
L’import s’est fait classiquement avec
mysql -p nouvellebase < donnees.sql
Ensuite j’ai fais la mise à jour vers SPIP4.0 sans problème.
Conclusion : il faut à tout moment vérifier les données et se préparer à les héberger proprement. Si l’une des étapes ne fonctionne pas, c’est qu’à ce moment l’encodage ou l’interprétation n’était pas bon.
