Re: about vcard encoding

["S. Isaac Dealey" <info@xxxxxxxxxx>]

> Hi,all
>   I am writing a lib about parsing a vcard into one
>   class.and I want to know
> if the property name and property parameters must be
> encoded in US-ASCII .If
> the format is not standard,different platform will can not
> communicate with
> each other.

Clarification of this would be helpful for me also. I've been reading
the RFC's and my understanding is that the file must be 7-bit ASCII
which means anything that's not ASCII needs to be represented with an
ASCII encoding. The property names shouldn't be an issue, because
they're all part of the standard and therefore all ASCII, but property
values may contain other types of characters.

Certainly it would make sense for someone who speaks only non-latin
languages to be able to include non-latin notes in their vCard.

The specification for vCard 2.1 included two forms of encoding which
are described specifically for solving the problem of binary
(graphics, sounds) and multi-line content (a postal address with line
breaks for exmaple) and I assume both of these methods also address
the problem of non-latin characters, being the existing standards of
Quoted-Printable and Base64 encoding (which is specifically a text
representation of binary data).

The specification for vCard version 3.0 no longer supports the
Quoted-Printable encoding, requiring all content to be Base64 encoded
(although RFC2426 unfortunately never mentions Base64 encoding,
instead referring only to "B" as the designation for brinary encoding,
without specifying that it must be Base64 encoded and neither the
vCard 2.1 specification or the RFCs for 3.0 mention the RFCs for the
encoding - 1421 & 2045 - found those on Wikipedia).

So the question I have (and this may be a "clueless newbie" question)
is how would an application receiving a vCard for import know that
Base64 encoded data is intended to be UTF8 containing non-latin
characters?


s. isaac dealey     434.293.6201
new epoch : isn't it time for a change?

add features without fixtures with
the onTap open source framework

http://www.fusiontap.com
http://coldfusion.sys-con.com/author/4806Dealey.htm