Peter Vreman wrote:
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.
http://www.microsoft.com/globaldev/reference/WinCP.mspx
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 encoding.
i've created a page on the wiki for this issue at http://www.freepascal.org/wiki/index.php/Widestrings
You are welcome to supply patches that fixes the prototypes and new units that support more encoding/decoding routines.
I think we should introduce a class widestringmanager :) Lower, upper, comparing etc. needs also to take care of unicode encodings.
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
