Umlaute aus Textdatei in TStringList

[Christian]

@theo Aber das erledigt sich doch auch sobald der compiler utf8string kennt dann kann er utf8string[x] einfach verbieten. copy,pos,trim & co funktionieren dann aber problemlos genauso wie konstantenzuweisungen oder ? auch stringlist kann eine überladene funktion Add(s : utf8string) haben u.s.w. das wär doch schon ein riesen schritt oder nicht ?
@mschnell glaub du bist den leuten auf der liste einfach mit deinem unicode generve auf den sach gegangen ist ja hier schon nervig gewesen xD
was ist da so viel komplizierter ?

[theo]

@theo Aber das erledigt sich doch auch sobald der compiler utf8string kennt dann kann er utf8string[x] einfach verbieten. copy,pos,trim & co funktionieren dann aber problemlos genauso wie konstantenzuweisungen oder ? auch stringlist kann eine überladene funktion Add(s : utf8string) haben u.s.w. das wär doch schon ein riesen schritt oder nicht ?

Ja, das wäre ein Schritt um überladene Funktionen zu verwenden.
Allerdings muss man sagen, dass das Problem in der reinen "Unicode-Welt" eigentlich auch wieder nicht so gross ist. Man mus sich einfach vom AnsiString verabschieden, so schwer das auch fällt.
Wenn ich mit der Einstellung rangehe dass in meinem Programm alles UTF-8 ist, dann sind die bestehenden AnsiString Funktionen einfach eine Art "low-level" Funktionen (Byte Zugriff).
Ob die eigentlichen UTF-8 Geschichten (eben utf8string[x]) überhaupt in den Compiler gehören ist fraglich.

Was ich eher im Compiler begrüssen würde, wäre ein UCS-4 String / Char.

Jedenfalls ist die "fixe Idee" von mschnell, Unicode so zu verwenden als wäre es ANSI imho einfach nicht vernünftig umzusetzen.

[af0815]

Was ich eher im Compiler begrüssen würde, ...

Ich würde als Benutzer von Lazarus/FPC ganz einfach begrüssen, wenn es schon inkomatible Sachen gibt, das mir die IDE/Compiler ganz einfach ein Warning oder besser Fehler (Inkompatible Typen,...) gibt.

Denn wenn gerade diese 'einfachen' String/Texte' (logische) Probleme machen, so ist das nicht unbedingt als Argument für den Einsatz. Eher ein Killerargument dagegen. Jetzt NICHT aus der Sicht eines Hackers betrachtet, denn der weis ja meistens eh um die Probleme.

Vor allen, was soll man davon halten

Code: Alles auswählen

1:
StringList.Add('Erwin Müller'); // Ist Müller nun UTF8
StringList.SaveToFile('TEST.TXT'); // (Editor: Eine Zeile, Erwin Müller)
StringList.Clear;
StringList.LoadFromFile('TEST.TXT');
ShowMessage(StringList.Strings[0]); // Anzeige leeres Fenster
 
2:
StringList.Add('Erwin Meier');
StringList.SaveToFile('TEST.TXT'); // (Editor: Eine Zeile, Erwin Meier)
StringList.Clear;
StringList.LoadFromFile('TEST.TXT');
ShowMessage(StringList.Strings[0]); // Anzeige Erwin Meier

wenn es schon HIER zu nicht gewünschten Effekten kommt.

[mse]

Jedenfalls ist die "fixe Idee" von mschnell, Unicode so zu verwenden als wäre es ANSI imho einfach nicht vernünftig umzusetzen.

Einspruch.
In der Praxis funktioniert das mit widestring sehr wohl. Meine Anwender aus der ganzen Welt inklusive China tun die seit Jahren mit Erfolg. Ich selbst arbeite so, seit Borland die widestring eingführt hat und das ist schon bald zehn Jahre her.

[theo]

Einspruch.
In der Praxis funktioniert das mit widestring sehr wohl. Meine Anwender aus der ganzen Welt inklusive China tun die seit Jahren mit Erfolg. Ich selbst arbeite so, seit Borland die widestring eingführt hat und das ist schon bald zehn Jahre her.

Darüber hatten wir schon oft gesprochen.
Es mag für eine bestimmte Anwendung reichen, einige Unicode "Facts" zu ignorieren.
Ein Compiler, eine Toolchain darf das imho nicht tun.

[mse]

Ein Compiler, eine Toolchain darf das imho nicht tun.

Auch darüber haben wir schon öfters gesprochen. FPC pos, copy, setlength usw. funktionieren ohne Einschränkungen mit Unicode widestrings.

[theo]

wenn es schon HIER zu nicht gewünschten Effekten kommt.

Früher konnte ich unter GTK1 gar keine Umlaute in den Text schreiben.
War das besser?

Es ist schon klar, dass es Verwirrung gibt. Aber was soll man machen?

[mschnell]

UTF-8 oder UTF-16 ist da nur ein marginaler Aspekt.

Stimmt zwar technisch, nicht aber in der Praxis. Für Europäische und Amerikanische Sprachen gibt es bei UTF16 keine "pairs", jedes Zeichen ist also 16 Bit. Demzufolge ist _hier_ bei einem UTF16 String Typ s der i-te Unicode-Character (genau wie bei ANSI-Codierung). Bei UTF8 eben nicht: schon ein simples ä besteht aus zwei Bytes (Code-Elements) und bei der momentanen Implementierung ist bei UTF8String dann eben s nicht der i-te Unicode-Character, sondern irgend ein Code-Element.

-Michael

[mschnell]

glaub du bist den leuten auf der liste einfach mit deinem unicode generve auf den sach gegangen ist ja hier schon nervig gewesen xD

Da war ich durchus nicht der einzige

Das Zeug macht in der aktuellen Version beinahe jeden alten Code zunichte. Das ist so nicht akzeptabel.

Kompliziert ist so etwas einfaches wie c:= s; s := copy(s1, 1, length(s2)); oder (vor allem bei WideString) s := 'Hallo Herr Müller";

-Michael

[af0815]

Früher konnte ich unter GTK1 gar keine Umlaute in den Text schreiben.
War das besser?

Wenn du mich so fragst - so gesehen eigentlich ja. Denn wenn es geht, so sollte es funktionieren. Und wenn eine explizierte Umwandlung erzwungen wird. Implizierte Wandlungen, die das Chaos erzeugen sollten nicht möglich sein, oder nur dann wenn ich explizit dem Kompiler sage, ja kompilier das, obwohl es eigenlich zu Problemen führen wird.

[theo]

Stimmt zwar technisch, nicht aber in der Praxis. Für Europäische und Amerikanische Sprachen gibt es bei UTF16 keine "pairs", jedes Zeichen ist also 16 Bit. Demzufolge ist _hier_ bei einem UTF16 String Typ s der i-te Unicode-Character (genau wie bei ANSI-Codierung).

Stimmt nur leider nicht. Was machst du mit Decomposed Characters, Bidi Markers etc pp. ?

[mschnell]

Jedenfalls ist die "fixe Idee" von mschnell, Unicode so zu verwenden als wäre es ANSI imho einfach nicht vernünftig umzusetzen.

Mag sein. Dann müsste man es aber wenigstens mit einer Compiler-Version abschalten können und weiterin den alte ANSIString Typ (als Type String) verwenden können um old-school-Code weiter zu verwenden und Neueinsteiger nicht völlig zu verschrecken ("lerne erstmal Unicode, danach kannst Du 'mal Versuchen ein Lazarus Programm zu machen"). Das wäre mit der momentanen LCL möglich, wenn der Compiler ANSIString und UTF8String unterscheiden könnte und automatisch umwandlen würde.

Das FPC Team hat anscheinend eine neue Unicode Implementierung in der Mache wo ein String dynamisch eine Codierung bekommt und die Umwandlungsroutinen somit wissen, was sie tun sollen. Ich hoffe das wird nicht zu langsam, da der Typ dann ja bei geder Operation gecheckt werden muss.

-Michael

[mschnell]

Es mag für eine bestimmte Anwendung reichen, einige Unicode "Facts" zu ignorieren.

Außer, wenn man z.B. ein Programm für ein alt-Ägyptisches Wörterbuch schreibt...

Ein Compiler, eine Toolchain darf das imho nicht tun.

Soll er auch nicht. Es liegt im Ermessen des Anwenders ob er Unicode-Codepoints zulassen will, die mehr als 16 Bit benötigen. Wenn er das wirklich tut, muss er bei WideStrings mit denselben Schwierigkeiten rechen wie momentan bei UTF8String alle user außerhalb der USA.

-Michael

[mschnell]

Es ist schon klar, dass es Verwirrung gibt. Aber was soll man machen?

WideStrings verwenden. Dann ist alles ganz einfach (außer Alt-Ägyptisch ). Leider wird das durch Lazarus verhindert (Ich sehe durchaus dass es dafür nachvollziehbare Gründe gibt, aber wenn das so ist sollte man bei der LCL beide Optionen "UTF8" und "WideString" haben.)

-Michael

[mschnell]

Stimmt nur leider nicht. Was machst du mit Decomposed Characters, Bidi Markers etc pp. ?

Nicht verwenden, genauso wie alt-Ägyptisch .
-Michael