[Astuce] emojis : erreur lors de la sauvegarde et problème d'affichage pour les existants

[woluweb]

Petit retour d'expérience qui pourra vous servir si vous rencontrez aussi des problèmes avec les emojis : j'ai un site web qui utilise des emojis qui fonctionnaient très bien (à la fois dans l'éditeur et dans le front-end).
Mais à un moment donné (fin mai) ils ont cessé de fonctionner :

• dans le front-end, tous les emojis sont remplacés par ?
• dans l'éditeur, si je modifie un article existant contenant des emojis, ils sont remplacés par ?
• dans l'éditeur, si je sauvegarde un nouvel article avec des emojis, j'obtiens l'erreur suivante

  Incorrect string value: '\xF0\x9F\x98\x83

  (même erreur si je restaure une version précédente de l'article)
• Pourtant, si je regarde dans la base de données, je vois les emojis correctement (et la table __content est utf8mb4_unicode_ci, ce qui me semble correct).

Presque par hasard, j'ai découvert que la seule différence avec tous mes autres sites (où je n'ai jamais rencontré le problème) était que "Database Connection Collation" était sur "utf8_general_ci" et pas "utf8mb4_general_ci" (on le voit dans System > System Information).
Et précisément c'est juste après être passé sur MariaDB 10.5 que le problème est apparu.

Je vous épargne la longue partie de ping-pong avec PlanetHoster pour essayer de comprendre et résoudre le problème, mais finalement Anthony a mis le doigt sur la solution : dans les Options PHP du serveur N0C, si on coche "nd_mysqli" au lieu de "mysqli" le problème est résolu !

Encore merci à PH-Mina-S et à ses équipes pour la résolution du problème !

[PH-Mina-S]

Toujours un plaisir woluweb ! Merci pour votre confiance !

[herve]

Bonjour
Content que tu es pu résoudre cela.

J'ai bien compris qu'il est préférable maintenant de passer en utf8mb4_general_ci à la fois sur l'interclassement et la collation.
Hors par hasard, j'ai regardé sur plusieurs sites hébergés chez PH et j'ai
Version de la base de données 10.2.44-MariaDB
Interclassement latin1_swedish_ci !
Collation de la base de données utf8mb4_general_ci

Avec le support PH, j'ai pu basculer l'interclassement en utf8mb4_general_ci mais la 1ère fois cela a planté le site
ASTUCE: Il a fallut que je réinstall la sauvegarde jpa . Les param de la bdd avec l'interclassement ET la collation de la base de données => utf8mb4_general_ci

Par contre je n'ai pas compris pourquoi j'avai ce paramètre Interclassement latin1_swedish_ci !??
Est-ce votre cas aussi sur d'ancien site ou nouveau site crée récemment?
Je n'ai pas eu de réponse pour cela du support mais je trouve cela étrange d'avoir cette langue (>

[woluweb]

Bonjour
Par contre je n'ai pas compris pourquoi j'avai ce paramètre Interclassement latin1_swedish_ci !??

La plupart de mes sites (même créés from scratch) ont aussi l'interclassement latin1_swedish_ci et ça n'empêche pas que tout fonctionne normalement.
Le problème n'est donc pas l'interclassement (aussi appelée Collation en anglais)

Ici le problème était vraiment au niveau de la "Database Connection Collation", qui ne se règle ni au niveau de Joomla ni au niveau de la configuration générale d'un serveur mutu... mais en choisissant dans les paramètres PHP "nd_mysqli" vs "mysqli".

[herve]

Bonjour
Dans ton cas,cela a résolu ton problème, moi en soulevant cela sur le forum international, un dev d'une extension mentionnait qu'il trouvait anormal d'être en latin1_swedish_ci et qu'il avait tout en utf8mb4_general_ci , ce que je vois aussi chez d'autres hébergeurs. J'avais cette recommandation de basculer tout en utf8mb4_general_ci ce qui me semble logique et universel.

Du coup j'aimerai savoir

1. Y a t-il une raison importante chez PH pour qu'il crée cette collation avec cette langue aussi spécifique par défaut ?
2. Pas besoin de basculer les autres sites dans cette langue ?

Possible d'avoir des retours PH-Mina-S ?

[woluweb]

salut herve,

Pour la collation/interclassement, c'est sûrement encore mieux de choisir utf8mb4_general_ci.
Mais je disais juste que je n'ai jamais constaté de problème en étant sur latin1_swedish_ci

Alors quasi tous mes sites sont chez PlanetHoster, mais concrètement :
- J'ai un seul site chez O2switch p ex, et là aussi je vois "Database Collation latin1_swedish_ci".
- J'ai quelques sites qui sont historiquement chez OVH et que les clients ne veulent pas déménager... et là aussi je vois "Database Collation latin1_swedish_ci"

Donc je ne pense pas que l'interclassement par défaut soit "piloté/décidé" par l'hébergeur.

[herve]

Bonjour
Ok j'entends à priori pas de problème (je ne peux affirmer que j'en ai eu un jour) . Peut-être que c'est Mysql qui impose cela ?

Si un jour quelqu'un ? PH-Mina ? pourraient 1 jour éclairer ma/notre lanterne avec ce choix quand même étrange alors que j'ai moi la connaissance (et d'autres sur joomla.org) de l'usage de utf8mb4_general_ci partout

[daneel]

Bonjour
Ok j'entends à priori pas de problème (je ne peux affirmer que j'en ai eu un jour) . Peut-être que c'est Mysql qui impose cela ?

Si un jour quelqu'un ? PH-Mina ? pourraient 1 jour éclairer ma/notre lanterne avec ce choix quand même étrange alors que j'ai moi la connaissance (et d'autres sur joomla.org) de l'usage de utf8mb4_general_ci partout

Lorsque MySQL a été initialement développé, le choix de l'interclassement par défaut était basé sur la compatibilité avec les systèmes existants. Latin1_swedish_ci était l'interclassement par défaut pour les anciennes versions de MySQL, et il a été conservé pour assurer la compatibilité ascendante avec les bases de données existantes lors de la mise à niveau vers les nouvelles versions.

"utf8_general_ci" est un interclassement conçu pour le jeu de caractères UTF-8. "utf8mb4_general_ci" est une amélioration pour prendre en charge pleinement l'ensemble des caractères Unicode, y compris les émojis et les symboles qui nécessitent jusqu'à 4 octets pour être encodés. L'encodage "utf8mb4" est une extension de l'encodage "utf8" qui ajoute la prise en charge des caractères sur 4 octets.

Si vous souhaitez prendre en charge l'ensemble des caractères Unicode, y compris les émojis et les symboles rares, vous devriez utiliser "utf8mb4_general_ci" comme interclassement comme indiqué dans l'astuce.

En résumé, si tu tombe sur un très vieux site avec interclassement Latin1_swedish_ci, c'est tout simplement un ancien choix qui n'a plus lieu d'être lors des migrations vers Joomla 4. Par ailleurs, il est fort probable que tu va utiliser utf8mb4_general_ci même sans le savoir car configuré par défaut.

[woluweb]

Haaa, daneel , cette bibliothèque vivante !
Encore merci pour toutes tes lumières !!!

[roland_d_alsace]

Hello.

Dans le passé j'ai déjà rencontré un problème similaire.

J'avais publié un petit topo sur le sujet : https://ordi-genie.com/tous/mysql-et...comlumn-at-row

[herve]

Bonjour
Merci pour ces infos.
Je pense qu'effectivement l'histoire est ancienne.
Cela serait bien maintenant que les nouvelles bases de données crées par les hébergeurs soient en utf8mb4_general_ci, aussi bien pour l'interclassement que la collation, et que cela évolue pour être plus universel !

Surtout si vous avez des membres de communauté (sans besoin d'être connecté) comme moi, qui font dans le front-end des copiers/coller de contenu avec notamment des icônes.
Cela plante et le visiteur ne comprend pas pourquoi ce site fonctionne si mal !

Il va falloir que je bascule tout ces sites en utf8mb4_general_ci pour l'interclassement :-( pour éviter ce genre de problème, avec j'espère pas trop de soucis lors de la migration