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
Visit our website at

Reply via email to