Hi,

In order to write cross platform programs, shall I use ForceDirectories or ForceDirectoriesUTF8? I would like to:

- Use native charset on the platform (i.e. UTF8 on Linux and whatever codepage on Windows)
- Avoid using AnsiString or the like (as all my programs use string type, change them all to AnsiString is scaring and I don't know the consequence at all).

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130302/08627e0c/attachment-0001.html>

Xiangrong Fang wrote

* Avoid using AnsiString or the like (as all my programs use string type, change them all to AnsiString is scaring and I don't know the consequence at all).

Are your programs compiled in either {$mode Delphi} or {$mode ObjFPC}{$H+}? If so then "String" = "AnsiString" already... (otherwise String is equivalent to ShortString)

Regards,
Sven

My program is always in {$mode objfpc} So string is not a problem, but shall I use the UTF8 version or not? I remember that Windows is NOT UTF8?

2013/3/2 Sven Barth

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130302/537c2659/attachment.html>

as all my programs use string type, change them all to AnsiString is

scaring and I don't know the consequence at all

Do you access the string's internal structure? Do you write the string to file directly instead of taking its content? If not, then nothing you have to worry about. Standard string operations work the same for all string type.

My program is always in {$mode objfpc} So string is not a problem, but shall I use the UTF8 version or not? I remember that Windows is NOT UTF8?

Windows supports wide characters, I don't know the encoding but it's likely UTF-8 is at least in the subset. I suggest using UTF8 all the time. 1: You don't have to worry about it if in the future you need to support UTF-8 characters
2: It does not hurt your current program

Xiangrong Fang wrote

In order to write cross platform programs, shall I use ForceDirectories or ForceDirectoriesUTF8? I would like to:

I would think that that depends on where you get the value for ForceDirectories(UTF8) from.
If this vale is obtained from any widget (OpenDialog, TEdit, etc.) the encoding of the value is in UTF-8.
If however you get the value as a commandline parameter, then it is in system-encoding if you use ParamStr(), but in UTF-8 if you use ParamStrUTF8().

So you would use:

Path := ParamStr(1);
ForceDirectories(Path);

or

Path := SelectDirectoryDialog1.FileName;
ForceDirectoriesUtf8(Path);

You need to be sure which encoding a string has when you pass it on to such procedures/functions.

Bart

That's what I guessed, so Instead of using UTF8 version I would use this to ensure cross platform correctness:

Path := SelectDirectoryDialog1.FileName;
ForceDirectories(UTF8Decode(Path));

Right? Yesterday I found in this post (which triggered me to ask the question initially):

http://lists.lazarus.freepascal.org/pipermail/lazarus/2012-April/073170.html

Such problems may (should) go away with the new Unicode- and AnsiString types, where AnsiString contains an Encoding field. Then the conversion between UTF-8 and the system codepage are done automatically, whenever required, and the xyUTF8 functions can be dropped then.

If so, we shall avoid using **UTF8 /3/3 Bart

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130303/0385d72d/attachment.html>

Yes, but it is a long way till all functions and methods are adapted.

If so, we shall avoid using **UTF8 your program has to work now or with older compilers/libraries you

have to use the *UTF8 functions.

Mattias

If your program has to work now or with older compilers/libraries you have to use the *UTF8 functions. But the problem is, my program works on both Linux and Windows 7 using

ForceDirectories (NOT the UTF8 version), and btw, I am running Chinese Version of Windows 7.

Could you please tell me what error could happen if I do not use the UTF8 version?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130303/911d235e/attachment.html>

For example:
ForceDirectories(SelectDirectoryDialog1.Filename);

SelectDirectoryDialog1.Filename is an UTF-8 string, while ForceDirectories expects system encoding, which might be an 8-bit windows codepage. It fails on any non ASCII character.

ForceDirectories(UTF8Decode(SelectDirectoryDialog1.Filename)); UTF8Decode converts to widestring, which is then converted to string in system encoding. It fails on any character not in the system codepage, including invalid UTF-8 characters.

ForceDirectoriesUTF8 is smarter, as it omits unneeded conversions on UTF-8 systems and thus supports invalid UTF-8 characters and it uses the *W functions under Windows.

Mattias

I have had the same problem with all the different string encodings arround:

Windows API-function can have ANSI or UTF16 encoding. FPC-RTL file functions are restricted to 255 characters (so only ANSI file names are possible). Linux seems to have UTF8.
The LCL is UTF8 and the IDE can have different encodings (UTF8 as default).

So I see no way to avoid the hassle to learn all the string encodings of all libraries you use.

I am now trying to use UTF8 encoded strings in my programs as much as possible. The LCL expects this encoding and I can have it in the IDE editor too (so no conversion is needed for constant strings). Then I wrote procedures/functions for all cases where a conversion is needed which take UTF8 strings as parameters and convert them to UFT16 or ANSI internally if needed. Also, when reading file names on Windows I capsulate this in a procedure, use UTF16 API functions if possible (to avoid the 255 characters limit) and convert them to UTF8 immediately.
So the conversion part is isolated in these small routines and the overall general encoding stays UTF8. UTF8 is a good compromise because it's not so memory waisting as UTF16 is.