Nokia and Google Suck at VCard

Ever wonder why your computer, even if it sports the latest technology, doesn't seem to be able to perform the simple things you ask it? It may not be you. Despite glittery marketing and millions of dollars spent, big companies like Nokia and Google can't even take the time to do simple things right. A case in point: transferring a list of contacts between a Nokia phone and GMail will only happen without snags if you have the simplest of data, and this is because of lazy developers didn't implement the VCard specification correctly.

The VCard 3.0 specification was finished in 1998 and was published as an Internet standard, RFC 2426. It consists of the simplest of data: essentially a bunch of rows of name:value pairs. There are a few simple rules regarding encoding of certain characters, but otherwise the specification is widespread and straightforward. So when I decided to finally take the Android plunge and transfer my telephone numbers from my recently-released Nokia C3-01 phone to GMail so that I could sync it with my Android phone, I expected things to go smoothly. I was wrong.

Nokia practically invented the mobile phone market, so with its years of data-processing experience you might forgive me for expecting their engineers to actually read the VCard specification. But after I told my Nokia C3-01 to perform a backup of all my contacts, here's an example of what it gave me:

ADR;CHARSET=UTF-8;ENCODING=8BIT:;Oak and Pine;123 Oak Street;San Francisco;CA;94120;USA



First off, you'll notice that the VERSION indicated is 2.1. The latest version, VCard 3.0, has been around since 1998. One would think that some time in the past decade that Nokia would have taken the time to update its VCard support.

But there are worse problems. Look at BDAY, the birthday property. The standard VCard 3.0 approach is to use the same ISO 8601 format recommended by the W3C, or 1970-01-02 in this case. Perhaps we could forgive Nokia, if it were following VCard 2.1, for foregoing delimiters. But why does it add a time element (000000)? This is not present in the VCard 2.1 BDAY examples, and although the VCard 3.0 examples do allow for an optional time component (if one wants to indicate the exact time of birth), the latter clearly indicates that the form with hyphens should be used. And if that's not enough, when we fix the value by changing it to 1970-01-02T00:00:00Z, Google can't understand it—we have to remove the time component altogether.

But there are worse problems still. Look at the NOTE, which has a string of text encoded as bytes in Base64! Again the heart of this problem lies in VCard 2.1, which recommends Quoted-Printable or Base64 for any text value that contains line breaks. (The newer VCard 3.0 specification uses common escape sequences for control characters, such as '\n' for a line break.) Perhaps the root of my complaint lies with the choice of VCard 2.1 rather than VCard 3.0, but my complaint lies also with Google. With billions of dollars at its disposal, one would think that Google would have provided at least a single engineer to enable the GMail import facility to support VCard 2.1. But no, all the Nokia note fields are not decoded—they go straight into my GMail contacts still in Base64, which is not helpful in the least.

But in other properties where line breaks might be needed, such as ADR, Nokia became creative in its choice of representation. Rather than Base64-encoding ADR, the Unicode line separator character (U+2028) is used. This is found nowhere in the VCard 2.1 or VCard 3.0 specifications. And it causes problems, for example, when trying to import such a VCard directly into a phone such as the Samsung Galaxy S 4G.

So, as always, I was stuck with writing my own custom VCard parser code which tidies up all the values from Nokia so that Google can digest them. If you'd like, you can download the entire globalmentor-core library, which you can easily build from the included Maven POM. I next intend to create a simple Java utility based on this library that will take all my Nokia contacts from a phone backup, fix up the values, and put them into the single file that GMail likes to import from. My code turns the above Nokia mess into this:

FN:Ms. Jane Lívia Doe
ADR:;Oak and Pine;123 Oak Street;San Francisco;CA;94120;USA
NOTE:This is just a test.\nIsso é só um exemplo.\n--\nThis is another note.

You'll notice that my code even combines the two NOTE properties, because Google can't handle more than one note and will discard all but the first.

So after all my contacts are on Google, it would seem that I'm in good shape—until it's time for me to export the contacts back out of GMail so that I can sync them back with Nokia. GMail's VCard output looks reasonably nice:

FN:Ms. Jane Lívia Doe
ADR:;;123 Oak Street\r\nOak and Pine;San Francisco;CA;94120;USA
NOTE:This is just a test.\nIsso é só um exemplo.\n--\nThis is another note.

But wait a second: why did Google move the ADR extended address "Oak and Pine" into the street address component? And worse still, why did it separate the two using an '\r\n' (CRLF) sequence? The VCard 3.0 specification clearly states that CRLF must be escaped by the single escape sequence '\n', not by '\r\n'.

Oh, and all those pretty pictures that I had attached to my contacts on my Nokia phone? They import just fine into GMail contacts—but Google decides to discard them when it exports the contacts back out to VCard format.

Parsing a VCard should be one of the simplest things in computer science—much simpler than an XML parser. VCard has been around for over a decade, it's well-documented, and it's an international Internet standard. But yet again, I have to write my own implementation if I expect it to work. Forgive me for thinking that there are a few lazy and ignorant developers at Nokia and Google.