At this point, the string is raw Unicode. The emoji character uses the operating system default representation, and the string is able to be copy-pasted into other applications.
A note on autocorrect: autocorrecting of shortcodes, and emoticons (
o_O) can lead to issues. The interpretation of emoticons may not be universal, for example,
:$ may mean ‘embarrased’ to some, but ‘money mouth’ to others. Also,
:100: is the shortcode for 💯, but is also used a lot in IPv6 addresses. Allow for disabling of autocorrecting, and store the raw text serverside as not to lose meaning.
Output is harder.
On mobile this is delegated based on the operating system emoji support, but the level of support highly varies based on the operating system.
For example, iOS 5.0 supports “emoji” in private space, but iOS 6.0 was the version version to support Unicode 6. The most recent version to date is iOS 9.3 which supports Unicode 8. iOS 10 will support Unicode 9.
The same Unicode version support updates with Android. Unlike Apple, the emoji representations in Android vary greatly between versions. Starting out with black and white emoji in Android 4.3, the implementations in Android 4.4 were.. suboptimal
Image from Emojipedia’s Green Heart entry
This has improved over time, with more recent versions of Android consolidating on representations more in-line with the Apple “standard” (and the Unicode standard. Which helps.) Also, more recent versions of Android support more recent versions of Unicode. Android 5.0 supports a better representation of Unicode 6.0, and Android 6.0.1 supports up to and including Unicode 8.
The same rule of upgrades holds true for OSX. El Capitan supports up to and including Unicode 8, where as Yosemite only supports up to and including Unicode 6.1. This means that there are a number of characters that just won’t display on Yosemite or below.
To get operating system level support for the new emoji, upgrade your operating system. You also get security updates for free!
Depending on the browser and operating system you use, this is highly variable.
To check what your preferred browser and operating system supports, check out this unicode test page. Results will vary based on your browser (on El Cap, Firefox Safari and Android results are all slightly different), but any emoji that show as replacement characters or squares will show any versions of Unicode you don’t have support for.
This is why I advocate for defaulting to fallback images for all websites that display emoji. Otherwise, the output is far to variable, and prone variability.
The best implementation of this to date is the Twitter Web style. It uses alt text, title attributes, and in Direct Messages containing only emoji, bigger images. This works really well, and helps mitigate misinterpretations in emoji
You can see the resulting HTML using this method below
<img src="img/1f643.png" alt="🙃" title="Upside Down Face" aria-label="Emoji: Upside Down Face">
Here is an example of this implemenation: , the upside down face.
The benefits of using this method include:
Try these on the inline image above.
I’ve seen no client-side solution that includes the title texts. This is probably because the amount of data required to list all the emoji descriptions is several megabytes of raw text. Caching and such aside, it’s a lot of data. Twitter solves this by using server-side logic so the client is saved from a hefty download, but unfortunately their implementation isn’t available.
It should be relatively easy to implement such a solution for whichever web platform used, given all the Unicode data is public, and Twemoji and EmojiOne are sufficiently licensed to allow for use in such implementations.
A proof of concept for such an implementation is available for Python in the emojificate package. Technical details relating to the implementation are provided in the README.
With an ever-changing Unicode standard, having a solution that works on a platform-independent basis is paramount to mitigating miscommunication. There are continual updates to the representations of emoji, but they will only be useful for those who have the ability to update their platform. Having a works-everywhere solution will help solve for emoji now, and allow for a way for future updates.
 If this means people stop using known-broken versions of Android, et al, by promoting that you’ll get new emoji with your security updates, then I’m all for it.
Update 2018-08-08: added “A note on autocorrect”