Umlaute aus Textdatei in TStringList

[Christian]

Wie ich schon erwähnt hab ist die UTF-8 implementierung eher glücklich für mich verlaufen da ich immer das problem hatte das unter Linux die Datenbanken mit UTF-8 gefüllt wurden und unter Windows mit ISO8859 ich hab bis heute in einigen Tabellen noch ein paar ISP8859 Leichen, jedoch sehr wenige. In der Dokumentenveraltung haben sich dadurch ne ganze menge Bugs eingeschlichen jedoch eher beim Dateinamenshandling da hab ich 3 längere Bereinigungsaktionen gebruacht bis die Dokumentenverwaltung nun (hoffentlich) komplett unicodetauglich ist. Aber eigentlich bin ich froh über die Unicodeunterstützung ohne riesen Änderungen als das ich die paar Probleme als problematisch sehe.

[mschnell]

Bspw. das Ursprüngliche Thema, das Inidateien/Stringlisten usw. nicht mehr so wie früher eingelesen werden können, wenn sie nicht UTF-Kodiert sind.

Ja, das ist blöd. Falls das nicht funzt, würde ich es aber als Bug einstufen und nicht unbedingt als grundsätzliches Problem.

Sag ich doch die ganze Zeit Wenn das mit Unicode sich nicht in mit früherer Software (in 99% der Fälle) kompatibler Weise lösen lässt, ist das sinnvolle Vorgehen, dem User die Möglichkeit zu geben, die Unicode-Verarbeitung explizit zu aktivieren. Der Default-Mode sollte der kompatible sein. Momentan ist es aber so, dass es gar keinen Modus gibt in dem das Unicoed-Handling entweder nicht gemacht wird oder (wegen Kompatibilität) nicht auffällt.

Und das ist wirklich blöd (um nicht wieder "nicht akzeptabel" zu sagen, womit dasselbe gemeint ist: es sollte geändert werden .

-Michael

[Christian]

Du quasselst threadweise wies sein sollte, aber was dran ändern tust auch nicht ?!
Fang doch an in allen Widgetsets einen schalter einzubaun der utf-8 abschaltet bzw in den meissten fällen ansi in utf-8 wandelt.

[mschnell]

Fang doch an in allen Widgetsets einen schalter einzubaun der utf-8 abschaltet bzw in den meissten fällen ansi in utf-8 wandelt.

Wer sagt denn, dass das ein sinnvoller Weg ist ? (Wozu in utf8 wandeln ? Hat die frühere Version der LCL auch nicht gemacht.)

Die String Infrastruktur von FPC wird sowieso bald wieder geändert und dann ist das möglicherweise für die Katz. Solange nicht klar ist, was da gemacht wird, hat es kaum Sinn noch weiter an der LCL 'rumzufummeln.

-Michael

[Christian]

Die früheren versionen der LCL hatten auf jedem betriebsystem ein anders Encoding was SEEEHR viel nerviger ist als UTF-8 du scheinst nur unter Windows zu basteln. Auf allen anderen Plattformen (incl Win CE) war das vorher schon utf-8 oder ein mischmasch was nichts richtig unterstützt (gtk). Jetzt ists wenigstens ne linie.

[theo]

Die String Infrastruktur von FPC wird sowieso bald wieder geändert und dann ist das möglicherweise für die Katz. Solange nicht klar ist, was da gemacht wird, hat es kaum Sinn noch weiter an der LCL 'rumzufummeln.

Mag sein.
Aber völlig unqualifiziertes rummäkeln auf allen Foren und Mailinglists und die Devels mit Geschwafel nerven, macht das Sinn?

[mschnell]

du scheinst nur unter Windows zu basteln.

Nö. Wir haben vor kurzem noch ein garnichmal so kleines Programm in Windows entwickelt und dann für Linux übersetzt. Lief sofort ohne jede Änderung.

Auf allen anderen Plattformen (incl Win CE) war das vorher schon utf-8 oder ein mischmasch was nichts richtig unterstützt (gtk).

WinCE habe ich nicht probiert. Will ich auch nicht. Linux auf Atrm wäre für mich ein interessantes Thema, momentan aber nicht akut.

Jetzt ists wenigstens ne linie.

.

-Michael

[mschnell]

Aber völlig unqualifiziertes rummäkeln auf allen Foren und Mailinglists und die Devels mit Geschwafel nerven, macht das Sinn?

Was meinst Du mit unqualifiziert ? Bisher habe ich den Eindruck, dass das meiste, was ich "angemäkelt" habe, nicht auf irgendwelchen Irrtümern beruht, sondern tatsächlich so (schlecht) ist. (Wenn es auch natürlich tatsächlich Gründe dafür gibt, dass es so ist, wie es ist.) Ich stehe absolut nicht allein mit der Meinung, dass es so nicht bleiben sollte und das FPC-Team ist ja auch schon dabei, Änderungen zu definieren. Die Voraussetzung zum Initiieren von Änderungen ist, dass man weiß was verändert werden sollte. Und ich versuche, bei dieser Meinungsfindung mitzuhelfen. Ich habe in fpc-devel auch einen sehr dezidierten Vorschlag unterbreitet, wie es besser funktionieren könnte (der Compiler unterscheidet die verschiedenen Codierung anhand der String-Typen). Ob das wirklich gut ist oder ob ein anderer Vorschlag (z.B. ein dynamischer String Typ, der die jeweilige Codierung seines Inhalts kennt) sich durchsetzt, müssen die "Macher" entscheiden, die (hoffentlich) über den entsprechenden Weitblick verfügen.

Eine intensive öffentliche Diskussion über verschiedene Realisierungsmöglichkeiten bevor ein Projekt in Angriff genommen wird, ist bei großen Entwicklungs-Arbeiten üblich und sinnvoll. Genau dafür sind diese Foren schließlich da.

Ich habe übrigens nur (glaube ich) zwei der mindestens 20 Diskussionen um das Thema selbst begonnen. Alle anderen haben andere begonnen, die mit dem momentanen Zustand zu arbeiten versucht haben, und (erst mal) gescheitert sind.

-Michael

[theo]

Ich habe in fpc-devel auch einen sehr dezidierten Vorschlag unterbreitet, wie es besser funktionieren könnte

Ja genau. Zum Glück hat mir Felipe erspart, das zu kommentieren.
http://www.mail-archive.com/fpc-devel@l ... 12972.html" onclick="window.open(this.href);return false;

[mschnell]

Felipe's kommentar war keine Antwort auf den vorgeschlagenen Lösungsansatz.
-Michael

[Christian]

Felipe hat dein "geschwafel" kommentiert.

Nö. Wir haben vor kurzem noch ein garnichmal so kleines Programm in Windows entwickelt und dann für Linux übersetzt. Lief sofort ohne jede Änderung.

Wenn du bei "euch" auch soviel quatscht und sowenig machst kann das nicht gross gewesen sein. Und mit Unicode hattes anscheinend gar nichts zu tun sonst hättet ihr probleme gehabt.

[mschnell]

Und mit Unicode hattes anscheinend gar nichts zu tun sonst hättet ihr probleme gehabt.

Natürlich nicht. Die ganze Diskussion geht ja auch nicht darum, was passiert, wenn man ein Programm machen will, das Unicode verwendet, sondern was passiert, wenn man ein Programm machen will, das eigentlich keinen Unicode braucht und mit lokale-basiertem ANSI zufrieden ist.
-Michael

[_Bernd]

Die ganze Diskussion geht ja auch nicht darum, was passiert, wenn man ein Programm machen will, das Unicode verwendet, sondern was passiert, wenn man ein Programm machen will, das eigentlich keinen Unicode braucht und mit lokale-basiertem ANSI zufrieden ist.
-Michael

Unter Windows kannst Du IMHO die LCL mit "DisableWindowsUnicodeSupport" rekompilieren. Ich hatte das mal mit einer 0.9.25er Version getestet.

Gruß, Bernd.

[Christian]

verwechselst du da nicht was ? Damals war der Unicodesupport für windows noch experimentell und musste mit EnableWindowsUnicodeSupport eingeschaltet werden ?!

[_Bernd]

Unicode wurde nach der 0.9.24 zum Standard. Ich hatte dann aber mit der 0.9.25 erhebliche (String) Probleme unter Windows 98. Nach der Rekompilierung der LCL mit "DisableWindowsUnicodeSupport" liefen meine Programm zumindest wieder wie gewohnt. Ich kann jetzt nicht sagen, wie sich das mit der 0.9.26 verhält (bin bei der 0.9.24 geblieben), wahrscheinlich aber genauso. Der Switch "DisableWindowsUnicodeSupport" ist ja immer noch in der lresources.pp vorhanden.

Gruß, Bernd.