In 1997, the Japanese invention is defined in the private area of unicode.
In this case two bytes may represent emoji.
IOS 4 in Japan to support emoji, using this proprietary coding.
In 2010, unicode 6.0 officially supports emoji, emoji all re-encoding.
In this case where the coding range emoji exceeds 2 bytes.
IOS 5 start, unicode support of emoji, emoji give up private support for the Japanese.
So, the same emoji, especially those old emoji, there are two coding.
Support for different systems, different.
Although the same code emoji, but like is proprietary, so the respective system, showing it may vary.
Because of emoji unicode representation beyond the range of 2 bytes, the system needs a lot of character encoding to support emoji. For example, mysql, it supported after updating utf8mb4.
Japanese encoding, in fact, more than one, if you want your emoji can be displayed in all systems, you need to do the conversion when displayed.
Development of emoji, unicode encoded evolution, as well as a variety of system changes to support the string encoding format, the three interact together and cause all sorts of interesting questions. Almost every emoji can not show, behind these three are related.
Because it involves the coding of the underlying support system, often the problem not been resolved.
Originally wanted to be careful to write an article, recently ill, the energy is not allowed. References Read the list of interested me, very interesting.
Reference
https://gist.github.com/mranney/1707371#file-emoji_sad-txt
https://en.wikipedia.org/wiki/Emoji
http://doc.cat-v.org/bell_labs/utf-8_history
https://emojipedia.org/unicode-6.0/
https://stackoverflow.com/questions/7856775/how-to-convert-the-old-emoji-encoding-to-the-latest-encoding-in-ios5
https://en.wikipedia.org/wiki/Private_Use_Areas
https://www.iamcal.com/emoji-in-web-apps/