Re: about vcard encoding

Hey, Jianbiao!
Jianbiao Guo написа:

Hi,dealey

Thanks for your replying.In vcard2.1,we can specify the property parameter"CHARSET" equal to "UTF-8",then the vcard reader can know the property value is using UTF-8 .and then the UTF-8 value can be converted into Unicode.You will not lose anything because the UTF-8 is the encoding format of Unicode.In Unicode,almost all the characters using by human are contained.if your platform support Unicode,you can display it directly to the user.In vcard3.0,this property parameter is moved to the mail header.so if you want to use the property parameter in your vcard,I think you'd better compliant to vcard2.1 standard not vcard3.0.

About my question,I want to explain it again as follows:

Because a vcard can describe as a line consisting of three parts:property name(for example ,"N","TEL","ADR")+property parameters(for example ,"ENCODING","CHARSET")+property values.My question is about the property name and property parameters.Because the property name and property parameters is used as a notation,so I think in all vcard,the two parts should be encoded in same character set and encoding so that different platform can communicate seamlessly.But in the formal definition of vcard2.1 and vcard3.0 which is written using the ABNF,I only know that the two parts are defined as terminal values(for example,name = "LOGO"/"PHOTO").I have checked the ABNF specification (RFC 2234).It say that the string using the us-ascii character set and the external encoding is not specified.Then my clear question is that if the two parts in a vcard line can be encoded in different format(for example,ASCII,UNICODE)

vCard would always be in ASCII format, no matter some parts are in Unicode, UTF7, etc. By using Quoted-Printable, Base64, UTF8 the final vCard would be 'ACSII encoded', so you dont have to worry about it. The reason of using all those codecs is to transform the vCard to ASCII symbols only.

or only encoded using ASCII and where can i find the document saying about it.

Thanks

Best Regards

John Guo

2006/5/26, 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

-- 
  Zdravko Stoychev
  System Software and Support
  MPS Ltd.
  zdravko.stoychev@xxxxxx
  +359-2-971-2324 (ext.271)

Ако не отговарям на писмата Ви - погледнете тук: http://6lyokavitza.org/mail

This e-mail is intended only for the addressee(s) and may contain privileged and confidential information. It should not be disseminated, distributed, or copied. If you have received this e-mail message by mistake, please inform the sender, and delete it from your system.