Jeux de caractères "avancés"

Le problème exposé dans ce sujet a été résolu.

Bonsoir tout le monde !

Je n’aurais pas vraiment pensé que j’aurais à ouvrir un sujet à ce propos, comme quoi…

J’aimerais utiliser certains emojis dans une base de données. Celle-ci est en UTF-8, collation utf8_unicode_ci. Ma connexion est en utf8, apparemment si je mets utf8mb4 c’est tronqué ou remplacé ou que-sais-je, mais c’est bien utf8 qui est utilisé au final.

Les emojis que je souhaite utiliser sont les suivants :

  1. 🔥 (U+1F525)
  2. 💧 (U+1F4A7)
  3. ❄️ (U+2744)
  4. 🏳️ (U+1F3F3)
  5. ⚡ (U+26A1)
  6. ⛰️ (u+26F0)
  7. 🌌 (U+1F30C)
  8. ☀️ (U+2600)

Dans un premier temps, je pensais utiliser du texte brut, donc aucun souci, puis je me suis trituré les méninges pour trouver les caractères qui auraient un aspect uniforme chez moi et qui puissent représenter ce que je souhaitais. Je pensais les insérer en passant par phpMyAdmin.

Mais évidemment, je n’avais pas la possibilité de saisir les caractères 1, 2, 4 et 7. J’ai donc fait le moche et en ne changeant que la collation de la colonne qui allait les contenir (passée de utf8_unicode_ci à utf8mb4_unicode_ci), j’ai pu les saisir, ils s’affichaient (et s’affichent encore et toujours) correctement dans phpMyAdmin, mais en plus aussi dans l’application avec deux navigateurs (Firefox 59 et Edge — quitte à tester sur plusieurs navigateurs, au moins le faire sur deux à ce point différents).

Suite à ça, j’ai voulu publier mon application. Mais les quatre caractères qui m’avaient logiquement posé problème à la saisie ne s’affichent désormais plus correctement (alors que dans le fichier SQL, ils sont bien présents et OK). J’ai naïvement pensé qu’en les reprenant depuis les sites où je les avais trouvés initialement et les réinsérais dans phpMyAdmin (comme je les avais insérés la première fois), l’affichage serait corrigé.
Déjà, dans phpMyAdmin, ils étaient affichés correctement. Quand j’ai tenté de les remplacer, les mises à jour ne se sont pas faites, donc la nouvelle valeur était la même que celle qui posait problème. J’ai donc tenté de remettre du texte ASCII, puis remettre les valeurs que j’avais trouvées, mais l’affichage dans l’application n’est toujours pas ce que j’ai sur ma machine locale.

J’ai évidemment supprimé les caches à la main, vérifié le jeu de caractères du fichier SQL, rien de ce à quoi je pense ne semble y faire.

Les versions de PHP et de MySQL sont les mêmes (PHP 7.1.15 et MySQL 5.7.9), comme de phpMyAdmin.

Est-ce que quelqu’un pourrait m’expliquer comment ça peut fonctionner sur ma machine et pas en distant, et ainsi me fournir une piste pour que je puisse utiliser ces caractères de manière "portable" ?

Merci d’avance  :)

+0 -0

Je n’ai pas le DSN sous la main, là, tu voulais surtout voir le jeu de caractères je suppose ? Comme je passe par Doctrine (qui repose sur PDO) pour l’application et phpMyAdmin (qui lui repose sur mysqli), je vais voir pour le débusquer.

Mon fichier de configuration à ce niveau est le même sur les deux environnements (pour l’application), il n’y a que les identifiants qui changent, et ils sont dans un autre fichier.

La seule chose que j’ai en tête aujourd’hui, c’est que sur le serveur distant, j’ai peut-être changé le jeu de caractères de connexion par défaut dans my.ini pour avoir utf8mb4, et peut-être aussi le jeu de connexion par défaut pour phpMyAdmin. Il faudra que je vérifie, je n’y avais pas pensé hier.

+0 -0

La question est : de quelle connexion parle t’on (application ou phpMyAdmin) ?  :p

Je vais re-véfirier demain, mais je suis quasiment certain qu’au niveau de l’application, les réglages pour la connexion à la base de données sont les mêmes en local et en distant (outre ce qui doit évidemment être changé), et avec Symfony, le jeu de caractères à la connexion est par défaut en UTF-8, et le fichier contient la valeur par défaut (elle n’est pas présente uniquement quelque part dans le code).

Par contre, outre le réglage que j’aurais fait dans le my.ini, je finis par me dire que la version exacte de MySQL n’est peut-être pas la même. Je sais que j’ai bien deux 5.7, mais je ne me rappelle pas du numéro de patch. Là aussi, je regarderai demain.

+0 -0

A priori la version exact de MySQL devrait rien changer, 5.7 supporte ça sans problème.

Si j’étais toi la première chose que je ferais c’est dumper les 2 bases (distante et locale) et vérifier que c’est identique. Je suis pas un utilisateur de MySQL mais c’est moi qui me suis occupé de supporter l’utf8mb4 sur ZdS qui lui utilise MySQL et sans rien changer à la base, j’ai dû faire pas mal de machins sur les schémas et sur les indexes pour que ça passe.

+0 -0

OK, apparemment j’ai trouvé le souci.

Mes tables sont par défaut en UTF-8 (utf8), comme je m’y attendais. Mais la colonne que j’ai modifiée est, sur mon serveur local, définie avec `name` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL, alors qu’en distant, c’est "simplement" `name` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL… Ce qui colle à ce que tu soupçonnais.
Manifestement j’ai dû faire des modifications en local après l’export.

Théoriquement, si je passe toutes les tables et colonnes au jeu de caractères utf8mb4, le souci devrait être réglé, non ?
Cependant j’y avais déjà pensé, et j’en suis toujours là…

Aloïs est déjà venu me rendre visite, pas bon signe…

Edit

Je crois bien que j’ai une piste plus sérieuse.

J’avais déjà mentionné que j’avais fait des modifications dans my.ini sur le serveur distant. Plus précisément, j’avais mis skip-character-set-client-handshake. Je pouvais donc bien m’escrimer à comprendre ce que j’avais réglé de faux entre les colonnes et la connexion depuis phpMyAdmin ou l’application…

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte