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 ㋡ ?
Emojis et BDD mutualisée
Related questions
- Connexion à mon compte client
144367
13.02.2019 09:51
- Serveur non sécurisé, celui-ci ne supporte pas FTP sur TLS
121244
03.09.2018 14:46
- reCAPTCHA erreur pour le propriétaire du site : clé de site non valide
106172
14.02.2019 16:17
- [FAQ] Comment mettre à jour mon site pour supporter Apache 2.4 ?
93218
28.07.2017 11:39
- Passage en php 7.4
91557
30.06.2020 05:05
- Augmenter taille PHP Post Max Size sur mutualisé ?
86719
04.12.2019 21:52
- The requested URL / was not found on this server
85906
02.03.2017 18:25
- NextCloud sur mutualisé
85615
07.04.2017 08:42
- Deploy d'un projet Node JS
85539
12.10.2016 20:18
- Ce site est inaccessible Impossible de trouver l'adresse DNS du serveur
85250
16.10.2016 16:24
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 !! ^^