Embedding iPhone and Android emojis

[csdude55]

I'm using contenteditable to allow users to post on my message board and send Private Messages. So it's "rich HTML" instead of using BB tags like this site.

I offer a bunch of built-in emojis, but they don't work on mobile devices (or they didn't; I haven't checked lately). People on mobile can open their own emojis on their keyboard, though, and with contenteditable it looks like they plug in and work, but... they don't, really.

For testing, I sent a message from my Android to a friend on iPhone. They opened it with Chrome for iPhone, and my emojis showed up just fine. Then they replied to me, and I opened their message using the default Android browser and then Chrome for Android, and both showed their iPhone emojis.

Then I opened them in Firefox, and the emojis worked fine there, too.

But then I opened their message using Chrome for desktop, and instead of the regular emojis I got some sort of ASCII-type of emoji, not the images sent.

Then I tried it using IE, and I just got a bunch of square blocks.

In the database, they show up like:

😊😜�😎🙄

(those are 5 different emojis)

Can you guys suggest a way that I can successfully embed these for all browsers? Maybe a font to import, or a package of images to download and manually convert each symbol to an <img src='...'>?

[lucy24]

I don't believe this is actually an emoji issue as such. It's about (a) different devices having different fonts installed (emojis are, O disgust and horror, a whole Unicode sector, notably 1F600 through 1F64F but also some others) and (b) though less common nowadays, different browsers having different Font Substitution skills. (MSIE has historically been the most grossly inept and backward in this area.)

Amusingly enough I just recently met an almost identical problem from the other end. I made an ebook of a text from 1841 that included a long list of astronomical symbols, most of them in the 2600-26FF area. It was a nasty shock to discover that certain built-in fonts don't display them as ordinary, dignified-looking, black-and-white letters but as colorful 3D emoji. So I had to do The Bad Thing and instruct the document to use {list of exact fonts} if it possibly could, just so this one article would not come out looking utterly ridiculous.

Sure, you can import a font. If so, I recommend editing it down to just this group of characters, so users don't have to download a multi-hundred-kilobyte file when all it's supposed to be used for is emojis. But then you'll get the users who don't want brightly colored emoji jumping out at them. I assume you've eliminated the idea of treating them like smileys with a one-on-one substitution: in the same way that typing ":-)" yields your forums's chosen happy-face, typing #&x1F600 by itself could yield some other resident smiley.

In the database, they show up like:

That's characteristic of multi-byte characters stored in a one-byte character set. If your users typed plain text in Russian or Chinese, it would look equally alarming. Some quick experimentation confirms that if I enter some basic emoji and then reinterpret as ISO-Latin-1, what I mainly end up with is ð (eth).

[not2easy]

There are services that provide just the block(s) of Unicode characters used for emojis. For WP I see s.w.org embeds via json as though every WP site invites their use. Similar to Google fonts, they are "embedded" requiring users to download some extra bytes. I have no recommendations for that, but if you look around there is likely a compatible service. The users' devices will show them differently depending on their OS and browser though they are fairly standardized for intent. IE/Edge might still be dodging their implementation. They never liked Unicode, seem to be waiting for it to go away.