[Résolu] Encodage UTF8mb3 et UTF8mb4 indisponibles sous SPIP (version 4.2.14)

Général
#1

Bonjour,
J’ai installé SPIP version 4.2.14 chez Switch et le serveur ne reconnait pas l’encodage UTF-8 brut. Il ne dispose que des versions, plus récentes, UTF8mb3 (encodage sur 3 bits) ou UTF8mb4 (encodage sur 4 bits) qui ne sont pas reconnus par SPIP.
Cela génère deux problèmes :

  • SI j’importe dans ma base SQL des données propres (dans mon cas, des listes géographiques), les caractères avec un diacritique (é,è,Î…) ou avec des caractères non latins ne sont pas reconnus par SPIP. Ce qui provoque un plantage avec GIS qui n’affiche plus les markers. Je suis obligé de corriger les fiches une à une dans l’espace privé pour que ça marche. C’est long et fastidieux.
  • Dans la base SQL, les données saisies dans l’espace privé sont codées bizarrement (è pour è, Ã@ pour î…), ce qui les rend inexploitables si je souhaite les extraire de la base pour les utiliser ailleurs.

Il semble que les codages UTF8mb3 et UTF8mb4 soient d’apparition récente. UTF8mb4 permet notamment d’utiliser des smileys jusqu’à lors indisponibles et permettrait un fonctionnement plus rapide sur le serveur…

Qu’en pensez-vous ? Il serait sans doute utile que SPIP permette de les utiliser.

Amicalement.

#2

Bonjour,

C’est surprenant ce que tu décris.
Parce que SPIP fonctionne très bien en utf8mb3 ou mb4 (à condition d’être en innoDB pour le format de stockage).

Pour être précis : utf8mb3 ou mb4, c’est le nombre d’octects maximum d’encodage d’un caractère utf8 dans la base de données.

Et SPIP laisse faire la base de données et se contente d’indiquer utf8.

#3

Pas de problème chez switch, où je suis en UTF8mb3.
ça sent la vieille base en latin1 ou autre, avec un export du même type de codage, importée dans de l’utf8 sans préciser ce codage…
Je n’ai pas les capacités à t’aider mais des posts comme celui ci

sont sur le forum,et peuvent peut être t’aider :wink:

Au moins une dizaine d’années, j’ai pas trouvé la date exacte, mais les forums ont des commentaires datant de 2015…
Des problèmes particuliers ont été relevés dans des cas précis avec UTF8mb4.
Clt

#4

Je suis aussi étonné que vous. Le site en cause est tout neuf, installé cette semaine, avec un choix d’encodage en utf8. Et le bug est assez fin, invisible sous SPIP si on se contente de saisir dans l’espace privé. Par contre, si on fait des modifications dans la base SQL (ou si importe une liste pourtant bien enocdée en utf8, ça se gâte.

Par exemple, je crée un article test dans l’espace privé avec cette chaîne de caractères :
(1) « àâäÀÂÄéèêÉÈÊËîïìÌÎÏòôöÒÔÖùûüÙÛÜ »
Tout semble OK à l’enregistrement et apparait correctement sur mes pages.

Mais dans la base sql, j’ai ça en enregistrement :
(2) « Ã âäÀÂÄéèêÉÈÊËîïìÌÎÏòôöÒÔÖùûüÙÛÜ »

Si, maintenant, je tape la même chaîne (1) dans la base sql via php, elle est bien enregistrée correctement dans la base. Mais dans les pages SPIP (espace privé et public), elle apparaît ainsi :

(3) « ������������������������������� »

Et là, c’est la cata avec GIS qui n’affiche plus les marqueurs

J’ai bien vérifié ma base. Toutes les tables et tous les champs sont bien encodés en UTF8mb3.

Donc, je ne comprends pas. Si quelqu’un a une idée ?

Amicalement.

#5

Une piste, peut-être… En continuant de fouiller, je vois que l’encodage du jeu de caractères du serveur est « cp1252 West European (latin1) ». Ce qui ne me semble pas normal.

Je n’ai pas la main là-dessus puisque c’est une serveur mutualisé. Je questionne Switch.

Amicalement.

#6

Aucun rapport, c’est l’encodage du serveur, pas celui de la base,

Capture d’écran 2024-06-30 à 12.57.26
Capture d’écran 2024-06-30 à 12.57.26983×275 16.6 KB

comme je l’ai dit, je n’ai aucun problème avec o2switchOn en revient toujours à un problème d’encodage du contenu
Note que mon logiciel d’export envoi systématiquement les commande de suppression des tables et de recréation en spécifiant le jeu et le moteur voulu à la création (UTF8mb3 chez moi)
exemple

ENGINE=MyISAM DEFAULT CHARSET=utf8mb3 COLLATE=utf8mb3_general_ci;

ou

ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 COLLATE=utf8mb3_general_ci;

selon les tables

Ne pas confondre le contenant et le contenu, je t’ai donné un lien qui l’explique
Par ailleurs, tes squelettes n’indiquent peut être pas le bon encodage à ton navigateur
J’arrête là car j’atteins mes limites, bonne continuation
Clt

#8

Merci pour vos réponses et votre intérêt pour mon souci.
De mon côté, j’ai continué de fouiller… et j’ai trouvé cela :
Ma base sql tourne sous Maria DB, version 10.6.18 (release date 17/5/24) : MariaDB Server - All releases - MariaDB.org
Je n’ai pas trouvé son descriptif d’encodage mais en consultant la page citée, je vois qu’il y a eu des modifications récentes dans les préférences d’encodage par defaut.
Je viens également de comparer les valeurs données par le serveur de Switch et les valeurs par defaut de Maria DB.
https://mariadb.com/kb/en/server-system-variables/#character_set_client
Il y a des différences et un certain nombre de réglages qui sont en latin 1 (voir image jointe). Puis-je les modifier ? Savez-vous lesquels ? Ces modifications seront-elles permanentes ou seulement attachées à la connexion en cours ?
Je verrai demain avec mon hébergeur comment rêgler définitivement la chose… Reste enfin la question de comprendre pourquoi j’ai ce phénomène avec un SPIP tout neuf sur une base toute neuve ?

Amicalement.

Capture d’écran 2024-06-30 à 15.59.10
Capture d’écran 2024-06-30 à 15.59.101158×413 84 KB

#10

Bonjour,

J’avais écrit un message ce matin pour clore ce fil car je pensais que tout était résolu en réinstallant ma base… Il n’en est rien et je tourne en rond.

J’ai réinstallé un site propre, tout neuf sur une base toute neuve configurée en UTF8mb4_general ci. J’ai configuré mon site, ajouté nom et slogan. Côté spip (espace public comme espace privé), tout va bien. Sauf que…

Quand je consulte la base via phpMyadmin, je vois dans la table des metas que le descriptif_site est enregistré « Belle-ÃŽle-en-mer » pour « Belle-Île-en-mer »… Et c’est comme ça dans toutes les tables. Tout ce que je saisis sous SPIP est mal encodé dans la base sql. Dans l’interface de SPIP, tout est nickel, mais côté base sql, les données sont enregistrées avec des codes fantaisistes.

Ca ne vient pas du serveur car j’ai sur ce même serveur un autre site propulsé par Wordpress. et dont la base est également configurée en utf8mb4. Et sur ce site, pas de souci. Les enregistrements dans la base sont conformes.

Spip fait donc quelque chose de travers. Le bug peut sembler invisible quand on ne va pas consulter directement sa base sql. Mais il est là…

#11

Bonjour
et dans connect.php : spip_connect_db vous avez bien utf8 en dernier ?

#12

Bonjour Natacha,

Merci de vous intéresser à mon problème.
Je suppose que vous parlez du fichier connect.php dans config à la racine du site. Je n’ai pas trouvé la doc qui le concerne. Le mien ne dit rien sur l’encodage… et se présente ainsi :

<?php
if (!defined("_ECRIRE_INC_VERSION")) return;
defined('_MYSQL_SET_SQL_MODE') || define('_MYSQL_SET_SQL_MODE',true);
$GLOBALS['spip_connect_version'] = 0.8;
spip_connect_db('localhost','','IDENTIFIANT','MOT_DE_PASSE','BASE','mysql', 'spip','','');

J'ajoute "UTF8" après la dernière virgule ?
#13

Bonjour
en dernier

#14

De nouveau bonjour, Natacha,

Et merci pour votre aide efficace.

J’ai testé votre proposition en modifiant cette ligne du fichier connect.php dans config à la racine (en ajoutant ‹ utf8 › à la fin).

spip_connect_db('localhost','','IDENTIFIANT','MOT_DE_PASSE','BASE','mysql', 'spip','','utf8');

et tout fonctionne normalement maintenant.

C’est donc bien un bug d’installation, assez insidieux. Mon installation s’était faite avec la dernière version de « spip-loader » qui n’écrit donc pas « utf8 » sur cette ligne. Le bug ne se voit que si on regarde dans la base comment les données sont encodées lors de l’enregistrement… Mais il est bien là. 4 petites lettres qui changent tout.

Ce serait bien de le signaler à l’équipe de développement.

Merci, merci de m’avoir apporté la solution.

Et bonne journée.

#15

je pense que lors de l’installation initiale votre base de données n’était pas en utf8 du coup ça a laissé vide le champ

#16

Merci encore, Natacha ! Vous m’avez soulagé d’un gros souci. Et je viens de faire deux tests qui confirment ce que vous dites…

Test 1. J’ai réinstallé une base vide avec spip loader en suivant la procédure. Tout s’est bien passé. La base est créée et le fichier de config indique bien utf8 en dernier argument.

Test 2. J’ai créé préalablement une base moi-même sous php (ce que je fais toujours depuis que j’utilise SPIP). Je l’ai configuré en utf8mb4. Tout se passe apparemment bien mais le fichier de config n’indique pas utf8 en dernier argument. En saisie dans l’interface privée, tout semble OK, mais les enregistrements déconnent pour les diacritiques dans la base sql.

Le bug est insidieux. Je ne m’en serai pas rendu compte si je n’avais pas importé directement des éléments (bien codés en UTF8) dans les tables… mais qui, du coup, dans l’interface de spip, n’étaient pas reconnus et produisaient des � pour les diacritiques.

Grâce à vous, tout est résolu. Je viens de passer deux petites heures à vérifier et corriger mes tables… Ce qui n’est rien au regard de tous les avantages et toutes les facilités qu’apporte SPIP en développement de projet quand c’est assez complexe. Merci une nouvelle fois à tous les développeurs et mainteneurs.

Bien amicalement.

ps. Je ne sais pas comment faire pour marquer cette discussion comme résolue.

1 « J'aime »
#17

heureuse d’avoir pu vous aider
modifiez le titre pour ajouter Résolu

#18

C’est fait :slight_smile: