UFT8 a[3] := b[3]

[theo]

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

Ja, ich hab ja auch geschrieben "eher schon". {$H+} hat wenigstens mit Strings zu tun.

[marcov]

Bei Strings ist
- 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
Momentan also am besten keine Energie in das Erlernen der String - Operationen der aktuellen Lazarus-Version stecken.

(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.

Neue versionen von FPC tun auch (1). (2) ist eine reine Lazarus loessung.

Aber die lokalen Ansi Codierung(1) auf Linux kann auch UTF-8 sein, und dann sind (1) und (2) gleich.

Auch gibt es kein richtiges UTF8 Stringtyp (ist erst für D2009 Kompatibilität vorgesehen), Utf8string is nur ein Alias für Ansistring um Funktionen zu können Dokumentieren die UTF-8 nutzen. UTF8string hat keine wirkliche UTF-8 Funktionalität, es ist nur ein hint das dieser Ansistring UTF-8 enthält.

[mschnell]

Aber die lokalen Ansi Codierung(1) auf Linux kann auch UTF-8 sein.

AFAIK, UTF-8 ist keine ANSI-, sondern eine Unicode-Codierung. Außerdem ist UTF-8 nicht landesspezifisch (so wie ANSI-xxxx) also eben keine "lokale" Codierung

Soweit ich weiß, erzeugt Lazarus bei einem mit der IDE in den Quelltext getipperten "MYANSISTRING := '1ä2ö';" auf jeden Fall einen UTF-8 codierten String und es gibt keine Einstellung "lokale ANSI-Codierung = deutsch" in Lazarus oder im Linux- oder Windows- System, die das verhindern könnte. Turbo-Delphi und ältere Lazarus-Versionen dagegen erzeugt in jedem Fall eine ANSI-Codierung (vermutlich entsprechend der lokale-Einstellung in Windows, keine Ahnung wie das auf Linux eingestellt wird) und niemals UTF-8.

-Michael

[theo]

Wie oft müssen wir das immer Gleiche denn noch besprechen?
Und wenn du schon immer praxisferne Theorie belabern willst, dann informier dich doch mal ein bisschen.
Es gibt keine "deutsche Kodierung", die verwendete Kodierung ist ISO/IEC 8859-1 resp. Latin-1 oder ISO/IEC 8859-15 und reicht für die meisten europ. Sprachen.

[marcov]

Aber die lokalen Ansi Codierung(1) auf Linux kann auch UTF-8 sein.

AFAIK, UTF-8 ist keine ANSI-, sondern eine Unicode-Codierung. Außerdem ist UTF-8 nicht landesspezifisch (so wie ANSI-xxxx) also eben keine "lokale" Codierung

Das ist eine Meinung, kein Fakt. Eine andere Meinung ist das das die Codierung ist von String-Arrays mit Element-große 1.

Wichtiger, zb Windows und Delphi2009+ haben dieselben Meinung. CP_UTF8 is eine mögliche Lokale Codierung unter Windows (1), und unter D2009+ gibts "UTF8String= type ansistring (CP_UTF8)" (2)

(NEU: Rechts-klick auf Editor window -> Dateieinstellungen -> Kodieren last sich das Konfigurieren)

Soweit ich weiß, erzeugt Lazarus bei einem mit der IDE in den Quelltext getipperten "MYANSISTRING := '1ä2ö';" auf jeden Fall einen UTF-8 codierten String und es gibt keine Einstellung "lokale ANSI-Codierung = deutsch" in Lazarus oder im Linux- oder Windows- System, die das verhindern könnte.

Es ist möglich das Lazarus das Heute forciert ja.
Aber mit FPC hat damit nichts zu tun, und da ist mann frei mit $codepage oder -Fc die Codierung von Quelltexte zu wählen.

Ich habe etwas gesucht in Lazarus und kann dort auch nicht finden wo die Codierung gesetzt wirt. Hast du ein Beispiel?

Turbo-Delphi und ältere Lazarus-Versionen dagegen erzeugt in jedem Fall eine ANSI-Codierung (vermutlich entsprechend der lokale-Einstellung in Windows, keine Ahnung wie das auf Linux eingestellt wird) und niemals UTF-8.

Unter Windows last es sich nicht bequem Konfigurieren (vielleicht aber mit Ultimate), aber es existiert (1).

(1) http://msdn.microsoft.com/en-us/library ... 85%29.aspx" onclick="window.open(this.href);return false; : "Two encodings of Unicode (UTF-7 and UTF-8) are implemented as code pages."
(2) http://blogs.embarcadero.com/abauer/2008/07/16/38864" onclick="window.open(this.href);return false;

[theo]

Ich habe etwas gesucht in Lazarus und kann dort auch nicht finden wo die Codierung gesetzt wirt. Hast du ein Beispiel?

Interessiert das den Compiler überhaupt? Wenn es sich nur um 8bit Zeichen handelt und keine $codepage gesetzt ist, nehme ich an, dass das einfach auf "default" (keine Konvertierung) läuft. Dem Compiler kann ja egal sein, was in String Konstanten und Kommentaren steht, so lange es 8 bit Zeichen sind.

[mse]

Dem Compiler kann ja egal sein, was in String Konstanten und Kommentaren steht, so lange es 8 bit Zeichen sind.

Dem Programmier ist es aber nicht egal, falls er WideString Konstanten definieren will.

[theo]

Dem Programmier ist es aber nicht egal, falls er WideString Konstanten definieren will.

Es ging hier aber um ANSI (Latin1) vs. UTF-8, wenn ich das richtig verstehe.

[mse]

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

Du meinst wahrscheinlich "decomposed characters".

Es ging hier aber um ANSI (Latin1) vs. UTF-8, wenn ich das richtig verstehe.

Der Verzicht auf {$codepage...} -Fc... beeinflusst leider auch WideString-Konstanten.

[theo]

Der Verzicht auf {$codepage...} -Fc... beeinflusst leider auch WideString-Konstanten.

Nichts als Ärger mit den WideStrings...

[mschnell]

Klar meinte ich "decomposed Characters" und nicht "Surrogate Pairs".
Klar meinte ich ANSI-"Latein1" und nicht ANSI-"deutsch".
Entschuldigung für die ungenauen Bezeichnungen.
Das ändert aber nichts an den eigentlichen Aussagen.

-Michael

[mschnell]

Nichts als Ärger mit den WideStrings...

Falsch !
Richtig wäre: Nichts als Ärger mit String-Konstanten.
-Michael

[theo]

Falsch !
Richtig wäre: Nichts als Ärger mit String-Konstanten.

Der obige Beitrag war an mse gerichtet und als Scherz gemeint, wie man am LOL sehen kann.

Welches praktische Problem hast du denn mit String-Konstanten?
Ich möchte jetzt aber nicht das theoretische Gejammere hören, was du schon seit Monaten von dir gibst.
Wenn du ein konkretes Problem hast, kann ich gerne versuchen, dir bei der Lösung zu helfen.

[lrlr]

(zurück zu meinem problem)

also der debugger zeigt bei a[0] das an, was eigentlich a[1] sein sollte: also das 1. zeichen (bzw. byte/char)

das hat delphi 5 bei 1basierten array aber auch gemacht (wenn man optimiert compiliert hat)

(das ursprünglich problem a[13] := b[13] funktioniert heute "plötzlich", entweder war ich gestern farbenblind oder besoffen...)

[mse]

Nichts als Ärger mit den WideStrings...

Nur mit Lazarus und dem "utf-8 in AnsiStrings, kein -Fcutf8, kein BOM, kein {$codepage utf8}"-System; mit MSEgui und anderen FPC Werkzeugen funktioniert es wunderbar.

also der debugger zeigt bei a[0] das an, was eigentlich a[1] sein sollte

Pascal String Indizes sind 1-basiert.

Martin