Serialize des contenus avec emojis

Certains jobs (et mails !) se perdent en raison d'un échec de la désérialization des arguments, alors que d'autres jobs avec la même fonction (envoyer_mail en l'occurence) et insérés par le même code fonctionnent bien. L'examen révèle que c'est à cause d'émojis présents dans les contenus éditoriaux passés en argument tableau à job_queue_add.

Les commits de Maieul dans formidable https://git.spip.net/spip-contrib-extensions/formidable/commit/156be061 et https://git.spip.net/spip-contrib-extensions/saisies/commit/70601313 révèlent l'origine du problème : « Si un tableau sérializé avec serialize() contient des émojis, alors la déserialisation échoue car les sommes de contrôles ne sont plus bonnes. Pour éviter cela, on passe utf8_noplanes() sur nos tableaux avant de les serialiser. »

Donc dans le cas de job_queue_add, il semble qu'il faudrait immédiatement appliquer un utf8_noplanes sur les éléments du tableau des $arguments, avant de le serializer (ainsi que le fait formidable_array_utf8_noplanes )

Plus généralement, le problème se pose partout où il y a usage de serialize, alors une solution universelle serait bienvenue.

Maieul propose une PR pour SPIP en relation https://git.spip.net/spip/spip/pulls/5094/

Il commente sur IRC :

En gros on a 3 solutions :

• soit effectivement on applique systématiquement la fonction inverse en lecture:
  • avantage : au moins c'est generique
  • inconvenient : a mon avis pas terrible en perf (et du reste je suis pas sur que ma fonction inverse soit exactement l'inverse, en raison du fait que potentiellement en UTF8 tu peux avoir un même emoji qui soit sous 2 formes différentes)
• soit on fournit une fonction generique qui permet d'appliquer utf8_noplane() sur un tableau, et toutes les fonctions qui savent qu'elles serialisent un tableau l'appellent
• soit, et c'est globalement le mieux, on se passe de serialisation PHP pour preferer du json_encode