I remember reading about Apple supporting emoji on the iPhone OS 2.2. Now that I’ve upgraded, I decided to try it out but for could never find it after hunting through the keyboard preferences. Googling showed that these cute little emoticons are only available for Softbank users. Thankfully, Steven Troughton-Smith has figured out that by editing a file on your iPhone backup, the “emoji” option suddenly shows up under Settings -> General -> Keyboard -> International Keyboards -> Japanese!

Now that I have the ability to enter these emoji on my iPhone, I figure I’d try it out by sending an email to myself. Alas, all I get is a list of of boxes. Time to look at the message content (relevant fields):

Content-Type: text/plain;
  charset=cp932;
  format=flowed
Content-Transfer-Encoding: base64
X-Mailer: iPhone Mail (5G77)
Mime-Version: 1.0 (iPhone Mail 5G77)
Subject: trying out emoji
Date: Sat, 31 Jan 2009 19:11:03 +0800

aGV5IHRoZXJlIPGQDQoNCvWc9d3wSPB78unzR/SY9Jv3RPCW9vnwlQ==

ok, pretty strange that it’s sent in cp932 encoding, but we’ll see:

>>> from base64 import b64decode
>>> s = b64decode('aGV5IHRoZXJlIPGQDQoNCvWc9d3wSPB78unzR/SY9Jv3RPCW9vnwlQ==')
>>> s
'hey there \xf1\x90\r\n\r\n\xf5\x9c\xf5\xdd\xf0H\xf0{\xf2\xe9\xf3G\xf4\x98\xf4\x9b\xf7D\xf0\x96\xf6\xf9\xf0\x95'
>>> s.decode('cp932')
u'hey there \ue10b\r\n\r\n\ue407\ue448\ue008\ue03b\ue220\ue23b\ue347\ue34a\ue528\ue055\ue520\ue054'
>>>

The Unicode code points look like they do correspond to the Softbank private use ones, so I’m going to use the emoji4unicode package to convert it to HTML. The following Python script will convert it to the various carrier’s representation:

import emoji4unicode
import carrier_data

s = b64decode('aGV5IHRoZXJlIPGQDQoNCvWc9d3wSPB78unzR/SY9Jv3RPCW9vnwlQ==')
uni = s.decode('cp932')

sd = carrier_data.GetSoftbankData()
dd = carrier_data.GetDocomoData()
kd = carrier_data.GetKddiData()

emoji4unicode.Load()
def find_symbol(pua, carrier):
    for sym in emoji4unicode.GetSymbols():
        uni = sym.GetCarrierUnicode(carrier)
        if uni and uni == pua:
            return sym

def map_symbol(sym, carrier, cdata):
    uni = sym.GetCarrierUnicode(carrier)
    if not uni: # no mapping for this carrier
        return sym.GetTextFallback()
    else:
        if uni.startswith(">"): # mapped
            if len(uni) > 5:
                raise Exception, "cannot handle this yet"
            uni = uni[1:]

        return cdata.SymbolFromUnicode(uni).ImageHTML()

softbank = []
docomo = []
kddi = []

for u in uni:
    hex = "%04X" % ord(u)
    if u > '\x7F':
        sym = find_symbol(hex, "softbank")

        softbank.append(sd.SymbolFromUnicode(hex).ImageHTML())
        kddi.append(map_symbol(sym, "kddi", kd))
        docomo.append(map_symbol(sym, "docomo", dd))
    elif u == '\n':
        softbank.append('<br />')
        kddi.append('<br />')
        docomo.append('<br />')
    else:
        softbank.append(u)
        kddi.append(u)
        docomo.append(u)

print "Softbank:<br />", ''.join(softbank).encode('utf-8')
print "<hr />KDDI:<br />", ''.join(kddi).encode('utf-8')
print "<hr />DoCoMo:<br />", ''.join(docomo).encode('utf-8')

Results below:

Softbank:
hey there

KDDI:
hey there

DoCoMo:
hey there

[サンタ][<][イチゴ][ナス][サル][イルカ][クジラ]

As you can see, DoCoMo has the least number of emoji’s, so many of the characters like “Santa”, “Strawberry”, “Eggplant”, “Monkey”, “Dolphin” and “Whale” are substituted by the fallback text format.

Do note that the python script is not optimized at all, and loops through every emoji in the database for each character it needs to convert. Also, if you need such functionality in your application, there are various libraries out there that already does the mapping well. This is just an experiment.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Not to worry, the Unicode consortium is a veteran when it comes to dealing with the hairy issues of creating standards that work across languages, cultures and geographic regions. They simply can’t please everyone.

To me, the motivation for this is clear — interoperability. The current state of affairs in the Japanese mobile industry leaves a lot to be desired: across the carriers, there exist different sets of supported emoji’s, different private-use characters, substitution mappings, and code pages (user-defined characters in Shift_JIS, really). As one can imagine, the results is chaos, and as I software engineer, I really don’t want to imagine what those poor software engineers have to do to make it “just work” when a message cross the carrier boundaries.

To illustrate my point, let’s look at what Google does when you send a message with some emoji characters from GMail to each of DoCoMo, Softbank, and au.

The screenshot above is for DoCoMo, but I also repeated the experiment for Softbank and au. From the bounce message, one can easily tell that what is saved as a sent message and what gets actually transmitted to each of the carriers’ SMTP server are all distinct in their encodings.

What’s saved in Gmail when you click on “Show original” embeds the graphics using standard mime techniques (multipart/related with CID URIs a.k.a RFC 2111) with an extension attribute called goomoji in the HTML version, which carries part of Unicode private use character assigned for it. For example, the crab is assigned U+FE1E3 in Google, so its goomoji value is 1E3.

What’s sent to DoCoMo is a different story altogether:

It’s a standard multipart/alternative message with 2 parts: text/plain and text/html, both encoded in Shift_JIS. Decoding the text/plain part gives:

>>> import base64
>>> sjis = base64.b64decode("W4NKg2pd+aT56ApYT1hPIIFfKF4tXimBXgoKaHR0cDovL3hyaS5uZXQvPXdpbAo=")
>>> sjis
'[\x83J\x83j]\xf9\xa4\xf9\xe8\nXOXO \x81_(^-^)\x81^\n\nhttp://xri.net/=wil\n'
>>> print sjis.decode("shift_jis", 'ignore')
[カニ]
XOXO ＼(^-^)／

http://xri.net/=wil

Since DoCoMo doesn’t have the decapods in their emoji set, it gets encoded as カニ (Japanese for crab) in square brackets. Next comes the double musical notes , which is assigned a user defined Shift_JIS value of F9A4 in DoCoMo (explains why I had to pass the ‘ignore’ parameter to the decode method above, Python has no way to map that that sequence to Unicode and therefore barfs). Same goes for the tulip . Ignoring the plain text “XOXO”, the last emoticon is a hug face , which Google assigned a code point to but none of the carriers use a graphic to represent. In fact, this is mapped to a Kao-moji (顔文字 – “face words”).

For au (KDDI), the message was also sent in multipart/alternative with text/plain and text/html parts but this time encoded in ISO-2022-JP. Similar situation here, where crab => [カニ], KDDI’s version of ISO-2022-JP for the musical notes and tulip emoji, and kaomoji for the hugs.

Similar deal for Softbank, but the charset specified is PDC, but it smells just like Shift_JIS with user-defined characters to me.

I hope by now you have an appreciation of the kind of fiddling that Google engineers had to do in order to get their messages to display properly on Japanese mobile phones, just because the carriers decided to go invent their own mappings and character sets. It’s no wonder that Google and Apple, with its recently announced emoji support in iPhone, are among those supporting this effort.

The ongoing work can be found here and all the emoji’s is available here and here in gory details.

If I had the time and luxury (read: paid) to participate, I would. I wish them all the best and hope to see a good set of emoji’s in Unicode soon.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Knowing that mobile usability is an important topic for OpenID implementors and users, and the rest of world probably has a lot to learn from the Japanese mobile ecosystem, I decided to exercise my Japanese skills and extract some points out of the slides (no, I’m not going to, nor qualified enough to do a full translation. Try Google for that). Please note that this is merely a best-effort translation and any error you find is likely to come from my ignorance.

Translated version follows the actual presentation:

• Considering Mobile OpenID
  • Taking into account Japan’s unique mobile scenario, explore the feasibility and methods of implementing mobile OpenID
  • Investigate if the protocol needs to be modified
  • Look at ways to make use of mobile characteristics to enhance usability
• Limitations and Characteristics of Mobile (Devices)
  • Technical Limitations
    • maximum URL length
    • Cookies support
    • IP address blocks and individual identification number (are we talking about carrier gateway IPs and identification headers?)
  • Device Limitations
    • manual URL entry – no way
    • manual ID/password input seems too difficult
• Maximum URL Length — Carrier Restrictions
  • DoCoMo
    • According to “NTT DoCoMo’s standard / guide for common device capabilities”…
    • Encoded URL maximum length = 512 bytes
  • au
    • From Open Appli (Java)
      • Maximum 256 bytes and ASCII only
      • Since this is only for “Open Appli (Java)” stuff, this source may not be reliable
  • SoftBank
    • From Web & Network Technical Information / Development Tool -> HTML Chapter – 2.5.8 URI Restrictions
      • Roughly 1024 bytes
      • Since this is only for “Open Appli (Java)” stuff, this source may not be reliable
  • Summary: Assume 256 bytes
    • Surprisingly small – is that ok?
    • As for au, since source code is in Java, should assume at most 512 bytes
• URL Length — Practical Observation
  • Logging in to pibb using myopenid (with SREG)
    • checkid_setup > 567 bytes
    • id_res > 921 bytes
    • checkid_immediate > 430 bytes
• URL Length — Think Harder
  • UA is used for Indirect Communication, so we only need to consider checkid_setup/checkid_immediate, id_res/setup_needed/cancel
  • checkid_* authentication requests can be done using GET or POST. With POST requests, the URL parameters go into the request body.
  • id_res/setup_needed/cancel comes in the form of HTTP redirect, so GET requests only
  • Empirically: id_res parameters requires a combined size of 728 bytes + the URL endpoint itself.
• Content Body Limitation for POST
  • According to ziguzagu: minimum 5KB (for DoCoMo PDC) => should be sufficient
  • we still need to solve the problem of indirect communication: id_res requires a lot of parameters
• Tackling id_res
  • Basics: OP attaches the authentication result as query parameters to the return_to URL and redirects the UA to it. Do we need anything other than the following for signature verification?
    • openid.mode
    • openid.ns
    • openid.response_nonce
    • openid.assoc_handle
    • openid.signed
    • openid.sig
  • According to OpenID Authentication 2.0, Section 11 “Verifying Assertion”:
    • The following steps are taken
      1. Verifying return_to URL
      2. Verifying discovered information
      3. Checking the nonce
      4. Verifying Signatures
    • Are the first two steps absolutely necessary?
    • The basic goal is to verify the data from the OP via indirect communication, it might be good enough to verify signature + nonce in this step?
    • If we had the ability to verify signature in check_authentication, that might work?
  • Therefore, adding mode, signed, sig, response_nonce to the URL, we get 468 bytes!
  • Moreover, if we delegate everything to the OP, we only need response_nonce and op_endpoint => 289 bytes.
  • Conclusion
    • Minimize id_res as much as possible
    • If we have a method to ask the OP via direct communication (keying off response_nonce), that would work.
    • We could also obtain parameters like identity and claimed_id from the OP in the same vein
• Cookie support in Mobile
  • DoCoMo doesn’t support cookies in the first place
  • au has separate secure/non-secure characteristics (?), and there’s a pitfall in using cookies in non-secure mode. (Translator’s note: Not quite sure what this means)
  • For Softbank, one cannot access cookies in SSL realm in non-SSL pages (much like the secure-characteristic operation)
  • Therefore, cookies are not quite useful for us
• The way that mobile web security works (Translator’s note: heavily interpreted)
  • There are published IP blocks that each mobile carrier uses
  • Unique identification number for the device/subscriber can be provided to the sites (via HTTP header). Used with published IP block, this is an effective way to identify a returning user.
  • Generally, it’s better to obtain the subscriber ID rather than device ID
    • imode ID
    • EZ-number
    • x-jphone-uid
  • Instead of cookies, device/subscriber IDs are used for session management
  • The availability of device/subscriber ID also eases the login process considerably at the OP’s end (during checkid_setup/checkid_immediate)
• What’s possible with Mobile OpenID
  • Unified identity for PC and mobile world
  • Possible ways to link the PC and mobile
    • enabling mobile to as your private information store
    • enabling mobile for settling payment
• Summary
  • There are challenges:
    • Maximum URL length problem
      • First, URL length needs to be shortened
      • Still, without fixing the protocol, we could exceed the URL length limit => counting on =nat for OpenID Authentication 2.1
    • Unique identification + IP — increases the convenience of using OpenID on mobile, but one must always remember to update the IP blocks lists.
  • Looking forward to more active discussions on Mobile OpenID next year

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Occasionally, I find myself needing to think of a product name or domain name for a web site. Ideas can knock on my head at any time: at lunch, in the toilet or waiting in the queue. I could note it down on a generic note taker on the phone, or jot it down on a piece of paper, but nothing beats being able to instantly find out if the domain is available and keep track of it in a dedicated app. Hence, DomainTool was born.

As with any great app, it should be simple to use, and addresses a focused need. Thus, you’ll find the following grand feature list:

• Query WHOIS servers to find out if a domain name is taken. Similar to the command line whois tool
• Bookmark a domain name, and query it again anytime
• Supports all TLD that has a published WHOIS server: COM, NET, ORG, BIZ, INFO, CC, JP, CN, TW, KR, MY, SG, PR, DE, EU, and many more!
• Supports Internationalized Domain Names (IDN)

Some screenshots:

By now, I suppose you’re dying to try it out on your iPhone, and I can certainly sympathize with that. It can be yours for USD0.99 (or the equivalent in your currency) — 70% of which goes to my coffee bank, and the rest goes to Mr. Jobs.

Get it here!

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.