[fpc-devel] ansistrings and widestrings
clootie at ixbt.com
Thu Jan 6 00:00:21 CET 2005
Firstly: I agree that Wide2AnsiMoveProc and Ansi2WideMoveProc should take size
of resulting string.
Next: I was wrong about ansistrings - on Windows their are (PCHAR's) used (until
WinNT arrived) in far east localized versions coupled with multibyte encoding.
So currenltly for legacy applications multibyte encoded character sets are
supported in any WinNT box.
PS. I hope mine patch (bug 3451) extending Widestring support in compiler will
finally be applied to CVS and we can proceed with RTL modifications to support
more extended ansi to wide strings conversions. ;-)
PPS. AFAIK UTF-8 is not used internally in any OS - it's only used for storing
UNICODE text in more compact form - web site authors really like it.
----- Original Message -----
From: "peter green" <plugwash at bircd.org>
To: "FPC developers' list" <fpc-devel at lists.freepascal.org>
Sent: Thursday, January 06, 2005 12:19 AM
Subject: RE: [fpc-devel] ansistrings and widestrings
> in wondows terminology (which i presume is where the name ansistring comes
> from) the windows code page which is often refered to in documentation as
> the ansi code page CAN be multi byte.
> more generally i belive an ansistring is usually intended to represent text
> in the platforms local encoding. Whilst a widestring is meant to represent
> text in utf-16.
> The platforms local encoding may be a single byte encodeing (iso-8859-?
> windows-125? etc) it may be a legacy mixed width encoding (EUC-?? SHIFT-JIS
> BIG5 etc) or it may be a unicode transformation format which is a superset
> of ascii (utf-8).
> now for dependency reasons i belive that the default conversion functions
> should remain a "dumb fallback" BUT i also belive that the function
> prototypes should be designed in such a way as to allow the conversion
> routines to be replaced with ones that can sesiblly handle the local
> i've created a page on the wiki for this issue at
More information about the fpc-devel