Re: about vcard encoding
Zdravko Stoychev <[email protected]> Fri, 26 May 2006 09:15:46 +0300
| Newsgroups | gmane.ietf.vcard |
|---|---|
| Organization | MPS Ltd |
| Message-ID | <[email protected]> |
This is a cryptographically signed message in MIME format. --------------ms040000020701060407070707 Content-Type: multipart/alternative; boundary="------------090907070301070606000503" This is a multi-part message in MIME format. --------------090907070301070606000503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 <[email protected] <mailto:[email protected]>>: > > > > 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 > <http://coldfusion.sys-con.com/author/4806Dealey.htm> > > -- Zdravko Stoychev System Software and Support MPS Ltd. [email protected] +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. --------------090907070301070606000503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000066"> Hey, Jianbiao!<br> Jianbiao Guo написа: <blockquote cite="[email protected]" type="cite"> <div>Hi,dealey </div> <div> 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.</div> <div> About my question,I want to explain it again as follows:</div> <div> 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) </div> </blockquote> 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.<br> <blockquote cite="[email protected]" type="cite"> <div>or only encoded using ASCII and where can i find the document saying about it.</div> <div> </div> <div> Thanks </div> <div>Best Regards</div> <div> </div> <div>John Guo <br> <br> </div> <div><span class="gmail_quote">2006/5/26, S. Isaac Dealey <<a href="mailto:[email protected]">[email protected]</a>>:</span> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;"><br> > Hi,all<br> > I am writing a lib about parsing a vcard into one<br> > class.and I want to know <br> > if the property name and property parameters must be<br> > encoded in US-ASCII .If<br> > the format is not standard,different platform will can not<br> > communicate with<br> > each other.<br> <br> Clarification of this would be helpful for me also. I've been reading <br> the RFC's and my understanding is that the file must be 7-bit ASCII<br> which means anything that's not ASCII needs to be represented with an<br> ASCII encoding. The property names shouldn't be an issue, because<br> they're all part of the standard and therefore all ASCII, but property <br> values may contain other types of characters.<br> <br> Certainly it would make sense for someone who speaks only non-latin<br> languages to be able to include non-latin notes in their vCard.<br> <br> The specification for vCard 2.1 included two forms of encoding which<br> are described specifically for solving the problem of binary<br> (graphics, sounds) and multi-line content (a postal address with line<br> breaks for exmaple) and I assume both of these methods also address <br> the problem of non-latin characters, being the existing standards of<br> Quoted-Printable and Base64 encoding (which is specifically a text<br> representation of binary data).<br> <br> The specification for vCard version 3.0 no longer supports the<br> Quoted-Printable encoding, requiring all content to be Base64 encoded<br> (although RFC2426 unfortunately never mentions Base64 encoding,<br> instead referring only to "B" as the designation for brinary encoding, <br> without specifying that it must be Base64 encoded and neither the<br> vCard 2.1 specification or the RFCs for 3.0 mention the RFCs for the<br> encoding - 1421 & 2045 - found those on Wikipedia).<br> <br> So the question I have (and this may be a "clueless newbie" question) <br> is how would an application receiving a vCard for import know that<br> Base64 encoded data is intended to be UTF8 containing non-latin<br> characters?<br> <br> <br> s. isaac dealey 434.293.6201<br> new epoch : isn't it time for a change? <br> <br> add features without fixtures with<br> the onTap open source framework<br> <br> <a href="http://www.fusiontap.com">http://www.fusiontap.com</a><br> <a href="http://coldfusion.sys-con.com/author/4806Dealey.htm">http://coldfusion.sys-con.com/author/4806Dealey.htm </a><br> <br> </blockquote> </div> <br> </blockquote> <br> <br> <pre class="moz-signature" cols="72">-- Zdravko Stoychev System Software and Support MPS Ltd. <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> +359-2-971-2324 (ext.271) Ако не отговарям на писмата Ви - погледнете тук: <a class="moz-txt-link-freetext" href="http://6lyokavitza.org/mail">http://6lyokavitza.org/mail</a> 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. </pre> </body> </html> --------------090907070301070606000503-- --------------ms040000020701060407070707 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIH+TCC AlcwggHAoAMCAQICAw/0sTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUxMjAxMDg0NjMyWhcNMDYxMjAxMDg0NjMy WjBJMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSYwJAYJKoZIhvcNAQkBFhd6 ZHJhdmtvLnN0b3ljaGV2QG1wcy5iZzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEArZcr L4in2p3eAec/AEcteuirEEeA7jU3c5M/sSv1zKTOANwixM9XIIaH/D2Yk2OK3hyx3uVIyeuu BTD0wfQmZthxStKyrm15nTjhbazHqEHi/o/TyaiJS8XxlfkSLQgpMFBgYLfXcLZnmHjdKxvh R3B2wsEDi+VQdOiqagGIYcUCAwEAAaM0MDIwIgYDVR0RBBswGYEXemRyYXZrby5zdG95Y2hl dkBtcHMuYmcwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAR7cuxU8HzNyM/qO/6 6T2QkZ85fD29UHOtfQibxlIHZvTbrMMz42PL8biafaFOU33ikbHU1oyqH5Qia8NxeHtel9iJ QC5fswSX8PHC/SMrCyDSHzuhly2hagASrFbIeSLkMBb7DrrlC5Bntjs4V1PMQeL2JyFJCnrf AiUZsaboezCCAlcwggHAoAMCAQICAw/0sTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUxMjAxMDg0NjMyWhcNMDYx MjAxMDg0NjMyWjBJMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSYwJAYJKoZI hvcNAQkBFhd6ZHJhdmtvLnN0b3ljaGV2QG1wcy5iZzCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEArZcrL4in2p3eAec/AEcteuirEEeA7jU3c5M/sSv1zKTOANwixM9XIIaH/D2Yk2OK 3hyx3uVIyeuuBTD0wfQmZthxStKyrm15nTjhbazHqEHi/o/TyaiJS8XxlfkSLQgpMFBgYLfX cLZnmHjdKxvhR3B2wsEDi+VQdOiqagGIYcUCAwEAAaM0MDIwIgYDVR0RBBswGYEXemRyYXZr by5zdG95Y2hldkBtcHMuYmcwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAR7cux U8HzNyM/qO/66T2QkZ85fD29UHOtfQibxlIHZvTbrMMz42PL8biafaFOU33ikbHU1oyqH5Qi a8NxeHtel9iJQC5fswSX8PHC/SMrCyDSHzuhly2hagASrFbIeSLkMBb7DrrlC5Bntjs4V1PM QeL2JyFJCnrfAiUZsaboezCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEa MBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vy dmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcw MDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FW y688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEE QB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2 oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9l X5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggK6MIICtgIBATBp MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDD/SxMAkG BSsOAwIaBQCgggGnMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA2MDUyNjA2MTU0NlowIwYJKoZIhvcNAQkEMRYEFH8tzd8tk6RHqTtEjJCCH/yBiW8kMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMP9LEwegYLKoZIhvcNAQkQ Agsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQID D/SxMA0GCSqGSIb3DQEBAQUABIGABZbdaaU5W1jG1/YrrZcaq51UW2w7imjKFeH+E1GitGE9 lXqjX03qUVpZW/CSdc1O/Gd/1BuSJ2zbHZZPg/m8zVODpBPEanGmrBvW74Z+ir0XIvb4/9Zr q+IHx7lIyD+mwP/Gt1gb8EHOm+rfCe/2PJbUUjEvq5kGPy3OJGcPaQUAAAAAAAA= --------------ms040000020701060407070707--