[fpc-devel] Unicode support - for the 20th time... ;-)
daniel.mantione at freepascal.org
Thu Nov 20 11:12:41 CET 2008
Op Thu, 20 Nov 2008, schreef Graeme Geldenhuys:
> On Thu, Nov 20, 2008 at 11:37 AM, Florian Klaempfl
> <florian at freepascal.org> wrote:
>> FPC supports Unicode, in 2.3.x is the UnicodeString type available being a
>> ref. counted utf-16 string on all platforms.
> OK, I'll try to switch fpGUI's TfpgString type to alias UnicodeString
> an see what happens. Obviously this will be done in a separate branch,
> not to screw with Trunk.
> So where can I find out what has been implemented and what is missing?
> Some or other roadmap, like Lazarus has for it's LCL.
> Does 2.3.x with UnicodeString support the following (off the top of my head).
> * TStringList.LoadFromFile() - what happens if file is UTF-8 encoded
> like under Linux.
The file is assumed to be in system encoding (which can be UTF-8). Support
for reading of other encodings has not been decided on about yet and is
not part of the initial plan.
> * Does it support > 1byte Locale variables for Currency Delimiter,
> etc.. Russian locale
> requires a >1 byte char.
It can remain a system encoded ansichar for 100% compatibility, or on
selected platforms become a widechar. Conversion to multibyte (utf8) can
in both cases be inferred by the compiler from type information.
> * FindFile, FindFirst? Do they handle Unicode filenames? What about
> other file IO calls.
Win32 widestring platform for sure. Not really decided on non-Unicode
platforms yet, they may remain in the system encoding. Autoconversion will
in such case happen based on type information.
> * Copy, Length, Pos etc...?
> * What about usage like: SomeString[x] := 'A';
String element based.
> * What if we call external API's with string parameters? XLib,
> OpenGL, Win32 etc?
Auto-conversion based on type information.
> * Does UnicodeString work on all platforms? Linux, Windows for a start?
Yes, but all platforms will get string=unicodestring.
More information about the fpc-devel