Bjørnar Nielsen wrote: > Arno, > >> Would you expect a correct result as well if you base64-decoded a >> quoted-printable encoded string? > > No, I agree. But the problem is not the decoding itself but the way > Unicode-chars and Ansi-chars are treated. > This is the line where the problem lies: > MyAnsichar := AnsiChar(UnicodeUrl[I]);
Yes, it expects a Char containing a 7-bit printable ASCII character. > If UnicodeUrl is switched to AnsiString, the problem disappears. This would introduce plenty of implicit string casts in existing Delphi code because in Delphi an ICS-URL is of type "string", only the mapping of "string" changed in D2009+ from AnsiString to UnicodeString. This is different in C++ Builder where generated .hpp files export the mapped types (AnsiString and UnicodeString explicitly). Note that such introduced string casts would corrupt invalid URLs *as well*. >> Can't you use your own custom function then? > > Yes I can, but I think other users could benefit from my proposed > change. I think this is a problem that was introduced with porting to > Builder 2010 and using UnicodeString. This problem was not there > before and maybe other users also have this problem now without > knowing it. > > Why not make the changes I proposed when all it does is restoring the > function to old behavior as when only AnsiString was used? The only workaround that comes to my mind was another overload that takes a RawByteString instead of string. I won't use AnsiString because implicit ansi string casts must be avoided too. -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
