I don't think Unicode emoji make sense in the long run - even if they're handy in SMS, and fun to scatter around normal text boxes, it would be better to use chat protocols with their own sets of consistent emoticons (as, indeed, many mobile messaging apps have). Why?<p>(a) Details matter. It doesn't matter if my 'A' displays in a different font on your phone, but the difference between Apple's colorful, pixelated, Space Invaders-like rendering of <a href="http://www.fileformat.info/info/unicode/char/1F47E/index.htm" rel="nofollow">http://www.fileformat.info/info/unicode/char/1F47E/index.htm</a> and the server-generated image's outlined round tentacle monster is fairly significant.<p>(b) Emoticons (at least those beyond the core set) are things of fashion: we always want more, but old ones go out of style. Though depictions can change, we're going to be stuck with the current list of Unicode emoji forever.
Emoji is such a weird thing. On one hand, I use them constantly for IMing. A quick 👍 is 10x better than the single-character "K" response in terms of expressiveness and playfulness.<p>On the other hand, the symbol coverage seems very random to my western brain. For example, there are three different mounds of rice, but no tacos. Nine different commuter trains, but no motorcycle. Also, the seemingly random assortment of flags.<p>I know this is a result of their Japanese origins, but if I had my druthers, emoji would be a little more inclusive, and then phones would have a little emoji-editor where you could edit your keyboards so they only included the symbols you wanted to use.
These are to support emoji symbols in Unicode. There's a lot in there beside pizza - party poppers, wedding chapels, game console controllers, "information desk person" and the ever mysterious "Japanese goblin".<p>PDF chart at<p><a href="http://www.unicode.org/charts/PDF/U1F300.pdf" rel="nofollow">http://www.unicode.org/charts/PDF/U1F300.pdf</a><p>for the full glory of it all.
Fun story about emoji and unicode:<p>I have a writing app I've developed for iOS, and a while ago received a bug report from someone saying the app crashed every time they tried to open their document. I couldn't figure out what was going on but after eventually receiving a copy of the document, I discovered that the crash was due to my incorrect handling of emoji characters.<p>Most string classes, including NSString in iOS, typically represent strings as sequences of 16-bit characters. With 65,536 possible combinations, this is perfectly adequate to support the characters from all major languages in use worldwide [1], plus emoji. Unicode does however allow for values outside of this range, which are represented by "surrogate" pairs of 16-bit values in the range D800-DFFF. It was these I was handling incorrectly, and had missed in my testing.<p>But if there's space in the 0-65,535 range to represent emoji, why would it be stored outside of this? Well, it turns out that the initial implementation of emoji in iOS used the "private use area" of this range to encode the character values [2]. NTT DoCoMo also had their own (incompatible) way of encoding emoji in the private use area [3]. When attempts were made to formally standardise on emoji in unicode, they couldn't use the private use area, and ended up going with values above 65,535.<p>If unicode had stuck to representing existing characters and symbols and said no to requests for stuff like emoji and klingon, string representation in modern software could have been kept a whole lot simpler.<p>Joel Spolsky has an excellent explanation of unicode and encoding issues here:<p><a href="http://www.joelonsoftware.com/articles/Unicode.html" rel="nofollow">http://www.joelonsoftware.com/articles/Unicode.html</a><p>[1] To the best of my knowledge; correct me if I'm wrong<p>[2] <a href="http://openradar.appspot.com/6402446" rel="nofollow">http://openradar.appspot.com/6402446</a><p>[3] <a href="http://web.archive.org/web/20080216230900/http://www.nttdocomo.co.jp/english/service/imode/make/content/pictograph/basic/index.html" rel="nofollow">http://web.archive.org/web/20080216230900/http://www.nttdoco...</a>
Might be a good time to plug <a href="http://codepoint.tumblr.com/" rel="nofollow">http://codepoint.tumblr.com/</a><p>I haven't touched it in years as you can see, but it was fun while it lasted.
Interesting. In Google Chome, I just see squares where the character should be. However, if I copy and paste it into the url bar, or anywhere else in OSX, I see a color picture of a pizza.
looks different for me here <a href="http://www.fileformat.info/info/unicode/char/1f355/browsertest.htm" rel="nofollow">http://www.fileformat.info/info/unicode/char/1f355/browserte...</a>