[gelöst] - Insert geht nicht mehr...

[theo]

sonst wird es in Europa mit utf-16 funktionieren, mit utf-8 nicht.

Ja, mein ich ja "in Europa". Wenn das reicht o.k. Ich meine aber dass eine Toolchain diese Begrenzung nicht aufbauen sollte. Ausserdem dürfte man es dann nicht UTF-16 sondern müsste es UCS-2 nennen.
....
Pos funktioniert auch mit UTF-8, sofern beide Inputs in UTF-8 sind. Gibt einfach den Byteindex zurück. (Von der Normalisierung welche beide betrifft, mal abgesehen)
---
Genau genommen müsste man für UTF-16 genauso spezialisierte Funktionen schreiben, wie es sie in der LCL für UTF-8 gibt. (UTF8Copy, ...Insert, ...etc);

Dein Argument funktioniert also nur, wenn man UCS-2 bedienen will. UTF-16 ist das nicht.

[mse]

Ja, mein ich ja "in Europa". Wenn das reicht o.k. Ich meine aber dass eine Toolchain diese Begrenzung nicht aufbauen sollte. Ausserdem dürfte man es dann nicht UTF-16 sondern müsste es UCS-2 nennen.

Wobei man "Europa" für Business Software guten Gewissens auf die ganze Welt ausdehnen kann. Für Hobby Projekte sowieso.

Pos funktioniert auch mit UTF-8, sofern beide Inputs in UTF-8 sind. Gibt einfach den Byteindex zurück. (Von der Normalisierung welche beide betrifft, mal abgesehen)

Richtig. Darum hat man ja mit copy(), delete() und insert() weder mit utf-8 noch utf-16 Probleme, sofern man Index und Länge durch pos() und length() Aufrufe gewinnt.

Genau genommen müsste man für UTF-16 genauso spezialisierte Funktionen schreiben, wie es sie in der LCL für UTF-8 gibt. (UTF8Copy, ...Insert, ...etc);

Einverstanden. Nur ist die Behandlung von surrogate pairs einfacher als die Behandlung von utf-8 Ketten.
Nun nenne mir doch bitte mal die Vorteile für die Lazarus Anwender (nicht die Lazarus Entwickler!) von utf-8 gegenüber utf-16.

Martin

[theo]

Einverstanden. Nur ist die Behandlung von surrogate pairs einfacher als die Behandlung von utf-8 Ketten.

Mag sein aber der "ByteIndex" stimmt trotzdem nicht, sodass man auch durch den ganzen String wandern muss. Also ist das etwa "ghupft wie gsprungen".

Nun nenne mir doch bitte mal die Vorteile für die Lazarus Anwender (nicht die Lazarus Entwickler!) von utf-8 gegenüber utf-16.

Keine Ahnung, ausser des typischerweise in Latin1-Ländern etwas kleineren Speicherbedarfs und der Tatsache, dass ich mit Writeln(Edit1.text) auf meinem de_CH.UTF-8 Linux die Umlaute in der Shell angezeigt bekomme.
Ich sage ja auch nicht, dass es besser sei. Nur hatte ich den Eindruck, man wolle hier WideString UTF-16 als "das Ei des Kolumbus" hinstellen und UTF-8 als Müll. Dem wollte ich entgegenwirken.

Vielleicht müsste man auch mal wieder sagen, dass Unicode noch andere Tücken auf Lager hat, sodass dieses Problem hier (UTF-xx) nicht wirklich zum Kompliziertesten gehört.

[mse]

Ich sage ja auch nicht, dass es besser sei. Nur hatte ich den Eindruck, man wolle hier WideString UTF-16 als "das Ei des Kolumbus" hinstellen und UTF-8 als Müll. Dem wollte ich entgegenwirken.

Nein, nein, utf-16 ist für den Toolkit Anwender nur das kleinere Übel. Und bei der Konzipierung eines GUI Toolkits sollte man hauptsächlich auf die Bedürfnisse der Anwender und weniger auf die Bedürfnisse der Entwickler achten. Auf jeden Fall kenne ich ein ähnlich gelagertes Projekt, wo das so gehandhabt wird.

Martin

Nachtrag:

Writeln(Edit1.text) auf meinem de_CH.UTF-8 Linux die Umlaute in der Shell angezeigt bekomme.

In Windows aber nicht! Und mit utf-16 hättest du die korrekte Anzeige in Linux und Windows.

[theo]

Nein, nein, utf-16 ist für den Toolkit Anwender nur das kleinere Übel.

Naja, dein "Vorteil" besteht aber in der Betrachtung des WideString als UCS-2.
Das freut den chinesischen Anwender gar nicht, während der bei der Lazarus-Variante im selben Boot mit den anderen sitzt.

[marcov]

Einverstanden. Nur ist die Behandlung von surrogate pairs einfacher als die Behandlung von utf-8 Ketten.
Nun nenne mir doch bitte mal die Vorteile für die Lazarus Anwender (nicht die Lazarus Entwickler!) von utf-8 gegenüber utf-16.

Ich kann mir etwas eindenken:

- UTF-8 ist die encoding der Unix Schnittstellen, die meisten Kommerzielle Lazarus programmer sind auf Linux/OS X. (fuer Windows gibts ja Delphi)
- Keine BOM oder -order
- Man muss nicht Horden User den unterschied zwischen 1 und 2-byte textfiles erklären.
- Keine zähe COM Widestrings auf Windows.

Aber die heutige Situation ist sowieso wahnsin:

1) Ich habe nie verstanden warum Lazarus Unicode einseitig gemacht hat mit eine schmale GUI UTF-8 Layer auf basis manueller String support. Das muss mann immer ganz herschreiben wenn richtige unicode support kommt.
2) IMHO is eine fixierte Encoding sowieso Unsinn. Mann soll den Encoding des Systems nutzen. Das ist was User erwarten, und der Rest sind die Fantasien und Traumen der IDE Developer. Und da bist du auch schuldig Martin

Man kann ein Unixer einfach kein UTF-16 system verkaufen, und den letzten mal das ich nachgesehen habe, nennt MSEGUI sich noch immer Portable.

[mse]

Naja, dein "Vorteil" besteht aber in der Betrachtung des WideString als UCS-2.
Das freut den chinesischen Anwender gar nicht, während der bei der Lazarus-Variante im selben Boot mit den anderen sitzt.

Das nehme ich dir nicht ab, dass du nur um mit Chinesen im gleichen Boot zu sitzen, einige Unannehmlichkeiten in Kauf nimmst. Ein mir bekanntes Projekt hat einen aktiven Chinesischen Nutzer der sich öfters in der Newsgroup meldet. Auch er kann mit der Beschränkung auf die BMP leben.

[theo]

Das nehme ich dir nicht ab, dass du nur um mit Chinesen im gleichen Boot zu sitzen,

Ich meine nur, dass eine Toolchain diese Einschränkung nicht machen darf.
Ein Anwendungsprogramm u.U. schon.
Du begründest ja den "Vorteil" von MSEGui mit der Betrachtung von Unicode als UCS-2. Das ist imho nicht gut.

[mse]

2) IMHO is eine fixierte Encoding sowieso Unsinn. Mann soll den Encoding des Systems nutzen. Das ist was User erwarten, und der Rest sind die Fantasien und Traumen der IDE Developer. Und da bist du auch schuldig Martin

Da bin ich Anderer Meinung. Intern soll zur Kommunikation mit den GUI Elementen Platformübergreifend die für den durchschnittlichen Anwender bequemste Codierung verwendet werden. Wir reden hier von GUI- und nicht von Konsolen Programmen.
Bei Konsolen Programmen, die hauptsächlich direkt mit dem Betriebssystem kommunizieren bin ich einverstanden, da sollte die "natürliche" Codierung verwendet werden, diese Programme laufen ja in der Regel auch nur auf einer Plattform. Über die Codierung der FPC RTL und FCL habe ich mich nie geäussert.
Das erwähnte Konkurenzprodukt, für dessen Bedürfnisse ich mich auf fpc-devel und fpc-pascal engesetzt habe, benötigt einen schnellen 16Bit String auf allen eingesetzen Plattformen. Es speichert übrigens keine Daten in utf-16 Dateien. In Textdateien wird ausschliesslich ASCII oder utf-8 verwendet. Für die üblichen Dateioperationen stellt es einen Satz von eigenen Funktionen mit widestring Schittstelle zur Verfügung, daher ist mir die in der FPC RTL und FCL verwendete Codierung auch egal.

Martin

[mse]

Ich meine nur, dass eine Toolchain diese Einschränkung nicht machen darf.
Ein Anwendungsprogramm u.U. schon.

Der Einsatz des nicht Lazarus GUI-Kits ist im Moment beschränkt auf die BMP und kann auch kein BIDI (ein wesentlich grösserer Mangel), diese Einschränkungen können in der Zukunft wegfallen, falls das Bedürfnis danach besteht. Die Einschränkungen beeinflussen weder copy(), delete() noch insert(). Und es hindert niemanden daran, korrekte surrogate pair Behandlung mittels UTF16Copy(), UTF16Delete() und so weiter vorzunehmen. Aber warum sollen ausser den Amerikanern alle Lazarus Anwender dazu gezwungen werden, in ihren Hobby Projekten die umständliche und langsame utf-8 Behandlung vorzunehmen, da ihre Sprache Umlaute und Akzente enthält? Verstehe ich nicht.

[Christian]

Ich verstehe die diskussion nicht mehr.
Wenn wirklich etwas geändert werden soll führt die Diskussion auf der Lazarus Mailingliste.
Ich kannd azu nur immer wieder sagen ich hab damit bisher keinerlei Probleme gehabt und würde mal behaupten das ich mit eine der grössten Lazarus Anwendungen im Moment aufziehe. Meine freunde aus China haben sich noch nicht einmal über iegrndwelche Unicodeprobleme beklagt obwohl ich bisher nicht wirklich drauf geachtet habe. ein UTF8Copy statt copy zu verwenden ist auch nicht gerade eine riesen hürde.
2 Sachen missfallen mir extrem martin. Auf der einen seite sagst du UTF-8 ist Lahm und nimmst deshalb Widestring welcher allerdings mindestens doppelt soviel Speicher frisst. Auf der anderen unterstützt du kein 64 bit weil so viel speicher ja anscheinend eh niemand braucht... Das passt nicht zusammen ein entsprechend grosses resultset aus einer Datenbank kann schonmal schnell in die GB´s gehn bei den richtigen (oder falschen) Abfragen.
Weiterhin machst du permanent Werbung ich hab prinziepell nichts dagegen aber es kommt mir langsam wie ein Glaubenskrieg vor und das kann im LAZARUS Forum nicht sein. Du solltest dir über eines klar werden, die Lazarus Userbase wird gerade durch die Delphi kompatibilität immer viel grösser bleiben als die MSE Userbase. MSE ist aus meiner Sicht ein absopulutes nieschenprodukt. Sicherlich ein sehr schönes und ich zieh den Hut vor der Energie die du da reinsteckst. Aber wenn du so weitermachst stell ich dich als Marketingmann ein

Noch was ihr antworet hier durch die Reiche weg mit 5 Antworten pro Benutzer direkt untereinander wenn ihrs nicht schafft alles zu lesen und dann zu schreiben nutzt bitte die Editierfunktion.

@mschnell was sollte das beispiel mit fs := utf8encode('äöü')
Form1.Caption := fs;

Form1.Caption := 'öäü' tuts doch ?!

[mse]

Aber wenn du so weitermachst stell ich dich als Marketingmann ein

Ich bin mir nicht sicher, ob du dir das leisten könntest.

[Christian]

Och bei der vielen Freizeit die du hast kann das nicht so teuer sein