system.insert zählt falsch bei Umlauten [gelöst]

[AlterMann]

Hallo

Ich versuche ein Sonderzeichen mittels Button in den Text eines TEdit einzufügen.
Die Cursorposition hole ich mir über Edit1.SelStart + Edit1.SelLength
Funktioniert auch tadellos, solange kein Sonderzeichen (z.B. Umlaut) vor der Einfügeposition im Text ist.
Dann verzählt sich system.insert, da anscheinend ein Umlaut als zwei Zeichen gezählt wird.

Gibt es da eine einfache Lösung?

fG
Christian

[mschnell]

Offensichtlich arbeitet system.insert mit UTF-8 Codierung und die Position ist in Bytes und nicht in darstellbaren Zeichen angegeben.

Das ist kein Bug, sondern ein Feature.

Wie es aussieht, wird sich dieses Verhalten in irgendeiner späteren Version von Lazarus ändern.

-Michael

[martin_frb]

Offensichtlich arbeitet system.insert mit UTF-8 Codierung und die Position ist in Bytes und nicht in darstellbaren Zeichen angegeben.
Das ist kein Bug, sondern ein Feature.
Wie es aussieht, wird sich dieses Verhalten in irgendeiner späteren Version von Lazarus ändern.

Nein, das wird sich nicht aendern. (Soweit ich weiss).

Auch wenn FPC einen echten UTF8-string hat besteht das problem.

In LazUtils (oder LCLProc/Intf) gibt es Proceduren wie Utf8Copy, Utf8Length, vielleicht auch Utf8Insert...
Mit denen geht das. Allerdings wenn viele Zeichen bearbeitet werden: Sehr langsam!

> EDIT
> Utf8Copy and co arbeiten mit codepoints. D.h fuer Zeichen aus mehreren Codepoints ist der index auch falsch
>

Es geht ebenfalls (fast, nicht wirklich immer), wen vorher in widestring umgewandelt wird.

Das normale Insert (fuer nicht widestring, das ist fuer ALLE 1 byte basierten strings (und utf8 ist 1 byte basiert)) wird sich nicht aendern.
Ebenso funktioniert s[x] nicht.
s[x], insert, copy, ... arbeiten mit Bytes (word, wenn widestring). Nicht mit Zeichen.

In ANSI (Europe): Zeichen = Byte
In Utf8: Zeichen = 1 oder mehr Codepoints / Codepoint = 1 oder mehr Bytes
In Utf16 (widestring): Zeichen = 1 oder mehr Codepoints / Codepoint = 1 word

[theo]

S.a. hier
http://wiki.freepascal.org/LCL_Unicode_ ... characters" onclick="window.open(this.href);return false;

[mschnell]

Nein, das wird sich nicht aendern. (Soweit ich weiss).

Mail von Florian Klämpfl (der oberste FP-Guru): im fpc-developers-Forum unuter dem Betreff "Unicode resouirce strings:

Am 20.08.2012 20:27, schrieb Graeme Geldenhuys:
>
>>> * UnicodeString is always UTF-16 (so everything but Windows takes a
>>> conversion penalty)!
>>
>> A decision has been made and you are not happy with it. Fine. But before
>> you called the fpc team being in a deadlock?
>
> Many things by the FPC team get discussed or debated behind closed
> doors, so how are we even in the fpc-devel mailing list to know what
> is decided. Last I read in fpc-devel it was still heavily debated and
> no decision was in sight. I guess now we know, the decision is UTF-16
> everywhere where UnicodeString is used.

Actually, you overestimate what the "FPC team" can decide. The
"decision" was more like: somebody popped up and proposed to implement
Unicodestring support in a D2009+ compatible way without breaking too
much legacy stuff. So we could say, ok, we merge this into fpc's svn.
The alternative would have been to say no, we leave things as they are:
"deadlock".

The current situation is:
- either somebody starts to implement support for unicodestring being
utf-8 (or whatever) on linux in a compatible way with the current
approach, then 2.8.0 will use this
- nobody works on it, then 2.8.0 comes with unicodestring=utf-16 always.

Wir können also ziemlich sicher sein, dass die zukünftige FPC-Version 2.8 auf Delphi-kompatible UTF-16 Strings umschwenken wird. Lazarus wird diesem Trend folgen müssen.

Ob wir das nun gut finden oder nicht. Es wird sich ändern.

-Michael

[martin_frb]

Ob wir das nun gut finden oder nicht. Es wird sich ändern.

Utf16 hat aber auch combound chars . Problem existiert immer noch.

Der unterschied: Es faellt beim testen nicht mehr unbedingt auf. Der Fehler-report kommt irgendwann spaeter vom end user

[mschnell]

Utf16 hat aber auch combound chars . Problem existiert immer noch.

So ist es. Ich habe auch nicht gesagt, dass sich das (oder ein ähnliches) Problem dann in Luft auflöst. Aber es wird eben anders und wenn man jetzt eine Lösung findet, kann sie dann wieder entweder unnötiger Overhead sein oder nicht mehr funktionieren.

[martin_frb]

Utf16 hat aber auch combound chars . Problem existiert immer noch.

So ist es. Ich habe auch nicht gesagt, dass sich das (oder ein ähnliches) Problem dann in Luft auflöst. Aber es wird eben anders und wenn man jetzt eine Lösung findet, kann sie dann wieder entweder unnötiger Overhead sein oder nicht mehr funktionieren.

Sorry aber ich versteh da was nicht. Gegeben ist ein bestimmtes Problem. Was hilft oder interessiert "Es wird anders" wenn das Problem trotzdem bleibt?

Es wird auch anders, wenn ich ein array of byte verwende... Aber helfen tut das gar nicht (und interessieren auch nicht, jedenfalls mich nicht in diesem Kontext). Aber vielleicht übersehe ich ja was. Viele FIrmen glauben ja auch das Bugs nur dann gefixt werden muessen, wenn Sie bei einem sehr grossem Anteil der Nutzer regelmäßig auftreten.

Sorry for exaggerating a bit...

[mschnell]

Hab ich doch erklärt. Da (vermutlich irgendwann) eine Änderung der LCL ansteht, ist eine Lösung, die jetzt für das Problem gefunden wird, möglicherweise mit einer späteren Version von Lazarus nicht mehr kompatibel. (Das ist einfach nur eine Feststellung, wer das Problem lösen will soll das ruhig machen und abwarten, was passiert, wenn er auf eine später Lazarus-Version upgradet. Man sollte aber wissen, dass das es an dieser Stelle später unvermittelt zu neuen Problemen kommen kann.)

-Michael

[martin_frb]

Ah verstehe. Der teil war mir entgangen.

Aber was sind die alternativen? ....

[theo]

Aber was sind die alternativen? ....

Das ist mschnell normalerweise egal. Er "hat" die Probleme auch nicht wirklich, weil er ganz offenichtlich nicht mehr selber programmiert.
Er findet es einfach lustig, vor Unicode Problemen zu warnen und irgend ein Geschwurbel darüber von sich zu geben.

[AlterMann]

Danke schön für eure Tipps und die rege Beteiligung.

UTF8insert aus der Unit Lazutf8 macht alles richtig.

Nochmals Danke
Christian

[mschnell]

Aber was sind die alternativen? ....

1) Delphi alt (locale-basiertes ANSI)
2) Delphi aktuell (UTF-16)
3) mseIDE (UTF-16)
4) Lazarus alt ((locale-basiertes ANSI)
5) Lazarus aktuell (UTF-8)
6) warten auf Lazarus zukünftig (UTF-16)
Es gibt sicher noch weitere Möglichkeiten Pascal zu programmieren

(Die Reihenfolge soll keine Bewertung darstellen. Hat alles Vor- und Nachteile.)

-Michael

[mschnell]

UTF8insert aus der Unit Lazutf8 macht alles richtig.

Prima. Ich freue mich dass es für Dich funktioniert.

Man kann ja im Moment nicht voraussagen ob/wann es dann (bei einer Neu-Übersetzung mit dem dann aktuellen Lazarus entweder nicht mehr funktioniert oder unnötigen Overhead erzeugt (was vermutlich nicht besonders schlimm wäre).

-Michael

[mschnell]

weil er ganz offenichtlich nicht mehr selber programmiert.

Doch, jede Menge, aber natürlich nicht mit Lazarus, das ist bei mir bis auf weiteres in der Testphase.