FPC Unicode support

[theo]

Habe ich einen Schalter verpasst?

Vermutlich ${codepage utf8} oder -Fcutf8.

Ja, so geht's mit UnicodeString, aber
u16:=u8;
gibt immer noch Länge 6.

Soll das so sein und warum?

[mse]

Es gibt mehrere Grundsatzentscheidungen zu treffen:

Warum? FPC 2.6.0 hat doch ausser Unicode ResourceStrings schon alles was es braucht , siehe mein Beitrag weiter oben.

Für 8-Bit Speicherung von Zeichenketten und kombinierte Zeichen und binären Daten wird "AnsiString" verwendet.
Für alle reinen Zeichenketten für GUI-Zwecke wird 16bit-UnicodeString verwendet, die Codierung ist utf-16.
Die Konversion AnsiString <-> UnicodeString wird auf Basis der 8bit-Systemcodierung von Compiler und RTL automatisch durchgeführt, alle weiteren Code-Wandlungen müssen vom Programm explizit vorgenommen werden.

Alles andere ist hauptsächlich Delphi Kompatibilität. Da einige FPC Core Entwickler beruflich mit Delphi arbeiten, hat das einfach Vorrang.

[mse]

Soll das so sein und warum?

Ja, das soll so sein AFAIK. "Codepage aware AnsiString" liefert immer bytecount als Länge.

[theo]

Ja, das soll so sein AFAIK. "Codepage aware AnsiString" liefert immer bytecount als Länge.

Sieht so aus. Folgerichtig, aber nicht extrem intuitiv, ergibt dann folgendes auch 1
StringElementSize(u16)

[mschnell]

Ja, das soll so sein AFAIK. "Codepage aware AnsiString" liefert immer bytecount als Länge.

Ja Unicode ist wirklich einfach und intuitiv.

Ein Stringm der genau ein Alt-Ägyptisches Zeichen in UTF-16-Codierung beinhaltet kann also drei mögliche Längen haben:

- 1 (Anzahl der sichtbaren Zeichen)
- 2 (Anzahl der Unicode-Code-Elemente
- 4 (Anzahl der Bytes)

-Michael

[mse]

Ja, das soll so sein AFAIK. "Codepage aware AnsiString" liefert immer bytecount als Länge.

Ein Stringm der genau ein Alt-Ägyptisches Zeichen in UTF-16-Codierung beinhaltet kann also drei mögliche Längen haben:

- 1 (Anzahl der sichtbaren Zeichen)
- 2 (Anzahl der Unicode-Code-Elemente
- 4 (Anzahl der Bytes)

Vier.
Du hast "Anzahl der 16bit Speicher Einheiten" vergessen, falls du mit "Unicode-Code-Elemente" "code points" meinst.
Falls "Unicode-Code-Elemente" "Anzahl der 16bit Speicher Einheiten" meint, hast du "code points" vergessen.

http://en.wikipedia.org/wiki/Code_point

Martin

[mschnell]

Vier. Du hast ... vergessen

Falls da nicht "3 Stück" rauskommt, bleibt's bei 3 verschiedenen Längen

-Michael

[mse]

Falls da nicht "3 Stück" rauskommt, bleibt's bei 3 verschiedenen Längen

Verstehe ich nicht.

[theo]

Ich kapier's trotzdem nicht.
In Delphi ist der "magische" UnicodeString nun der Default String.
Bei FPC aber nicht.

Code: Alles auswählen

var u:UnicodeString;
  s:String;
begin
  u:='test';
  s:='test'; 
  Caption:=inttostr(StringElementSize(u));
  Caption:=inttostr(StringElementSize(s));

Bei Delphi: "UnicodeString kann Unicode- und ANSI-Strings enthalten." in FPC ist es aber nur ein WideString mit Ref. Zählung.
"Currently FPC 2.3.x has a new type called UnicodeString. This is similar to a WideString type. The difference being that UnicodeString is reference counted on all platforms. "

Dann gibt es aber einen neuen AnsiString der gerne auch UTF16 "frisst" aber trotzdem eine Elementgrösse von 1 hat.
Und wie laufen die automat. Konversionen nun genau?

HILFEEEEE!

[mse]

Ich kapier's trotzdem nicht.
In Delphi ist der "magische" UnicodeString nun der Default String.
Bei FPC aber nicht.

Wahrscheinlich "not yet decided".

Bei Delphi: "UnicodeString kann Unicode- und ANSI-Strings enthalten."

Woher hast du diese Information? So viel ich weiss gilt das für Delphi nicht mehr. Es war mal die Rede davon, wurde dann aber nicht realisiert. Falls doch, ist es ja noch schlimmer...
Wobei, was meint "Unicode- und ANSI-Strings"? Den Text von Unicode- und ANSI-Strings oder die binären Daten?

Dann gibt es aber einen neuen AnsiString der gerne auch UTF16 "frisst" aber trotzdem eine Elementgrösse von 1 hat.
Und wie laufen die automat. Konversionen nun genau?

"not yet decided".
Grundsätzlich wird von neuem AnsiString - wie sollen wir den nennen, cpstrnew? - in einen cpstrnew in anderer Codierung zuerst in UnicodeString (utf-16) gewandelt und dann in die Codierung des anderen cpstrnew.
Teilweise kann dieser Vorgang zur compile Zeit aufgelöst werden, teilweise müssen zur Laufzeit die Codierungsflags ausgewertet werden. Auf jeden Fall ist dies alles der Performance und der Einfachheit des Compilers und der Laufzeitumgebung nicht zuträglich.

[theo]

Nur kurz, mehr später:

UnicodeString kann als die folgende Delphi-Struktur dargestellt werden:

type StrRec = record
CodePage: Word;
ElemSize: Word;
refCount: Integer;
Len: Integer;
case Integer of
1: array[0..0] of AnsiChar;
2: array[0..0] of WideChar;
end;

http://docwiki.embarcadero.com/RADStudi ... RAD_Studio" onclick="window.open(this.href);return false;

Soviel zum Thema: "Lies einfach die Delphi Doku".

[mse]

Für cpstrnew und UnicodeString wird der gleiche Record verwendet.
Eine UnicodeString Variable hat aber immer die "2: array[0..0] of WideChar;" Form. AFAIK...

[theo]

Für cpstrnew und UnicodeString wird der gleiche Record verwendet.
Eine UnicodeString Variable hat aber immer die "2: array[0..0] of WideChar;" Form. AFAIK...

Das befürchte ich auch, womit ich nun wirklich jeden verstehe, der das alles nicht versteht.
Ich für meinen Teil ziehe mich vorläufig wieder aus diesem Geschehen zurück.
Soviel Schrott interessiert mich einfach nicht mehr.

[mschnell]

Falls da nicht "3 Stück" rauskommt, bleibt's bei 3 verschiedenen Längen

Verstehe ich nicht.

1, 2 und 4 habe ich schon erwäht, weniger als 1 oder mehr als 4 kommt sicher nicht raus, bleibt die "3" als einzige weiter Variante.
-Michael

[mschnell]

Bei Delphi: "UnicodeString kann Unicode- und ANSI-Strings enthalten."

Ich habe zwar beides nicht, aber meine Kollegen haben mir erzählt dass sich das zwischen "Delphi 2009" und "Delphi XE 2" in diversen Aspekten geändert hat und erheblich verbessert worden ist (in welcher Hinsicht auch immer).

Du musst also die Delphi-Version beachten, mit der Du FPC vergleichen willst

-Michael