Bjørnar Nielsen wrote:
>> 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.
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