Support Twemoji v2 and Unicode v8.0

[jstoeffler]

Some iOS emojis aren't aren't in the index,like 😎 for example (I believe it's :sunglasses:) .
I guess it's something hard to maintain, and I was wondering whether it's a good idea to get the data from another source.

php-emoji is based on a separate source for example. Github also has a repository for that.

Let me know if I'm missing something.

[tompedals]

You're right, now that the twitter/twemoji now supports Unicode v8.0 there are a lot more emoji available. I hope to update this library soon to support v2 of Twemoji as we want to support it in our product. I'll take a look at the other sources for emoji, thanks for those links.

[jstoeffler]

I'd be glad to help with this, and submit a PR.

I'm just confused how to build the index.json file.
I saw hat twemoji uses two different sources and compiles them somehow.

Those sources are

• http://www.unicode.org/Public/UNIDATA/EmojiSources.txt
• http://unicode.org/Public/UNIDATA/StandardizedVariants.txt

I think it makes sense to rely on those, as this library works with twemoji, if we can't use twemoji directly.

Would you mind providing some guidance on this ? Then I'll try to submit a build script and a new index.

[tompedals]

I can't remember where the original index came from now, I think it may have been https://github.com/github/gemoji/blob/master/db/emoji.json with some changes. This appears to contain all of the aliases.

[tompedals]

The data set you mentioned originally looks useful as it contains a has_image_twitter property for each emoji as well as everything else needed.

https://github.com/iamcal/emoji-data/blob/master/emoji_pretty.json

[jstoeffler]

I managed to create a script and re-built the index.

However there seems to be a problem with the generated regex. It has some special characters, like *, and breaks.

I believe it's because the format regex method doesn't handle the new emojis codes properly (some use more bytes?).

Let me know if you have any idea, I couldn't find exactly which codes were missing.

The data source also has skin variations, and some of them being handled by twemoji. It would be great to support them, but as for the naming, I'm not sure what would be best:

• the code, ex: :261D-1F3FB:
• the name with some suffix, ex: :point_up_skin_variation_1: / point_up_261D-1F3FB