search

joypixels / emojione

[Archived] The world's largest independent emoji font. Maintained at https://github.com/joypixels/emoji-toolkit.
https://www.joypixels.com
Other
4.46k stars 536 forks source link

Problematic second colon in shortcode for ☀️ (:sunny:️) #644

Closed zarko-tg closed 5 years ago

zarko-tg commented 5 years ago

We've found by accident that (at least one type of) emoji yields a shortcode with a non-standard closing colon.

emojione.sprites = true emojione.ascii = true

emojione.toShort('☀️') will return screenshot 2019-02-20 at 09 50 18 (Pay close attention to visual difference between the first and the second colon)

Such an inconsistent format / non-ASCII colon is causing certain troubles in our remote systems so we're forced to remove hex efb88f from the shortcode so that only a regular second colon remains in the string.

This does not seem to be the case for other emoji shortcodes. Is it so on purpose or is this a bug?

We're on emojione 4.5.0

zensasian85 commented 5 years ago

This is confirmed.

We also experienced same issue, but it's not only the sun. The emoji "heart" has the same issue well. We are wondering what over emojis have the same issue.

Though, we only experienced this issue on iOS. Android has no problem. We are using the emojione.toShort() to save the symbol as colon-based in the database

So when converting with emojione.shortnameToUnicode(str) in our app, we get the emoji with a questionmark at the end like this: ☀? ❤?

For one app, we are using version 4.0.0, and for an older app, we are using version 3.1.7

Please look into this.

---- UPDATE! ---- We did some more debugging, and found some interesting things. Have a look at the image below: 4DD6E8F7-3519-464A-8608-DC62177F8407 As you can see, a weird symbol is being added. The weird symbol's code is: 65039

Again, we are only experiencing this issue on iOS.

So for now we ended up making this function to fix the problem: string.split("").filter(f => f.codePointAt(0) !== 65039).join("")

Not the prettiest, but should fix the issue. We still would like you to look into this issue.

caseyahenson commented 5 years ago

Great find @zarko-tg, we'll get a fix for this put out soon

dkasak commented 5 years ago

Incidentally, the definitions for those emojis appear to have the wrong fully-qualified sequence specified: they are missing the VARIATION SELECTOR+16, i.e. 0xFE0F == 65039, to make them a proper fully-qualified sequence.

   "name": "red heart",
...
      "fully_qualified": "2764",
...
      "default_matches": [
        "2764",
        "2764-fe0f"
      ],
    "name": "sun",
...
      "fully_qualified": "2600",
...
      "default_matches": [
        "2600",
        "2600-fe0f"
      ],

This seems probably related.

stephenreddek commented 5 years ago

@caseyahenson Do you have any update on timeline for a patch release?

caseyahenson commented 5 years ago

@stephenreddek looking like by July 10 for this fix (along with the version 5.0 update), and will likely require a migration to the https://www.github.com/joypixels/emoji-toolkit library as we'll be deprecating this repo starting with 5.0.

stephenreddek commented 5 years ago

@caseyahenson Great. Thanks so much for the update!

caseyahenson commented 5 years ago

This is fixed in the 5.0 release https://github.com/joypixels/emoji-toolkit/releases/tag/5.0.0.