maemo.org Bugzilla – Bug 5347
address book cannot import vcards from benq/siemens phones properly
Last modified: 2010-01-14 12:27:58 UTC
You need to log in before you can comment on or make changes to this bug.
N900 Maemo 5, 1.2009.41-10 Adressbook fails to import vcards from BenQ/Siemens mobile phone. Drops data from it, chokes on Umlauts. I am attaching a vcard from that phone. I replaced the phone number/surname carefully and made sure that the file otherwise continued to use the charsets/yadda yadda it used before.
Created an attachment (id=1405) [details] incompatible vcard
That N property looks invalid. According to the 2.1 spec (<http://www.imc.org/pdi/vcard-21.txt>): > The default character set is ASCII. The default character set can be overridden > for an individual property value by using the "CHARSET" property parameter.
(In reply to comment #2) > That N property looks invalid. According to the 2.1 spec > (<http://www.imc.org/pdi/vcard-21.txt>): > > > The default character set is ASCII. The default character set can be overridden > for an individual property value by using the "CHARSET" property parameter. > Yes, the vcf seems to be in ISO-8859-1 or so. Maybe instead of insisting that the vcf files be correct the importing should be smart and auto-detect the encoding or using iso-8859-1 as fallback. And even if that should not work out it would still be better if the import would replace the invalid char by some escape code instead of just dropping the entire entry.
(In reply to comment #2) > That N property looks invalid. According to the 2.1 spec > (<http://www.imc.org/pdi/vcard-21.txt>): > > > The default character set is ASCII. The default character set can be overridden > for an individual property value by using the "CHARSET" property parameter. > Like Lennart said: In IOP there is no price given for interpreting specs most strictly. The price is given for reading as many real world cards as possible. Siemens/BENQ sold many of those phones, and their vCard implementation is broken, but users will blame us for getting it wrong.
This has been fixed in package evolution-data-server 1.4.2.1-20091116+0m5 which is part of the internal build version 2.2009.47-17 (Note that 2009 is the year and the number after is the week.) Any public update released with or after this build version will include the fix. Please verify that the new version fixes the bug by marking this bug report as VERIFIED after the public update has been released and if you have some time.
FYI, VCF files from PalmOS devices (in this case a Treo 600; VCF export from on-PC Palm Desktop application version 4.1) suffer from the same flaw (encoded in Latin-1 AKA ISO 8859-1) and that same fix should work for them, too.
The problem reported here should be fixed in the update released today for public: The Maemo5 update version 2.2009.51-1 (also called "PR1.1" sometimes). Please leave a comment if the problem is not fixed for you in this update version.