After further investigation I made a small pop3 server emulator that sends
all character codes except 0x00, 0x0A and 0x0D which should not be in
message anyway.

Even though the LastResponse unicode looks a bit odd in debugger, after
doing a SslPop3Cli->LastResponse.c_str(); and
SslPop3Cli->LastResponse.t_str(); and assigning it to some single-byte
string type like AnsiString the characters are back to original byte-codes.
c_str return wchar_t pointer which is probably converted into single-byte
string and t_str returns char_t pointer is for compatibility purposes for
getting raw data (I read somewhere that it may be dangerous to use because
of the conversions and mangling it could do but obviously it does the same
thing in this case like c_str); I don't know how Delphi equvalent for c_str
and t_str are named.

So I guess that UnicodeString somehow preserves or converts raw bytes
properly back to AnsiString and no further help is necessary I guess, unless
of course someone wants to comment on this to add some useful additional
info or if I figured it out totally wrong :)

Also after reading a bit of RFC's char codes above 127 should not be in
email anyway but should be encoded/quoted/whatever but it should be handled
when reading it, thanks to other email programs that may use it.
To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at

Reply via email to