Emojis et BDD mutualisée
BMPCreated with Sketch.BMPZIPCreated with Sketch.ZIPXLSCreated with Sketch.XLSTXTCreated with Sketch.TXTPPTCreated with Sketch.PPTPNGCreated with Sketch.PNGPDFCreated with Sketch.PDFJPGCreated with Sketch.JPGGIFCreated with Sketch.GIFDOCCreated with Sketch.DOC Error Created with Sketch.
Question

Emojis et BDD mutualisée

by
DanielM1
Created on 2017-05-06 16:08:22 (edited on 2024-09-04 11:53:40) in Hébergements Web

Pour qu'une table MYSQL accepte les émojis, dans PHPMYADMIN cliquez sur le nom de la table, puis "OPERATIONS" puis changez l'interclassement en 'utfmb4_unicode_ci' **en prenant bien soin de cocher la case 'changer le classement de toutes les colonnes**' avant de cliquer sur Exécuter.
Evidemment, avant cette opération il est conseillé de dupliquer la table au cas où ...
N'essayez pas de modifier l'interclassement à partir des colonnes elles-mêmes, vous allez droit à la cata.
Une fois le clic effectué, la table accepte les émojis du type que l'on peut trouver sur https://fr.piliapp.com/symbol/ par exemple ☺
Et la table accepte également les émojis Smartphones comme ceux présentés sur https://emojipedia.org/ 😇 ... A condition que cette table se trouve sur votre wampserver ou sur LWS ... Mais pas sur OVH, où ça ne fonctionne pas. Ce second type de smileys se transforme en ???? dans la base de données.
Personnellement j'ai, non seulement modifié les tables, mais également la base de données pour la passer en utf8mb4, mais rien n'y fait.
Une idée sur ce problème ㋡ ?


8 Replies ( Latest reply on 2021-08-27 18:11:58 by
EstebanT
)

utf8mb4 ou utf8 est un préalable, avant l'interclassement

quel domaine?
où est l'hébergement? Paris/Gravelines?
quel version de mySql server?
tu as exporté ta table pour voir les entêtes?

Sur OVH, il s'agit des bases 400 mo fournies avec l'offre pro2014, datacentre gra2.
3 bases de données type MYSQL v.5.6 d'après le manager.
Sur une exportation de table, La version du serveur OVH indiquée est '5.6.42-log', contre '5.7.14' sur le wampserver local et '10.1.37-MariaDB-1~jessie' chez LWS (qui, eux, acceptent les 👂💓...)
La version PHP est 5.6.40.
La structure de la table 'test' exportée indique bien que le mb4 est pris en comte :
CREATE TABLE `test` (
`id` int(1) NOT NULL,
`Message` char(100) COLLATE utf8mb4_unicode_ci NOT NULL,
`Texte` text COLLATE utf8mb4_unicode_ci NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

Version serveur 5.6.42-log dépassée ou limitations spéciales OVH ?

> Version serveur 5.6.42-log dépassée ou limitations spéciales OVH ?

je ne sais pas trop
tu as vérifié dans `.ovhconfig` que ton container.image est bien: `stable`?

j'en aurai appris une: https://stackoverflow.com/a/39465494

L'ovhconfig est correct (container.image=stable).
Sur https://stackoverflow.com/a/39465494 il est question d'un problème qui affecte tous les émojis. Un exemple cite 😊❤️.
Sur ces 2 smileys copiés sur la page et insérés directement (phpmyadmin) sur la table de test , 😊 ressort en ???? et ❤️ est correctement enregistré. Le problème n'affecte que certains caractères spéciaux. Ces 2 caractères s'enregistrent normalement sur les autres BDD dont je dispose, hors OVH.
A noter que sur https://stackoverflow.com/a/39465494, il est question d'utiliser utf8mb4_general_ci ou ufthmb4_unicode_bin mais cela n'apporte aucun changement au problème 😢

ok, j'aurais pensé que uft8mb4_unicode_bin aurait réglé ton souci

```text `-- Server version 5.7.23-log`
```sql
CREATE TABLE `test` (
`id` int(1) NOT NULL,
`Message` char(100) COLLATE utf8mb4_unicode_ci NOT NULL,
`Texte` text COLLATE utf8mb4_unicode_ci NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
```
https://i.imgur.com/RlcWyeA.png

par contre échec dans le dump:
```sql
INSERT INTO `test` VALUES (0,'?❤️??','?❤️??');
```

même résultat (échec dump) avec
```sql
CREATE TABLE `test2` (
`id` int(1) NOT NULL,
`Message` char(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,
`Texte` text CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_520_ci;

CREATE TABLE `test3` (
`id` int(1) NOT NULL,
`Message` char(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,
`Texte` text CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;
```

serveur non chez Ovh

j'ai la flemme d'essayer avec Sql privé en 5.7, mais si vraiment besoin... ```

Sur la BDD OVH mutualisée,
UPDATE `test` SET `Message` = '😊❤️😢👂', `Texte` = '😊❤️😢👂' WHERE `test`.`id` = 1;
ca donne :

C'est à dire qu'on n'en est même pas encore au problème 'Dump'.
Bref, il semble donc que le problème vienne de la version trop ancienne du SQL proposée par OVH avec les hébergements mutualisés.
Vu qu'il n'est pas possible d'updater soi-même la BDD commune, le problème n'a donc pas, à priori, de solution en 'mutualisé'

sql privé en 5.7 ?
mais ça reste à vérifier

Non, le SQL privé sur OVH j'ai déjà testé il y a 2 ans et ça ramait, sans compter que ça revient cher par rapport à ce que l'on trouve ailleurs.
Mon dernier site n'a pas sa BDD propre. Il fonctionne en appelant des modules sur un autre site pour récupérer les éléments sur la base de données de cet autre site. Donc il suffit de transférer les modules et la base de données de cet autre site d'arrière plan sur un autre serveur, et changer juste les URL des appels sur le site d'accueil des visiteurs, sans avoir à changer l'hébergement dudit site 'vitrine'.
Le problème n'est donc pas mortel pour moi. C'est plutôt pour les clients de mutualisés OVH qui prévoient l'utilisation de messages via Smartphones sur leurs sites que j'ai une pensée triste.

ok
sauf que l'appel à une base externe sur un autre hébergeur n'est pas une fonctionnalité gagnée d'avance?

Ce ne sont pas des appels à une base externe.
Ce sont des appels à des modules situés sur un site externe qui utilise sa propre base de données. Les modules extraient les informations de la BDD et les renvoient au site appelant.
Comme sur un réseau où les périphériques font appel au serveur qui stocke les informations. Les périphériques n'ont pas accès direct à la BDD.

Bonjour,

Avez vous trouvé une solution depuis, je rencontre le même problème :/

Bonjour @EstebanT

Je ne connais pas ton contexte exact, mais les bases de données des hébergements Mutualisés ne sont pas disponibles en dehors de cet hébergement.

Le problème a été résolu après intervention de OVH sur ses bases de données.
Ceci-dit, il faut veiller à ce que l'interclassement de la table soit en utfmb4_unicode_ci ou, au moins un autre utfmb4... et que l'encodage des pages html soit en utf8

@DanielM1

Yep, normalement c'est fait mais ca change juste le nombre de points d'interrogations :/ . J'ai fait un post sur ce forum de mon problème : https://openclassrooms.com/forum/sujet/inscription-smiley-dans-bdd#message-94225696 .

Merci à vous !! ^^