Encodage UTF8mb3 et UTF8mb4 indisponibles sous SPIP (version 4.2.14)

[Perig]

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.

[RealET]

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.

[choucas]

@Perig

(encodage sur 3 bits) ou UTF8mb4 (encodage sur 4 bits) qui ne sont pas reconnus par SPIP.

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

erreur suite migration site sur jeux de caractères

Après une migration et changement de squelette, je n’ai pas vu tout de suite qu’il y avait eu un problème de jeux de caractères… Tout est bien configuré en utf8, et j’ai pu corriger en exportant/important dans la base pour les caractères spéciaux, guillemets, ç… Mais il reste des bouts de textes en arabe ou cyrillique… et je me retrouve avec des trucs du genre cette affiche due au graphiste Emile Muneim (أميل منعم) et un nouveau slogan : "Change avec le rouge !" (غيّر بالأحم؅

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

@Perig

Il semble que les codages UTF8mb3 et UTF8mb4 soient d’apparition récente.

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

[Perig]

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.

[Perig]

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.

[choucas]

@Perig

ne piste, peut-être… En continuant de fouiller, je vois que l’encodage du jeu de caractères du serveur est «

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

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

@Perig

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

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

[Perig]

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.