UFT8 a[3] := b[3]

[lrlr]

(mein erstes posting, also nicht gleich über mich herfallen, danke)

nachdem "turbo delphi 2006" unter win7 nicht SOO ideal läuft bin ich letzte woche auf lazarus gestoßen

convert von 2 (simplen) programmen von delphi->lazarus war erstaunlich einfach..

bin aber (natürlich) sofort über dieses (leidige?) thema utf8 gestoßen

a[3] := b[3];

funktioniert nicht...

trotz {$DEFINE Delphi}

und obwohl garkeine sonderzeichen im sting sind (es steht ein datum in dem string)

ich hab copy() + copy() + copy() als (funktionierenden) ersatz verwendet
nur das würde mit UFT8 auch nicht funktionieren ?

wo stelle ich ein dass der "default" für String UnicodeString ist (utf8 macht für mich keinen Sinn)




auch scheint (laut debugger) a[0] das 1. zeichen zu sein

was wäre eine möglichkeit für a[3] := b[3]; die IMMER funktioniert (egal ob UTF8, unicode, "normaler" 8bit string...)

[mschnell]

Bei Strings ist
- das Verhalten der alten (nicht Unicode-fähigen) Lazarus/FPC-Versionen identisch mit dem dem von älteren (nicht Unicode-fähigen) Delphi-Versionen (->1).
- das Verhalten von neueren (Unicode-fähigen) Lazarus/FPC-Versionen (->2) sehr unterschiedlich von dem von älteren (nicht Unicode-fähigen) Delphi-Versionen. Es ist auch nicht möglich, über irgendwelche Optionen ein "altes" (nicht Unicode orientiertes) Verhalten einzustellen, wenn man in seiner Anwendung Unicode nicht braucht.
- das Verhalten von neueren (Unicode-fähigen) Delphi-Versionen (->3) ziemlich unterschiedlich von dem von älteren (nicht Unicode-fähigen) Delphi-Versionen.
- das Verhalten der aktuellen (Unicode-fähigen) Lazarus/FPC-Version sehr unterschiedlich zu dem der aktuellen (Unicode-fähigen) Delphi-Version(en)
- das Verhalten der zukünftigen (Unicode-fähigen) Lazarus/FPC-Version vermutlich identisch oder zumindest sehr ähnlich zu dem der aktuellen (Unicode-fähigen) Delphi-Version(en)

Momentan also am besten keine Energie in das Erlernen der String - Operationen der aktuellen Lazarus-Version stecken.

In einfachen Fällen wird der nicht-Unicode Sourcecode funktionieren, wenn der "neue String Typ" (->3) statt 8-Bit-Strings (->1) verwendet wird. Verwendet man aber die aktuellen "Lazarus Strings" (->2) läuft der alte Sourcecode bei "deutschen" Programmen quasi nie.

(1) der "ANSISTRING" Typ wird als Folge von 8-Bit ANSI-Zeichen in der lokalen ANSI-Codierung (Windows-Einstellung)interpretiert
(2) der "ANSISTRING" Typ wird als UTF8-codiert behandelt, jedes dieser Zeichen kann mit 8, 16, 24 oder 32 Bit codiert sein.
(3) neuer String-Typ mit variabler Codierung mit 8, 16, oder 32 Bit Charactern in ANSI-Codierung mit einstellbarer Codepage, UTF8, UTF16, oder 32 Bit UNICODE.

-Michael

[theo]

Was sind a und b? Strings?
a[3] := b[3]; geht bestimmt, wenn keine Zeichen > 127 vorkommen.

was wäre eine möglichkeit für a[3] := b[3]; die IMMER funktioniert (egal ob UTF8, unicode, "normaler" 8bit string...)

Das gibt es im Moment nicht.

Die LCL arbeitet immer mit UTF-8.
Wenn du auf einzelne Chars zugreifen musst, kannst du entweder vor der Operation nach WideString umwandeln (und dann wieder zurück),
oder du kannst meinen UTF-8 Scanner benützen: http://wiki.lazarus.freepascal.org/Theodp" onclick="window.open(this.href);return false;

Mach mal ein konkretes, vollständiges Beispiel, dann werden wir sehen, wie man das lösen kann.

[lrlr]

ok (so ungefähr dachte ich mir das schon,...)

>(1) der "ANSISTRING" Typ wird als Folge von 8-Bit ANSI-Zeichen in der lokalen ANSI-Codierung (Windows-Einstellung)interpretiert
>(2) der "ANSISTRING" Typ wird als UTF8-codiert behandelt, jedes dieser Zeichen kann mit 8, 16, 24 oder 32 Bit codiert sein.

das stimmt was nicht , oder soll das einfach nur darstellen, dass man es nicht unterscheiden kann, ob utf8 oder nicht..?!?



beispiel zu a[13] := b[13];

var
a,b: String;

a := '10.11.2012 08:07:06';
b := '31.11.2010 09:08:03';
a[13] := b[13];

es wird "irgendwas nach a[13] kopiert
genaueres kann ich am abend sagen (hier hab ich kein lazarus weil in der firma haben wir genug kohle für delphi )

[theo]

das stimmt was nicht , oder soll das einfach nur darstellen, dass man es nicht unterscheiden kann, ob utf8 oder nicht..?!?

Ja.

es wird "irgendwas nach a[13] kopiert

Das:

Code: Alles auswählen

procedure TForm1.Button1Click(Sender: TObject);
var
a,b: String;
begin
a := '10.11.2012 08:07:06';
b := '31.11.2010 09:08:03';
a[13] := b[13];
Edit1.Text:=a;
end;

funktioniert astrein und ergibt:
10.11.2012 09:07:06

[mschnell]

was wäre eine Möglichkeit für a[3] := b[3]; die IMMER funktioniert (egal ob UTF8, unicode, "normaler" 8bit string...)

Die String zuerst explizit in Widestring konvertieren, dann wide_a[3] := wide_b[3] und dann a explizit in UTF8String zurück-konvertieren.

-Michael

[lrlr]

$define delphi

weiß ich noch auswendig, den rest schau ich mir am abend an

im debugger (strg-F7) war bei mir a[13] ein "':'

[mschnell]

das stimmt was nicht , oder soll das einfach nur darstellen, dass man es nicht unterscheiden kann, ob utf8 oder nicht..?!?

Das ist einfach, aber schlecht zu verbalisieren. Jedes "Zeichen" umfasst bei UTF8 eben 1, 2, 3 oder 4 Byte (und dann gibt es noch "Surrogate Pairs", was die Sache noch komplizierter mach ) Die "Adressierung" in Strings "a[3]" funktioniert aber in "Byte" und nicht in "Zeichen". Die Katastrophe ist, dass auch der "ANSISTRING" Typ trotz seines Namens immer als UTF8-codiert behandelt wird (z.B. bei MYANSISTRING := '1ä2ö';), obwohl es auch den UTF8STRING Typ gibt, bei dem ja offensichtlich (oder zumindest erlernbar) ist, was da passiert.

-Michael

[mschnell]

das stimmt was nicht , oder soll das einfach nur darstellen, dass man es nicht unterscheiden kann, ob utf8 oder nicht..?!?

Das ist einfach, aber schlecht zu verbalisieren. Jedes "Zeichen" umfasst bei UTF8 eben 1, 2, 3 oder 4 Byte (und dann gibt es noch "Surrogate Pairs", was die Sache noch komplizierter mach ) Die "Adressierung" in Strings "a[3]" funktioniert aber in "Byte" und nicht in "Zeichen". Die Katastrophe ist, dass auch der "ANSISTRING" Typ trotz seines Namens immer als UTF8-codiert behandelt wird (z.B. bei MYANSISTRING := '1ä2ö';), obwohl es auch explizit den UTF8STRING Typ gibt, bei dem ja offensichtlich (oder zumindest erlernbar) ist, was da passiert.

Beim aktuellen Lazarus gilt also "ANSI = UTF8" wan natürlich technischer Unsinn ist

-Michael

[theo]

und dann gibt es noch "Surrogate Pairs", was die Sache noch komplizierter mach )

Bei UTF-8 nicht, die braucht's bei UTF-16. Deshalb ist die Verwendung von WideString ja auch nicht wirklich besser für den gesamten Unicode Range.
Es tritt dich einfach etwas später in den Hintern...

Beim aktuellen Lazarus gilt also "ANSI = UTF8" wan natürlich technischer Unsinn ist

Quatsch, Char ist Char, das ist technisch iO.

Die einzig sorgenfreie Lösung (in diesem Bereich, Unicode hat noch andere Schmankerl) wären 32bit Chars, das haut aber in den Speicher.

[lrlr]

>Quatsch, Char ist Char, das ist technisch iO.

8bit ?

[theo]

>Quatsch, Char ist Char, das ist technisch iO.
8bit ?

Ja. Nur dass bei UTF8 >#127 Sequenzen vorkommen.

Man kann sich das Anschauen, ich habe Lazarus ja ein Unicode Character Map spendiert :
Bearbeiten -> Aus der Zeichentabelle einfügen -> Unicode Tab
Dort siehst du unten die jew. UTF-8 Repräsentation der Zeichen beim drüberfahren mit der Maus.

[theo]

$define delphi
weiß ich noch auswendig, den rest schau ich mir am abend an

Das hat mit Strings an sich nichts zu tun, eher schon {$H+} AnsiStrings einschalten.

[lrlr]

>Das hat mit Strings an sich nichts zu tun, eher schon {$H+} AnsiStrings einschalten.

define $delphi:
irgendwo hab ich gelesen, dass das irgenwas mit uft8 ja/nein zu tun hätte (ist aber scheinbar nicht so)

$H-

hat das etwas mit utf8 ja/nein zu tun ??

das ist doch "nur" die unterscheidung long/short string (also längenangabe in [0] oder eben "moderne" strings...)

im shortstring kannst ja auch uft8 haben ?!

[mschnell]

Beim aktuellen Lazarus gilt also "ANSI = UTF8" wan natürlich technischer Unsinn ist

Quatsch, Char ist Char, das ist technisch iO..

Von Char habe ich mit Absicht nichts geschrieben, sondern nur von den String-Typen und beim aktuellen Lazarus ist eben
ANSISTRING = UTF8STRING
wenn wir auf beiden Seiten "STRING" subtrahieren bleibt
ANSI= UTF8

aber ein ANSI-ä (mit deutscher Codepage) ist eben etwas anderes als ein UTF-8 ä

Dividiern wir nun die Gleichung
ANSI= UTF8
durch ä
ergibt sich

Lazarus = False


-Michael