Long ago we had mojibake, with many programs mangling Unicode. Eventually, almost all software handled Unicode properly. Then to celebrate… we started mangling emoji in a different way, re-encoding them into ASCII, as shortcodes and the likes.

The effect of this is that you now have to decode your Unicode strings to handle emoji properly.

Slack bots now receive :emoji_shortcode: rather than the actual emoji that I entered; and if they pass it on to another system, my emoji is now mangled, unless that tool implements emoji decoding, on top of the Unicode decoding it’s already done.

Or third-party clients: again, extra decoding needed to get the real emoji back.

Or, to take a slightly different tack, Dropbox Paper emails, with remote images disabled: it’s like Outlook all over again L, but this time with words instead of a letter white frowning face.

Or again, the sorts of things where you copy and paste and you get either an image or the name of the emoji, rather than the emoji itself.

To be clear: I’m not railing against emoji names or shortcodes as an input format, only as a storage and exchange format, where it seems to me strictly inferior.

I’m honestly flummoxed about why so many systems are doing this; I can’t think of any plausible reasons in favour of it.

• For accessibility tools that don’t know how to read emoji? No, these platforms still transform the emoji at display time, to use their own images or fonts; they could do it there.

• For Unicode forwards-compatibility? Unconvincing for the same reason.

• For custom emoji? Just use :emoji_shortcodes: for the custom emoji only, and normalise the rest back into Unicode.

I’m stuck and frustrated with these systems. Does anyone know why we’re normalising into a verbose ASCII format rather than into the proper Unicode code points?