With Delphi, TStringList seems to be hard coded to use UTF16 with "Add"
and StringList[i] (which is a really bad idea in a String system
providing versatile encoding). TStringList.LoadFromFile seems do default
to the system ANSI encoding (which seems like rather contra-intuitive in
a system that defaults to coding strings as UTF16).
With Lazarus, TStringList seems to be (considered to be, as
StrinCodePage(SomeString ) is 65001) hard coded to use UTF8 with "Add"
and StringList[i] (which is a bad idea, as well, but not worse than
Delphi forcing UTF16) TStringList.LoadFromFile uses (defaults to) "no
conversion" which in fact means UTF8 encoding (which in fact is straight
forward and obvious, and hence better than Delphi).
I don't see why a redesign of the "hard coded UF8" TStringList would be
necessary just for setting the code of the file to be loaded by
TStringList.LoadFromFile, just a settable conversion at that function
(and the at SaveToFile) would be helpful. Of course a versatile encoding
of TStrings would be a much better way to go, but I don't suppose this
ever will happen (partly because Delphi does not feature his either).
The current makeup results in different behavior between Delphi and
Lazarus.
I was hit by this when doing a (Windows) program that analysis text
files that are generated in local (German) ANSI code.
To load a text file, the most convenient function to me seems to be
TStringList.LoadFromFile and here (with the current official Windows
distribution of Lazarus) the output of myString := StringList[i]
obviously is wrong.
Test: Speed
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus-ide.org/listinfo/lazarus
