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

[pluto]

Erstmal danke für die Antworten, aber ich wollte hier eigentlich kein neuen Thread aufmachen zum Thema: UTF8 und Lazarus sondern einfach nur klären warum die Insert Methode nicht so geht, wie ich es erwartet hätte.

Ich könnte auch meine Hand dafür ins feuer legen, dass insert eine Funktion gewesen ist und keine Procedure
Die Frage ist für mich damit geklärt

[theo]

Ich könnte auch meine Hand dafür ins feuer legen, dass insert eine Funktion gewesen ist und keine Procedure

Dann empfehle ich dir eine gute Brandsalbe
Das war schon in TP eine procedure http://www.macdonald.egate.net/CompSci/ ... tml#insert" onclick="window.open(this.href);return false;

[mschnell]

Das kann evtl. schon sein, zeigt aber nur wieder, dass unter FPC UTF-8 die Mutter von allem Unicode ist.

Wenn Du mit "Mutter" Source-Datei meinst, ist da auch nichts gegen einzuwenden. UTF8 ist natürlich das kompakteste Format zur Speicherung von Unicode in Dateien. Zum Programmieren ist aber vermutlich in den meisten Fällen UTCS2 (was für alle meine zukünftigen Anwendungen UTD16 entspricht) ("Widestring" in FPC) praktischer und schneller.

D.h. WideString (UCS-2, UTF-16) bedarf immer einer Konvertierung, sonst kann es der FPC gar nicht lesen.

Wenn das automatisch geht (wie ei FPC in standardeinstellung) ist da auch nichts gegen einzuwenden.
-Michael

[Christian]

Praktisch ist im Falle von Lazarus was abwärtskompatibel zu Delphi ist und das ist UTF-8 weitestgehend jedenfalls besser als jedes andere Unicode Format.

[mschnell]

Hier nochmals die Erklärung von Jonas Maebe in fpc-devel:...

Martin, Danke, dass Du das für mich herausgesucht hast, Ich hätte es erst heute machen können.

Das heisst, wenn der Quellcode beispielsweise in utf-8 abgespeichert ist und dem compiler dies mittels -Fcutf8 oder BOM mitgeteilt wird, werden zur Compilezeit string Konstanten, die Codepoints > 127 enthalten, in widestring gewandelt und als widestring ins exe eingebaut....So, dies war nun aber das letzte mal...

Ich hoffe, ich habe die angesprochenen Phänomene inzwischen (u.a. mit Deiner Hilfe, nach einigen Irrungen und Wirrungen) richtig verstanden.
Es läuft doch darauf hinaus, dass bei Benutzung von Lazarus, wenn man ein neues Projekt anlegt, ohne dass man die default-Compiler-Einstellungen ändert, die Anweisungen (die jeder nicht speziell auf das Problem hingewiesene so schreiben würde):

Code: Alles auswählen

var
  ws: WideString; 
begin
 ws := 'äöü123';
 ...

zu einem nicht wie erwartet Unicode kodierten WideString führen.
Es wäre in jedem Fall sehr schlecht, wenn FPC je nach Kodierung der Source-Datei unterschiedliche Objekt-Code erzeugen würde. Natürlich muss der Compiler die Kodierung der Source-Datei erkennen (per Compiler-Option oder durch BOM).

kannst Du das mit MSEIDE vermeiden ?
Dass Du in MSEIDE vermeiden kannst dass die Anweisungen

Code: Alles auswählen

var
  ws: WideString; 
begin
  ws := utf8decode('äöü123');  //oder wie auch immer man einen korrekt Uniciode kodierten WideString erzeugt
  Form1.Caption := ws; // oder wie auch immer man Wondow-Captions in MSEIDE anspreicht

zu einem Problem fürhren, ist mir klar, da die MSEIDE - Linbrary APUI mit WicdeStrings arbeitet.

Wenn aber jemand nun inbedingnt mit UTF8 arbeiten möchte und schreibt:

Code: Alles auswählen

var
  us: UTF8String; 
begin
  us := utf8encode('äöü123');  //oder wie auch immer man einen korrekt Uniciode kodierten UTF8String erzeugt
  Form1.Caption := us; // oder wie auch immer man Wondow-Captions in MSEIDE anspreicht

geht das vermutlich auch mit MSIEID schief. Oder ?

Gruß,

-Michael

[mse]

Es läuft doch darauf hinaus, dass bei Benutzung von Lazarus, wenn man ein neues Projekt anlegt, ohne dass man die default-Compiler-Einstellungen ändert, die Anweisungen (die jeder nicht speziell auf das Problem hingewiesene so schreiben würde):

Code: Alles auswählen

 
var
  ws: WideString; 
begin
 ws := 'äöü123';
 ...
 

zu einem nicht wie erwartet Unicode kodierten WideString führen.

Das sehe ich auch so, und deine Versuche und die Erfahrungen, die russisch sprachige Anwender mit der neuen Lazarus Version machen, bestätigen den Sachverhalt.

Wenn aber jemand nun inbedingnt mit UTF8 arbeiten möchte und schreibt:

Code: Alles auswählen

 
var
  us: UTF8String; 
begin
  us := utf8encode('äöü123');  //oder wie auch immer man einen korrekt Uniciode kodierten UTF8String erzeugt
  Form1.Caption := us; // oder wie auch immer man Wondow-Captions in MSEIDE anspreicht
 

geht das vermutlich auch mit MSIEID schief. Oder ?

Code: Alles auswählen

 
  us := utf8encode('äöü123');  //oder wie auch immer man einen korrekt Uniciode kodierten UTF8String erzeugt
 

funktioniert, 'äöü123' wird zur Kompilierzeit korrekt in widestring gewandelt und zur Laufzeit korrekt von widestring in utf-8.

Code: Alles auswählen

 
  Form1.Caption := us; // oder wie auch immer man Wondow-Captions in MSEIDE anspreicht
 

funktioniert nur, wenn die Systemcodierung utf-8 ist, da MSEgui widestring erwartet und zur Wandlung von UTF8String (=ansistring) in widestring zur Laufzeit die Systemcodierung verwendet wird, also funktioniert es in der Regel unter Windows nicht.
Die Zeile müsste für MSEgui folgendermassen geschrieben werden:

Code: Alles auswählen

 
  Form1.Caption := utf8decode(us); // oder wie auch immer man Wondow-Captions in MSEIDE anspreicht
 

Martin

[mschnell]

funktioniert, 'äöü123' wird zur Kompilierzeit korrekt in widestring gewandelt und zur Laufzeit korrekt von widestring in utf-8.

Ich vermute, die FPC-Macher haben gedacht, bei Unicode sollte man mit Widestrings arbeiten und somit den Compiler auf Widestrings optimiert. Die Lazarus-Macher dagegen (miss-)brauchen FPC zut bearbeitung von UTF8, obwohl der arme Compiler den Typ UTF8String garnicht wirklich kennt, sondern ihm der TYP AnsiString vorgegaukelt wird und da nun mal zufällig UTF8Subcodes statt ANSI-Character drin gespeichert sind.

Trotzdem verwendet der Compiler zur Laufzeit Deiner Aussage nach bei der Umwandlung von Widestring -> ANSIString (UTF8String kennt er ja bekanntlich nicht) die UFT8-Kodierung und nicht die im System eingestellte ANSI-Kodierung ?!?!?!?!? Das soll man nicht verwirrt sein .
-Michael

[mschnell]

Code: Alles auswählen

Form1.Caption := us; // oder wie auch immer man Wondow-Captions in MSEIDE anspreicht

funktioniert nur, wenn die Systemcodierung utf-8 ist, da MSEgui widestring erwartet und zur Wandlung von UTF8String (=ansistring) in widestring zur Laufzeit die Systemcodierung verwendet wird, also funktioniert es in der Regel unter Windows nicht.
Die Zeile müsste für MSEgui folgendermassen geschrieben werden:

Code: Alles auswählen

Form1.Caption := utf8decode(us); // oder wie auch immer man Wondow-Captions in MSEIDE anspreicht

Klar, weil der Compiler UFT7String garnicht kennt und nicht weiß dass er das Unicode-Mäßig in den WideString (den caption:= ...; erwartet) konvertieren soll. Er macht dann vermutlich eine Konvertierung ANSIString (entsprechend der Systemcodierung) zu Widestring, was natürlich zu Blödsinn führt.

Die einzige Rettung ist, dem Compiler den Type UTF8String beizubringen.

Dann konnte er (auf Winsch) length, copy, s, insert usw mit diesem Typ auch korrekt (Character- und nicht Subcode-Counting) machen (was natürlich massiv schlechter Performt als die Subcode-basierten Operationen).

-Michael

[mse]

Die einzige Rettung ist, dem Compiler den Type UTF8String beizubringen.

Oder Lazarus auf widestring umstellen oder MSEide+MSEgui benutzen.

Martin

[theo]

Die einzige Rettung ist, dem Compiler den Type UTF8String beizubringen.

Bzw. dem AnsiString Codepages, wie beim neuen Delphi:
https://forums.codegear.com/thread.jspa ... 715&#16715" onclick="window.open(this.href);return false;
https://forums.codegear.com/thread.jspa ... 546&#15546" onclick="window.open(this.href);return false;

[mschnell]

Oder Lazarus auf widestring umstellen

Nö, Auch dann würden nicht alle Zuweisungen

Code: Alles auswählen

WideString := UTF8String; 
WideString := ANSIString; 
UTF8String := WideString; 
UTF8String := ANSIString; 
ANSIString := WideAString;
ANSIString :) UTF8String;

So funktionieren, wie man sich das vorstellt.
Ganz abgesehen von s, lengthm, copy, insert, etc bei UTF8Strings.
Außerdem sagen die Lazarus-Leute ja dass sie mit gutem Grund die API mit UTF8 machen, weil GTK anscheinend so arbeitet und dann in der LCL nicht so viel konvertiert werden muss.

oder MSEide+MSEgui benutzen.

Das ist für Delphi-Umsteiger aber anscheinend nicht einfach....
(für mich ganz unmöglich, da - wenn überhaupt - die portierte Software im Endeffekt auf Delphi kompilierbar bleiben muss)
-Michael

[mschnell]

Bzw. dem AnsiString Codepages, wie beim neuen Delphi:

ANSI-Strings benutzten (bei Delphi, vermutlich auch bei FPC) immer schon implizit die im System eingestellte Codepage. Jedenfalls arbeiteten doch uppercase und genossen korrekt.

Aber UTF8 (mit Unicode statt Codepage) wollen wir doch auch können. Gleichzeitig !

-Michael

[theo]

ANSI-Strings benutzten (bei Delphi, vermutlich auch bei FPC) immer schon implizit die im System eingestellte Codepage.

Es geht aber darum, dass ein AnsiString sich seine codepage "merken" kann. Das kann auch UTF8 sein.
(Siehe zweiter Link oben)

"Yes, the previous layout is the same, and there are 2 new fields past the
Refount - elementSize and codepage."

S.a. z.B. bei "StringCodePage" in http://dn.codegear.com/article/38498#8StringCodePage" onclick="window.open(this.href);return false;

[mschnell]

Es geht aber darum, dass ein AnsiString sich seine codepage "merken" kann.

Das hatte ich schon verstanden. Kommt mit aber ziemlich abstrus vor. Welchen Codierungs-Typ hat dann s1 := s2 ? Oder s := ws (WideString) ?

Das kann auch UTF8 sein.

UTF8 ist natürlich keine Codepage, aber wenn der Stringtyp sich seine Codierung merken kann, ist das eine sinnvolle Erweiterung.
-Michael

[theo]

Das hatte ich schon verstanden. Kommt mit aber ziemlich abstrus vor. Welchen Codierungs-Typ hat dann s1 := s2 ? Oder s := ws (WideString) ?

Ersteres wahrsch. Default (System Encoding), zweiteres wenn S Ansistring ist: UTF-8. Was sonst?

UTF8 ist natürlich keine Codepage, aber wenn der Stringtyp sich seine Codierung merken kann, ist das eine sinnvolle Erweiterung.

Naja, "65001 is the code page number for UTF-8 on the Windows platform"

http://www.micro-isv.asia/2008/08/will- ... -stand-up/" onclick="window.open(this.href);return false;