discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Addresses not importing vcards files


From: Richard Frith-Macdonald
Subject: Re: Addresses not importing vcards files
Date: Tue, 10 Sep 2013 14:39:49 +0100

On 10 Sep 2013, at 14:22, "Sebastian Reitenbach" 
<sebastia@l00-bugdead-prods.de> wrote:

> 
> On Tuesday, September 10, 2013 15:12 CEST, Richard Frith-Macdonald 
> <richardfrithmacdonald@gmail.com> wrote: 
> 
>> 
>> On 10 Sep 2013, at 10:22, Sebastian Reitenbach 
>> <sebastia@l00-bugdead-prods.de> wrote:
>> 
>>> 
>>> On Sunday, September 8, 2013 14:42 CEST, Philippe Roussel 
>>> <p.o.roussel@free.fr> wrote: 
>>> 
>>>> Hi Sebastian,
>>>> 
>>>> On Sun, Sep 08, 2013 at 02:27:56PM +0200, Sebastian Reitenbach wrote:
>>>>> Hi,
>>>>> 
>>>>> while testing Addresses for a new release, I figured there are a couple 
>>>>> of problems.
>>>>> Riccardo suggested to forward them here, I'll separate them in different 
>>>>> threads.
>>>>> 
>>>>> First problem is that Addresses is unable for me to import vcards, even 
>>>>> vcards 
>>>>> it successfully exported.
>>>>> 
>>>>> I found that in Addresses/Frameworks/Addresses/ADConverter.m in 
>>>>> - (id<ADInputConverting>) inputConverterWithFile: (NSString*) filename
>>>>> 
>>>>> http://cvs.savannah.gnu.org/viewvc/gap/system-apps/Addresses/Frameworks/Addresses/ADConverter.m?revision=1.4&root=gap&view=markup
>>>>> 
>>>>> 
>>>>> its detecting the type of encoding of the file wrongly. With the patch 
>>>>> attached,
>>>>> it works for me. That moves the detection of ASCII encoding before UTF8 
>>>>> encoding.
>>>>> 
>>>>> Without the patch it would detect UTF-8 all the time, and then fail 
>>>>> parsing the vcard.
>>>>> On the other hand, I could just move the UTF-8 detection to the end.
>>>> 
>>>> I'm probably missing something here but shouldn't utf-8 works for
>>>> plain ascii files ?
>>> 
>>> I would have expected that too, but that didn't seemed to be the case.
>>> When it was parsing the vcard, addresses was telling me that it didn't 
>>> found a vcard 
>>> in the file. I set a breakpoint into the function where its doing the 
>>> parsing,
>>> and its looking for the colon in: BEGIN:VCARD
>>> 
>>> But it cannot find the :, printing out the string examining it, I see only 
>>> some garbage,
>>> but no readable string.
>>> With the patch I had attached, I moved the detection of ASCII before UTF8,
>>> then it happily detected the colon, and imported the vcard.
>>> 
>>> Sebastian
>> 
>> The patch can't possibly be correct because, as Philippe pointed out, if a 
>> vcard is valid ascii then it *must* also be valid utf-8.
>> 
>> The only ways I can think of that the patch could 'fix' things for a 
>> particular vcard would be:
>> a. there's a memory or unintialised variable bug somewhere and changing the 
>> code layout stops the bug manifesting ion this case or
>> b. there's a bug in the ascii string checking such that it is creating a 
>> string successfully even though the data is not valid ascii
>> c. some other bug the patch somehow hides
>> 
>> Could you possibly post the actual vcard so I could try looking at it under 
>> gdb.
>> 
> 
> I created a test user in Addresses, and exported that one into a vcard, then 
> tried to import 
> it again in Addresses, and it failed with following message:
> 
> $AddressManager                                                       
> 2013-09-10 15:20:11.210 AddressManager[4391] File in NSUnicodeStringEncoding
> 2013-09-10 15:20:11.278 AddressManager[4391] Syntax error in line 0!
> 
> The Syntax error in line 0 is because it cannot find the colon in 
> <BEGIN:VCARD>
> tag.
> 
> Does that import/export work for you?

I haven't tried ... will do.
But
> File in NSUnicodeStringEncoding
it's not utf-8 as stated in the earlier email, it's in the 16bit unicode.
So I guess the problem is that the data happens to be valid 16bit unicode text, 
so the code is then trying to parse that (and of course failing).

This then, is a problem with the algorithm used by ADConverter to recognise the 
chjaracter encoding ... simply trying each encoding in turn to see if the data 
produces a string is not a reliable mechanism.

A 100% reliable fix is not possible, but a near-100% solution would be to try 
to convert the data to a string AND check that the resulting string (if any) 
starts with 'BEGIN:VCARD'





reply via email to

[Prev in Thread] Current Thread [Next in Thread]