[Vpim-talk] editing and deleting fields in a vcard

Sam Roberts sroberts at uniserve.com
Sat Mar 4 02:24:17 EST 2006

Quoting aidanf at gmail.com, on Fri, Mar 03, 2006 at 12:25:24PM +0000:
> I have never wanted to encode a vcard in multiple versions or multiple
> character sets.
> The idea is that I can sync my phone contacts to my computer, edit them
> there and then sync them back to the phone. This requires the ability to
> save the vcard back in the same format and character set as it was
> originally encoded (Most mobile phones implement vcard2.1, but not 3.0.)

So you don't want transcoding, but you want encoding preserved. Ok,
thats not so hard to do. Much easier than transcoding.

> What encodings are currently supported by vpim? I tested vpim with a couple
> of thousand vcards and 12 failed to decode with Vpim::InvalidEncodingError.

Thats great that you could do that. I would like to see the ones that
failed, I think I support any valid 2.1 vCard, but I could be wrong, or
the card could be technically invalid. Even if they are invalid, I want
vPim to be useful, not righteous, so I would try and make decoding work.

On encoding, I just reemit the fields, in their original forms. The only
things that might cause you problems are new fields that use base64
encoding, and (as you found), that new cards always use version 3.0. I
can add support for encoding version 2.1 cards.

- can you give me examples of cards that fail?
- what kinds of fields do you add?
- what kinds of fields to you delete, if any?
- do you ever modify fields?
- what kinds of character set are these cards encoded in? have you had
	any problems with how vpim treats character sets?
- what php vcard lib did you use? did you like its api?

Btw, The biggest difference between 2.1 and 3.0 is the types of
encodings supported, 3.0 just allows encoding=b (base-64), version 2.1
allows encoding=7bit, 8bit, quoted-printable, and base64.  Unless you
have pictures, certs, or other binary data in your cards, that shouldn't

The other difference is that 2.1 allows params to miss their name, you
can write:


And the decoder is supposed to realize that means


but if you see a raw "base64", the decoder is supposed to realize that
what is meant is encoding=base64. Anyhow, I support this on input, but
don't encode things like that. The fully specified pname=pvalue is
always allowed by 2.1 and 3.0.


More information about the Vpim-talk mailing list