On 8 Sep 2013, at 23:30, Pirmin Braun <[email protected]> wrote: > Am Sun, 8 Sep 2013 21:36:31 +0100 > schrieb Richard Frith-Macdonald <[email protected]> : > >> I would have thought the correct fix would be for the calling application to >> use the existing methods to set the mime parser to be expecting http and/or >> a different characterset, since this application should know the context >> (ie what is being parsed and what form the browser has been told to upload >> the data in). >> >> >> > > the application using GSMime is the webserver-Library; in > WebServerConnection.m it says: > parser = [GSMimeParser new]; > [parser setIsHttp]; > so GSMimeParser will try NSISOLatin1StringEncoding, which obviously fails. > Since _defaultEncoding is left unchanged at NSASCIIStringEncoding, no further > attempts are made and it ends up with the NSLog(@"Bad header ... illegal > characters in %@" > > so I thought, lets try all encodings. I think, the header is encoded in > UTF-8. But will look at it with gdb now to be sure.
Sounds like there is something else going on ... if we are tryihng latin1 the character conversion should never fail: since latin1 is an 8bit characterset with all 256 available codepoints used, any data should represent a valid string, so I guess the error message must be about something other than the encoding. _______________________________________________ Bug-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-gnustep
