2011/1/2 Vladimir Zhirov <[email protected]>: > cobines wrote: >> Those only work for characters in current Ansi code page. > > Yes, on Win32. They also work properly for utf-8 characters > on Linux and Mac OS X. > >> It is better to use UTF8Decode, UTF8Encode. > > UTF8Decode and UTF8Encode do not provide any platform abstraction, > they merely convert single-byte utf-8 string to double-byte > utf-16/usc-2 string. > > And since RTL/FCL functions on Win32 use single-byte Ansi strings, > they cannot handle characters outside of current code page anyway. > I do not see how UTF8Decode/UTF8Encode can help here. > The only way is to use them in combination with wide version > of Windows API (functions ending with "W"), but it is not portable. > > To make it clear, when I called Utf8ToSys/SysToUtf8 "general purpose" > I did not mean they should be used all over the code. They are only > needed when calling RTL/FCL functions if there is no appropriate > wrapper function like FileExistsUtf8.
Yes, I was thinking of Win32. What I wanted to say was that it's not simply a matter of adding UTF8ToSys call: FileExists(UTF8ToSys(FileName)). It might work on Linux, but won't always work on Win32. As you said, either do FileExistsUtf8, or directly use unicode OS API, like on Windows: Windows.FindFirstFileW(UTF8Decode(FileName)) -- cobines -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
