On Friday 26 September 2008 12.30:27 Marco van de Voort wrote:
In our previous episode, Martin Schreiber said:
Hmm, you should ask the Russian users for example if they prefer MSEgui
utf-16 internal encoding or Lazarus utf-8.
Users always look short term, and want to change as little as possible.
This goes both for UTF-16 (with the is UCS2 approximation and keep the
old ways of string indexing) as for UTF-8 (as superset of ansi, avoidance
of multiple file types (no endianess)).
Note that e.g. source ocde seems to go en masse in the direction of UTF-8
(Even Tiburon, which works exclusively on Windows, an UTF-16 platform,
saves source default to UTF8 afaik).
As does MSEide, source code is stored in the current locale encoding or utf-8,
the latter is preferred. MSEgui stores ini files and the like in utf-8, the
form definition files (*.mfm, the MSEgui equivalent of Delphi *.dfm) are pure
ASCII.
For DB access MSEgui converts from utf-8 or the current locale encoding to
utf-16 while fetching the data from server and converts back to utf-8 or the
locale encoding before writing data to the server. There is a switch in the
connection and dataset components to select either utf-8 or the locale
encoding. Strings in the dataset buffer are stored as variable length utf-16
strings.
All this can be done with the currently available standard FPC 2.2.2
widestring facilities. I have no problem if the FPC RTL supports the system
encoding only, MSEgui has the commonly used interface to the filesystem and
other services with widestring parameters. If something is missing, it can be
added to the MSEgui library.
But for internal character encoding where the users must work with, utf-16 is
better suited than utf-8, I am happy that FPC will support a reference
counted widestring type in Windows in future releases.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
