Umlaute aus Textdatei in TStringList

[mschnell]

Denn die englischsprachigen können ja genauso sagen: "Wozu die Aufregung, das brauchern wir ja auch nicht, bzw. ist für uns keine besondere EInschränkung, Wir können damit gut leben".

Dann hätte man bei ASCII bleiben und Unicode nicht erfinden müssen und alles wäre gut .
Ich kenne aber viel mehr Europäer, die äöü und èéê brauchen als alt-Ägypter

(Wer von Euch hat einen Programmier-Auftrag vom Pharao in Arbeit ? )

-Michael

[mschnell]

Basta find ich gut. Ich teile deine Meinung zwar nicht, aber wird drehen uns im Kreis.Also: Basta!

Wenn keine Einigung zu erzielen, ist der einzig sinnvolle (humanitäre, demokratische, ...) Weg, beide Meinungen zuzulassen. Und das heißt für ein Programm, den Benutzer aussuchen zu lassen, was er machen möchte (im Fall von Lazarus also ihm die Auswahl zu geben zwischen einer LCL-API mit UTF8 und einer mit WideString - am besten auch einer mit ANSI (wie früher). Dem Benutzer Angesichts der nicht Konsens-fähigen Entscheidung für eine "optimale" API einfach UTF8 aufzuzwingen ist mehr als schlechter Stil.

Da aber bei FTP ohnehin noch Änderungen bezüglich der String und Unicode-Behandlung anstehen (vermutlich sogar in zwei Schritten jeweils mit diversen Änderungen) Kann man den jetzigen Zustand nur als unbefriedigende Zwischenstufe ansehen, die man nur einem begrenzten User-Kreis empfehlen kann, der aber (wegen FTP-Update) ohnehin nicht lange bestand haben wird.

Amen

-Michael

[Christian]

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";

Sieste, genau das geht mir dabei auch tierisch auf die nerven. Du sprichst als hättest du 100.000 eur für fpc/lazarus bezahlt.
Man kann das auch sachlich diskutieren ohne solche ausdrücke wie "nicht akzeptabel".

[Christian]

[Man muss nicht, aber sie können in einer Datei stehen die man lädt.

Zählt nicht. "Legacy" Programme und Programme, die jemand schreibt, der von Unicode nichts wissen will, dürfen keine solchen Unicode Dateien laden. Das sind (zumindest momentan bestimmt 99% aller Programme.

Wer so was tut muss natürlich wissen was er da macht.

-Michael

Quark, einerseits erzählst du die programme MÜSSEN mit Unicode umgehen können (siehe ä) andererseits es dürfen keine Unicodedateien geladen werden son schmarn. MOOONNTTAA wo bleibt die funktion beiträge bestimmter Benutzer zu ignorieren xD

[af0815]

Ich teile deine Meinung zwar nicht, aber wird drehen uns im Kreis.

Was wenn ihr nach dem Kreis drehen, mal den Mittelpunkt angeht

Solte da nicht der Benutzer stehen, dem schon ganz schwindlig ist.

[theo]

Solte da nicht der Benutzer stehen, dem schon ganz schwindlig ist.

Unicode macht nun mal "schwindlig".
Das Buch hier hat wohl nicht nur zum Spass 1472 Seiten. http://www.unicode.org/book/aboutbook.html" onclick="window.open(this.href);return false;

@af0815: Was schlägst du vor?

[mschnell]

Quark,... son schmarn. MOOONNTTAA wo bleibt die funktion beiträge bestimmter Benutzer zu ignorieren xD

Juhu ! Endlich mal ein sachlicher Beitrag

-Michael

[monta]

Man musste doch früher Unicodesupport bspw. unter Windows explizit mit defines aktivieren, geh ich richtig in der Annahme, das aber die umgekehrte Variante nicht existiert?

Und man ggf. ein Laz 9.24 aufheben muss, um bei bestimmten Dingen sich darüber keien Gedanken machen zu müssen.

[Christian]

nein wie auch da müsste man ziemlich viel code in den Widgetsets mit defines ausklammern.

[monta]

naja, andersrum ging es ja auch

[Christian]

andersrum gings nur in Windows 32.

[monta]

Das meinte ich ja eigentlich auch nur, da dürfte es ja nun auch die größten Probleme und Verwirrungen geben. Abgeshen von GTK1 war es doch ohnehin unter Linux schon Unicode.

[theo]

Mich würde mal interessieren, wer eigentlich "echte" Probleme damit hat und wie die aussehen.
Ich meine nicht theoretische wie UTF8String='ä', dass das nicht geht wissen wir nun.
Wer kommt den z.B. nicht weiter mit seinem Programm wegen Unicode/UTF-8 ?
Wo hakt's?

Vielleicht können wir so die Diskussion mal etwas sinnvoller gestalten.

[monta]

Die Frage ist gut .

Ich muss ehrlich sagen, das ich etwas abgeschreckt bin von der Unicode-Geschichte, meine großen Projekte auf Unicode sprich auf die 9.26/27 umzustellen. Ich fürchte, das es da bei Datenbankgeschichten doch Probleme gibt, somal die DB nicht UTF sondern ISO8859 ist. Da hab ich es erstmal gelassen, das ganze mit neuem Lazarus zu probieren.
Ansonsten gibt es einfach kleine Probleme, Unsicherheiten, wo man sich nicht sicher ist bzw. was man einfach übersieht, wil man es nicht gewohnt ist. 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. Bzw. man sitzt davor und fragt sich, ob die Funktion nun UTF8 braucht/liefert oder nicht. Ich muss ehrlich sagen, das ich früher auch nie auf die Kodierung geachtet hab.

[theo]

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.