Effacement de ce qui suit un emoji dans un message

Bonjour, à la prévisualisation, lorsqu'on a un emoji dans le champ du message, il s'affiche correctement, ainsi que ce qui suit. Hélas, j'ai constaté à mes dépends (https://zestedesavoir.com/forums/sujet/964/suppression-du-systeme-de-notation-des-messages/?page=10#p68258) que lorsque le message est posté, l'emoji et tout le texte qui le suit disparait. L'emoji en question est, d'après la palette des caractères d'OS X : ELECTRIC LIGHT BULB, Unicode U+1F4A1 (U+D83D U+DCA1), UTF-8 F0 9F 92 A1. Ce bug pourra être d'autant plus ennuyeux que le langage Swift d'Apple accepte (certes, c'est plus funny qu'autre chose) les emojis dans les noms de variables. Comme un cours sur Swift est en rédaction d'après ce que j'ai lu, ce bug pourrait être ennuyeux…

Maintenant que le dégât a eu lieu, deux questions : - s'il n'est pas possible de le corriger rapidement / simplement, un avertissement sera-t-il ajouté dans la fenêtre de rédaction ? - est-il possible de retrouver mon contenu caviardé dans les bases de données, sachant que suite à la constatation du bug j'ai édité le message pour indiquer qu'il n'est pas complet ?

Merci pour vos réponses.

Edit (près de 24h après) : je m'était planté sur le lien du message ayant le problème.

Ce bug pourra être d'autant plus ennuyeux que le langage Swift d'Apple accepte (certes, c'est plus funny qu'autre chose) les emojis dans les noms de variables. Comme un cours sur Swift est en rédaction d'après ce que j'ai lu, ce bug pourrait être ennuyeux…

Boarf Python supporte les noms de variables unicode depuis python3 ce qui rend ce genre de codes valides :

1
2
3
4
5
6
7
8

from functools import reduce
import operator as op

Σ = lambda *args: sum(args)
Π = lambda *args: reduce(op.mul, args)

print("Sum :", Σ(1,2,3,4))
print("Product :", Π(1,2,3,4))

Et pourtant en preque 10 ans je n'ai jamais vu aucun cours les utiliser réellement et encore moins dans de vrais codes en prod (à raison). Donc bon ce n'est pas parce que swift le supporte, comme d'autres langages, que c'est un problème car ça ne devrait pas être être discuté dans un tuto.

Pour ton problème il est fortement improbable que le message soit encore en base. Tu l'a modifié, il est disparut à jamais maintenant.

Il faudrait qu'on arrive à reproduire le bug pour voir d'où vient l'erreur.

Idem, Java supporte les identifiants Unicode depuis le début, donc on peut faire :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

public class I18N {

    private static final String العربية = "Hello World";

    public static void main(String... args) {
        String עברית = العربية ;
        日本語(עברית );
    }

    private static void 日本語(String 한국어) {
        System.out.println(한국어);
    }
}

Ce qui fonctionne direct dans IntelliJ mais que personne ne sensé ne fait…

Cela dit, le caractère dont tu parles (Unicode U+1F4A1) n'est pas dans UTF-16, ce qui pose sans doute des problèmes supplémentaires imprévus tant ses caractères sont rare. Par exemple, tu ne peux pas t'en servir dans un code source Java.

L'erreur vient très vraisemblablement du fait qu'il s'agit d'un caractère Unicode appartenant à la plage >= 0x10000 : il semblerait que SQL ne soit pas capable de les gérer et qu'il tronque donc le message reçu juste avant ce caractère. J'ai eu le même souci en essayant d'utiliser des caractères gotiques dans une publication sur DotClear.

Essai pour confirmation (la prévisualisation marche nickel). Si je me suis trompé, à la suite de cette phrase, un caractère devrait apparaître, suivi d'une autre phrase :

Donc ça viendrait du stockage en base ?

Probablement : notre base est en UTF-8 avec les restrictions MySQL 5.5.

Je n'ai pas vérifié l'existence de restrictions Python.

C'est le seul moyen que je vois pour expliquer qu'il y a exactement le même problème sur ZdS et DotClear (programmé en PHP) mais que la prévisualisation ne merde pas (ça ne passe pas par la BDD). Cela dit, ça doit être configurable, puisque Wikipédia n'a aucun problème avec ces caractères-là.

OK, donc il n'y a pas d'archivage des modifications ? Enfin, si quelqu'un peut vérifier que la base ne contient hélas effectivement plus de trace de la suite du message après le caractère posant problème, ça serait cool, afin que le cas échant je puisse restaurer au moins partiellement le reste du message…

OK, donc il n'y a pas d'archivage des modifications ?

Non le site ne garde que la dernière version. Donc si tu as édité c'est perdu.

Ok, tant pis…

Tu penses que ce bug peut être corrigé rapidement afin que d'autres n'en soient pas victime ? Et sinon, si le délai risque de s'allonger, est-il possible que vous envisagiez de mettre un avertissement dans le champ de rédaction indiquant que malgré ce qu'en affiche la prévisualisation, la présence d'un emoji empêche l'affichage de la suite du texte ?

À propos de prévisualisation, et si nécessaire, j'ouvre un nouveau topic si le bug n'est pas répertorié, pourquoi les expressions mathématiques (exemple : $V_{AB}$) sont-elle affichées « en brut » dans la prévisualisation ? Est-ce une volonté de soulager le serveur ou un bug ?