> However, as long as this codepage was one of the windows-xyz,
> single byte character sets converting back to Ansi with the
> same codepage should work without data loss and give you back
> the raw bytes (hopefully). This won't work, for example, with
> Japanese locale settings.

But there is a string type for that purpose. It is called
RawByteString. It is defined as AnsiString($ffff) which in effect
means it is an ansistring with no encoding attached to it so you can
use it to transfer data from functions and avoid codepage conversions.

Yes, by default it uses default system code page for conversions to Unicode.

RawByteString is a single-byte character type but unlike AnsiString it
does not have a specific encoding attached to it. So that means it can
be used to pass values to and from functions that will do
UnicodeConversions. It is not indended to be used for storing data,
just mostly for input/output of functions as the official
documentation specify.

So my best bet is that it would be the best to receive raw byte buffer
(unsigned char or BYTE type) and then place it into RawByteString and
return that value. This should avoid conversions.

In your own functions you can cast RawByteString as input type and use
conversion functions to convert from RawByteString to any codepage you
like (or store it as binary data). There are some functions that do
this I think the ones you need are SetCodePage() and StringCodePage().

Other than that, AnsiString can be defined in various codepages for
example you can declare a
typedef AnsiStringT<28591> Latin1String; and store data in
Latin1String type - this will ensure that the codepage conversions are
always in identical codepage and not dependent on the system code
page.But I think RawByteString is better for this purpose.

Both AnsiString and RawByteString are single-byte types unlike
UnicodeString, UTF8String and others which are multi-byte.

Take a look here:

> Note that in MIME headers 8-bit characters are not allowed!
> Email clients must encode 8-bit characters in header lines
> properly. MIME text parts might include 8-bit characters with
> a charset specified in the content-type header, in those cases
> the (AnsiString) text content has to be converted to Unicode
> with the charset specified.

Yes, no 8-bit in header but you still have to receive that buffer and
as far as I know there is no way to get the buffer contents directly
at the moment.
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

Reply via email to