Re: Addresses not importing vcards files

[Sebastian Reitenbach]

On Tuesday, September 10, 2013 15:39 CEST, Richard Frith-Macdonald 
<richardfrithmacdonald@gmail.com> wrote: 
 
> 
> 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).

sorry, my fault messing up unicode with utf-8 :(

> 
> 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'

OK, so the current process is kind of flawed. Thanks for the suggestion, 
definitely will look into that one, sounds easy enough that it will just work.

cheers,
Sebastian

> 
>