On Tuesday, September 10, 2013 15:39 CEST, Richard Frith-Macdonald <[email protected]> wrote: > > On 10 Sep 2013, at 14:22, "Sebastian Reitenbach" > <[email protected]> wrote: > > > > > On Tuesday, September 10, 2013 15:12 CEST, Richard Frith-Macdonald > > <[email protected]> wrote: > > > >> > >> On 10 Sep 2013, at 10:22, Sebastian Reitenbach > >> <[email protected]> wrote: > >> > >>> > >>> On Sunday, September 8, 2013 14:42 CEST, Philippe Roussel > >>> <[email protected]> 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 > > _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
