Je l’ai fait @ChristianPitet 
Merci !
···
Bien cordialement,
Christian Pitet
Bonjour,
Webmaster du site https://cyclobelfort.fr, j’ai exactement le même problème. Les caractères accentués qui se sont transformés, y compris en base et plugins inactifs, donc après avoir vidé le cache, plus de brèves par exemple et des erreurs de table inexistantes
Je suis chez OVH. SPIP 4.1.10.
PHP 7.4, MYSQL v.8.0.
Je n’avais pas le dernier paramètre à utf8 dans le fichier connect.php (en tout cas sur le site de prod chez ovh) j’ai essayé, ça ne change rien.
J’ai joué avec PHP My Admin pour changer l’interclassement qui était (est finalement toujours) en latin1_swedish_ci pour passer en utf8mb3_general_ci, ça marchait très bien pour certains champs/certaines tables, mais pas pour d’autres (exemple les descriptions sur la table spip_jobs). Et il faut modifier tous les champs, un changement global de l’interclassement ne semblait avoir aucun effet ou alors je m’y suis mal pris le 1er coup.
J’ai restauré la base finalement à samedi (la dernière fois que j’ai été dans l’espace privé c’était samedi matin, donc j’ai pris la sauvegarde de samedi après-midi) et j’en suis revenu au point initial, comme après avoir vider le cache en début de soirée.
Sur un hébergement mutualisé, je ne sais pas comment passer spip-cli. J’ai éventuellement un serveur de développement (avec Maria DB 10 mais sur lequel j’ai déjà un interclassement à utf8mb3_general_ci mais toutefois les problèmes de caractères dans les champs après avoir restaurée la sauvegarde SPIP de PROD) sur lequel je pourrais réparer la base, pouvez-vous svp me donner de plus amples informations sur la marche à suivre pour remettre en ordre ma base de données et mon site ? Ou puisque j’ai des sauvegardes, est-ce qu’il y a une manipulation que vous pouvez me décrire que je pourrais passer sur la base de prod ?
Merci,
J’ai réactivé manuellement mes 3 plugins dont j’avais besoin.
Me reste plus que le problème de conversion de caractères, j’ai certainement pas le choix que d’utiliser spip-cli sur une copie de ma DB sur mon serveur de dev car je ne vois pas de moyen de l’installer sur mon hébergement mutualisé. Infos supplémentaires, c’est une base qui est existe depuis SPIP 1.9 (puis migrée sur du 2.1.27, du 3.2.7, 4.1.5 et 4.1.10)
Bonsoir Sylvain,
SPIP 4.1.10, c’est en soi problématique au moins en termes de sécurité : Mise à jour critique de sécurité : sortie de SPIP 4.3.2, SPIP 4.2.16, SPIP (…) - SPIP Blog
Pour ce qui est de spip-cli, tu peux faire un dump MySQL que tu traites avec spip-cli sur ton serveur de dev, et restauration en prod.
Merci. Je vais regarder tout cela. Et en effet, mauvais point pour la sécurité, j’ai retrouvé 2 ou 3 fichiers suspects datant de ce WE et un fichier modifié dans le répertoire ecrire. Je m’occupe de mettre à jour et réparer tout cela.
1 « J'aime »
Bonjour , merci à Touti pour « venir en aide à mon désespoir ». Tout est rentré dans l’ordre après son intervention . Une fois le travail sur la Bases de données nous avons mis à jour spip avec spip-loader sur 4.3. en mettant à jour les plugins. Cette mise à jour était nécessaire et merci à SPIP pour tout ce travail d’amélioration.
A tout hasard, et je pense que Touti n’y verra pas d’incinvénient voilà la démarche qu’il a entreprise
Je ne me suis occupée que de la base de données, donc je ne sais pas si vous avez été ou non hacké à priori je ne pense pas.
OVH se moque de ses hébergés et a fait les mises à jour SQL en force.
Vous êtes ainsi passé de latin à utf8 sans avoir été prévenu.
A faire :
Récupération de la BDD
Import en local de la BDD
On remet tout en latin1_swedish_ci
puis on réimporte
On passe spip convert
puis on exporte la bonne base et on met à jour
J’espère cette fois-ci que je ne me suis pas trompé d’endroit pour répondre.
Bonne journée à tous et toutes
Bonjour Alcide,
tant mieux si cela à résolu ton souci et oui c’est le bon endroit pour répondre.
Merci d’utiliser le féminin quand tu parles de touti ! ce n’est pas la première fois que cela m’arrive mais mon vrai nom ne veut pas dire que je suis la secrétaire de touti 
Du fait des mélanges manuels que tu avais tenté entre latin et urf-8 mb3 mb4 etc directement dans la base, l’intervention spécifique a été de remettre d’aplomb le fichier sql. Je déconseille vraiment fortement cette pratique aléatoire qui consiste à modifier l’encodage depuis l’interface SQL comme PhpMyadmin. Il m’a fallut aussi comprendre pourquoi les tables __mpa étaient dans la base SPIP alors qu’elles appartiennent normalement à mysql et me foutaient le bazar en local.
Tout remettre en latin1_swedish_ci était donc un prérequis avant de passer en utf-8 avec spip-cli sur le SPIP local avec la base encodée en latin nettoyée
sql:convert:toutf8
Une petite visio pour remettre d’équerre depuis OVh a été nécessaire. Franchement, fuyez OVH c’est de 
merci pour les infos supplémentaires.
J’ai importé ma base sur mon serveur Maria DB (pour l’import j’ai du changer l’option COLLATE utf8mb4_0900_ai_ci en COLLATE utf8mb4_unicode_ci sur la commande create database - je n’ai pas utilisé ma db de dev initiale car pas dans les conditons correctes je pense). Sur chaque table dans la base importée, je vois Interclassement = latin1_swedish_ci
J’ai installé spip-cli (à part les liens d’autocompletion car je n’ai pas de répertoires bash_completion.d. La commande spip fonctionne, j’ai l’aide.
Ensuite, je suis allé dans le répertoire où se trouve mon site spip (que j’avais installé par spip_loader.php initialement, que je viens d’ailleurs de réutiliser pour mettre la 4.1.18). Et avant de lancer des commandes de mises à jour, j’ai essayé d’utiliser une commande en théorie sans mises à jour:
spip server:locate
[ERROR] Pas de site SPIP détecté.
Avant de lancer les opérations de conversion, j’ai quelque chose à faire qui indique quelle base/site il faut modifier je pense, comment dois-je procéder ?
Alors j’ai essayé quand même la commande en me disant que des questions seraient éventuellement posées (vu que pas d’arguments/options pour le demander), mais :
spip sql:convert:toutf8
Convertir en UTF8
=================
<!DOCTYPE html>
<html class='ltr fr no-js' xmlns='http://www.w3.org/1999/xhtml' lang='fr' dir='ltr'>
<head>
<title>Site en travaux</title>
<meta name='viewport' content='width=device-width' />
<link rel='stylesheet' href='prive/themes/spip/reset.css' type='text/css' />
<link rel='stylesheet' href='prive/themes/spip/clear.css' type='text/css' />
<link rel='stylesheet' href='prive/themes/spip/minipres.css' type='text/css' />
</head>
<body class='minipres'>
<div id='minipres'>
<h1>Site en travaux</h1>
<div>
Attention : un problème technique (serveur SQL) empêche l’accès à cette partie du site. Merci de votre compréhension.
</div>
</div>
</body>
</html>
Merci
Bonjour,
Il suffit d’effacer config/connect.php
Et d’aller avec le navigateur sur URLsitelocal/ecrire/ et la procédure de création du config/connect.php se fait.
Remarque : au moment de créer l’admin du site, si tu as déjà un compte dans la base, tu peux faire [Suivant] sans renseigner de compte.
Je viens de procéder à la manip pour recréer le connect.php, il a bien vu ma base, je l’ai choisi je suis allé au bout. J’arrive à me connecter avec mon compte admin, donc je me suis dit, c’est ok.
Je reviens sur le serveur et essaie de lancer les commandes, mais même résultats.
Yes Touti est merveilleusE !
OVH se moque de ses hébergés et a fait les mises à jour SQL en force.
Ces messages ayant attiré mon attention, j’ai vérifié mes vieux sites peu fréquentés sur OVH… et constaté que ça leur est également arrivé 
Du coup la réparation m’intéresse, mais il y a un peu des flous dans la description que tu en donnes.
« Vous êtes ainsi passé de latin à utf8 sans avoir été prévenu. » :
Je me demande : quelle mise à jour OVH a t il fait au juste : les déclarations des tables et des interclassements ou les contenus eux mêmes ?
Avec phpmyadmin je regarde ce que je peux voir :
- l’interclassement déclaré pour toutes les tables est resté
latin1_swedish_ci. - idem l’interclassement de tous les champs texte
- par contre, l’interclassement de la connexion au serveur est (passé) en
utf8mb4_unicode_cicf la page phpMyAdmin (adaptez l’url)
Si je remet la déclaration latin1_swedish_ci au paramatrage de la connexion au serveur je ne vois aucun changement et toujours les hiéroglyphes.
Ce serait donc le contenu des champs qui a été changé alors ?
Dans le paramétrage SPIP du charset (page /ecrire/?exec=configurer_langue) il y a iso-8859-15
Je met utf-8 comme il y est conseillé sur cette page.
Et hop ça marche ! C’est donc le contenu des champs lui même qui a été modifié par OVH.
Par précaution je remet l’encodage général de la connexion au serveur à utf8mb4_unicode_ci.
Je laisse les champs et les tables déclarées en latin1… :-/
Et donc il m’a suffit de changer la déclaration à SPIP de l’interclassement de la BDD, dans la page
/ecrire/?exec=configurer_langue du site spip, ce qui est nettement plus simple que l’import-convert-export assez technicoïde, pour résoudre a priori le même problème.
J’ai déjà utf-8 sur cette page :
Votre site est actuellement installé dans le jeu de caractères :
utf-8
? hein ? tu as lu [Résolu] Caractères accentués subitement non rendus correctement et plus aucun plugin actif - #28 par touti ?
où j’explique que la base a eu des encodages mélangés manuellement et qu’il a fallut la remettre à plat ?
Si j’ai bien compris, j’ai posté ici qu’OVh à fait la mise à jour MYSQL8 qui bascule par defaut en utf-8 sans se préoccuper des tables existantes on dirait …
Tout le monde ne s’assure pas des rétrocompatibilités comme SPIP le fait
Hello @touti, là je commentais le message de @Alcide que tu as dépanné. Je n’ai pas examiné tous les détails de ce fil touffu car je trouve les contributions souvent peu claires ou ambigües. Par exemple quand tu écris « la table majeure semblait avoir été passée en utf-8 par OVH », je ne sais pas ce précisément qui a été « passé en utf-8 » : la déclaration de la table ? la déclaration des différents champs de la table ? ou le codage lui-même du contenu des différents champs textes ? ou peut être l’ensemble ? Sans parler de la déclaration de la connexion au serveur qu’il y a aussi… : autant de points de réglages concernés par les charset et des encodages.
Sur mon site problématique, les déclarations des tables n’ont pas été changées (restent latin) et c’est le contenu qui a été transcodé et je comprend que c’est ça que tu voulais exprimer.
Et d’ailleurs, les déclarations des tables ne concernent elles pas uniquement le « classement » (en cas de tri) et non l’encodage ? Peut être bien, et dans ce cas mes questionnements sont hors sujet…
Mais en tout cas j’ai l’impression que les solutions diffèrent selon les sites, puisqu’il m’a suffit de changer la configuration SPIP du charset pour tout résoudre…
faux
Et les problèmes diffèrent aussi puisque mes autres sites sur le même serveur OVH n’ont pas été impactés ! [EDIT : MAIS ILS SONT DÉCLARÉS DANS SPIP EN UTF-8]
@JLuc le message de Alcide reprenait des extraits de mon mail que j’explicite sous son post parce que l’encodage de sa base et des tables était sens dessus dessous !
Tu participes à un forum où tu annonces que tu n’as pas pris le temps de lire les posts, c’est assez discourtois quand même.
dsl mais quand je comprend pas ce qui est écrit, quelle qu’en soit la raison, ça ne me sert à rien de lire en détail et mon incompréhension n’a rien de discourtois vraiment
Je vous tiens informé de comment j’ai procédé pour corriger mon site. Comme je n’arrivais pas à utiliser spip-cli, ce n’est pas évident, il y a une partie manquante dans la doc de comment on le connecte à un site existant. J’ai donc décidé d’y aller directement dans la base en suivant ceci : How to Find and Convert Latin1 encoded rows to UTF8 - MySQL
Je vérifie ma base:
SELECT SCHEMA_NAME 'database', default_character_set_name 'charset', DEFAULT_COLLATION_NAME 'collation' FROM information_schema.SCHEMATA where SCHEMA_NAME='madb';
database charset collation
madbdev utf8mb4 utf8mb4_unicode_ci
database charset collation
madbprod utf8mb4 utf8mb4_0900_ai_ci
utf8mb4_0900_ai_ci est celui par défaut en MySQL 8.0 Sur le Maria DB, je n’avais pas ce jeu de caractères. J’ai utf8mb4_unicode_ci disponible sur la base de prod, mais est-ce qu’OVH va me la rechanger, donc j’ai envie de laisser ce qui existe, surtout que c’est la valeur par défaut.
Liste de l’état actuel des tables:
SELECT CCSA.character_set_name, CCSA.collation_name, T.table_schema, T.table_name FROM information_schema.`TABLES` T,
information_schema.`COLLATION_CHARACTER_SET_APPLICABILITY` CCSA
WHERE CCSA.collation_name = T.table_collation
and T.table_schema='madb'
mes tables sont bien en latin1 pour le moment
Je dois passer l’alter mais ça ne modifiera pas les données existantes. J’exporte et je vais me générer les requêtes sql de modifications alter.
ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ou
ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;
suivant mon environnement
Pour passer toutes les tables j’ai du changer le stockage de certaines à InnoDB au lieu de MyISAM. Il s’agit des tables spip_meta, spip_ortho_cache, spip_ortho_dico, spip_urls. Je suis passé par l’interface graphique de PHPMyAdmin dans Operations, Options pour cette table après avoir vérifié que je pourrais le faire sur ma prod.
A ce moment là je vérifie que j’ai bien toutes les tables comme je le souhaite, donc je repasse la requête ci-dessus.
Toutes les tables semblent avoir maintenant le bon charset et collation
Vérification des colonnes:
SELECT TABLE_SCHEMA, TABLE_NAME,COLUMN_NAME,DATA_TYPE,COLUMN_TYPE,CHARACTER_SET_NAME,COLLATION_NAME FROM information_schema.COLUMNS WHERE TABLE_SCHEMA='madb' and CHARACTER_SET_NAME is not null ORDER BY `TABLE_SCHEMA` ASC;
J’ai 210 colonnes concernées. Toutes avec le character_set_name = latin1 mais pour collation_name j’ai soit latin1_swedish_ci, soit latin1_bin (sauf pour les tables dont j’ai modifié le stockage, j’ai modifié aussi l’interclassement. Mais j’ai repassé l’alter ci-dessus pour être sûr).
L’alter table du dessus à modifier les colonnes, reste à migrer les données existantes.
J’exporte et je vais me générer les requêtes sql d’update:
update table_name set column_name = convert(cast(convert(username USING latin1) AS BINARY) USING utf8mb4) where convert(cast(convert(username USING latin1) AS BINARY) USING utf8mb4) IS NOT NULL AND convert(cast(convert(username USING latin1) AS BINARY) USING utf8mb4) NOT LIKE '%?%' AND length(convert(cast(convert(username USING latin1) AS BINARY) USING utf8mb4)) > 3;
J’ai passé sur les 210 colonnes sur mon env de devs, en prod j’exécute que sur les colonnes qui avaient des modifs ou des erreurs d’update en dev, soit environ une 20aine de colonnes. Ca se passe mieux en prod, je trouve sur internet que utf8mb4_0900_ai_ci est mieux, ça se vérifie.
Je n’ai pas pu corriger tous les articles ou les brèves par les requêtes puisque dans les textes les liens contiennent potentiellement des ? mais je ne pouvais pas enlever ce critère sinon j’avais une erreur, certains caractères ne voulant tout simplement pas se convertir. J’ai l’impression que tous les articles dont le contenu venait de logiciels de traitement de texte que je ne citerai pas et qui changent certains caractères par des caractères insécables ont fait que certaines lignes n’ont tout simplement pas voulu être modifiées. Ensuite, j’ai fait 3h de vérifications et modifications manuelles, mais les requêtes m’ont résolu 75/80% du contenu du site.
Merci
3 « J'aime »
Bonjour, perso j’ai fait la boulette de vider le cache et le site a pris une claque visuellement tout en conservant les caractères accentués en affichage bizarre !!! Quelqu’un pourrait-il m’aider svp ? Merci d’avance à vous et pas à OVH en tout cas …
Salut, du coup je dois contacter OVH ou il faut se débrouiller sans eux ? Merci