TStringList mit UTF-8/Unicode

[Socke]

Hallo zusammen,
zurzeit sitze ich vor folgendem Problem:

Code: Alles auswählen

var
  sl: TStringList;
  s: RawByteString;
  i: Integer;
  cp: TSystemCodePage;
begin
  s := 'Hallo Welt';
  SetCodePage(s, CP_UTF8, False);
  i := sl.Add(s);
  cp := StringCodePage(sl[i]); // cp <> 65001 (UTF_8)
end;

Wie handhabt ihr eure Strings mit dem neuen FPC 3.x? Haltet ihr es wie Lazarus und packt einfach UTF-8-Daten in einen AnsiString oder geht ihr einen anderen Weg?

[Michl]

Scheinbar hat die TStringList kein Eigenleben bzgl. der Codepages. Man muss auch aufpassen, mit welchem String man die StringList füttert. Sie weicht dahingehend von einfachen Strings ab. Bsp. (ohne -disableUTF8RTL):

Code: Alles auswählen

  s := 'ÄÖÜ ' + CP1252TestString;

--> es wird vor dem Anfügen des CP1252TestStrings dieser zu einem UTF8 codierten String umgewandelt. Das Ergebnis ist ein rein UTF8 codierter String.

Genau dieses Verhalten weist die TStringList nicht auf:

Code: Alles auswählen

  SL.Add(UTF8TestString);
  SL.Add(CP1252TestString);

Jetzt hat man einen wunderbaren Codepagemischmasch. Evtl. müsste man bei FreePascal da mal nachhaken, ob man das Verhalten nicht verbessern kann.

Allerdings bringt dieses Verhalten auch den Vorteil mit sich, dass (was ja deine Frage war) man schon mit dem Zufügen einzelner Strings entsprechend ihrer Codierung die Codierung des gespeicherten Files definiert.

Ein einfacher Test:

Code: Alles auswählen

procedure TForm1.Button1Click(Sender: TObject);
const
  UTF8Test1 = #$C3#$84#$C3#$96#$C3#$9C;
  UTF8Test2 = 'ÄÖÜ';
  CP1252Test = #$C4#$D6#$DC;
 
  procedure Test(aName: String; Encoding: TSystemCodePage);
  var
    SL: TStringList;
    rs: RawByteString;
  begin
    SL := TStringList.Create;
 
    rs := UTF8Test1;
    SetCodePage(rs, CP_UTF8, False);
    SetCodePage(rs, Encoding, True);
    SL.Add(rs);
 
    rs := UTF8Test2;
    SetCodePage(rs, CP_UTF8, False);
    SetCodePage(rs, Encoding, True);
    SL.Add(rs);
 
    rs := CP1252Test;
    SetCodePage(rs, 1252, False);
    SetCodePage(rs, Encoding, True);
    SL.Add(rs);
 
    SL.SaveToFile(aName);
    FreeAndNil(SL);
  end;
 
begin
  Test('UTF8Test1.txt', CP_UTF8);
  Test('UTF8Test2.txt', CP_UTF8);
  Test('CP1252Test.txt', 1252);
end;         

Eine beliebige Codierung könnte man auch der Stringlist verpassen über den Umweg vor dem Speichern:

Code: Alles auswählen

    rs := SL.Text;
    SetCodePage(rs, Encoding, True);
    SL.Text := rs;

[EDIT]: Deine Frage war, wie das andere handhaben... Ich nutze die Option -disableUTF8RTL in echten Projekten nicht und da ich Texte nur für interne Wiederverwendungen speichere, speichere ich logischerweise auch alle TStringLists in UTF8 codierten Files (ohne BOM).

[Socke]

Allerdings bringt dieses Verhalten auch den Vorteil mit sich, dass (was ja deine Frage war) man schon mit dem Zufügen einzelner Strings entsprechend ihrer Codierung die Codierung des gespeicherten Files definiert.

Meine TStringList konvertiert alles zur System-Codepage, was bei UTF-8 In- und Output Schwierigkeiten bringt.

Ich nutz(t)e TStringList in meinem aktuellen Projekt vor allem im Speicher; die Fehlerquelle beim Schreiben der Datei/Stream fällt daher weg.

[Michl]

Meine TStringList konvertiert alles zur System-Codepage, was bei UTF-8 In- und Output Schwierigkeiten bringt.

Das ist bei mir definitiv nicht so.

Anbei mal das kleine Testprojekt. Es sollte 3 Files erstellen, 2 UTF8 kodiert, 1 in 1252 kodiert.

Ist das bei dir nicht so, dann wäre dein System interessant.

Ich nutz(t)e TStringList in meinem aktuellen Projekt vor allem im Speicher; die Fehlerquelle beim Schreiben der Datei/Stream fällt daher weg.

Muss ich mal hier schauen...

[Michl]

Ich nutz(t)e TStringList in meinem aktuellen Projekt vor allem im Speicher; die Fehlerquelle beim Schreiben der Datei/Stream fällt daher weg.

Muss ich mal hier schauen...

Nö, das ist bei mir definitiv nicht so:

Code: Alles auswählen

  function PStringToHex(P: Pointer; Cnt: Integer): String;
  var
    i: Integer;
  begin
    Result := '';
    for i := 1 to Cnt do begin
      Result := Result + IntToHex(PByte(P)^, 2) + ' ';
      inc(p);
    end;
  end;
 
  procedure Test(aName: String; Encoding: TSystemCodePage);
  var
    SL: TStringList;
    rs: RawByteString;
  begin
    SL := TStringList.Create;
...
    rs := SL.Text;
    writeln(PStringToHex(Pointer(rs), Length(rs)));
 
    SL.SaveToFile(aName);
    FreeAndNil(SL);
  end; 

--> bringt folgenden Output:

Code: Alles auswählen

C3 84 C3 96 C3 9C 0D 0A C3 84 C3 96 C3 9C 0D 0A C3 84 C3 96 C3 9C 0D 0A 
C3 84 C3 96 C3 9C 0D 0A C3 84 C3 96 C3 9C 0D 0A C3 84 C3 96 C3 9C 0D 0A 
C4 D6 DC 0D 0A C4 D6 DC 0D 0A C4 D6 DC 0D 0A 

--> eindeutig 2 x UTF8 kodiert und einmal 1252.

Mein System: Windows 7, 64bit, Lazarus 1.7 r51544M FPC 3.1.1 r33042 i386-win32-win32/win64

[Socke]

Meine TStringList konvertiert alles zur System-Codepage, was bei UTF-8 In- und Output Schwierigkeiten bringt.

Das ist bei mir definitiv nicht so.

Anbei mal das kleine Testprojekt. Es sollte 3 Files erstellen, 2 UTF8 kodiert, 1 in 1252 kodiert.

Ist das bei dir nicht so, dann wäre dein System interessant.

Die Ursache ist wohl die Methode des Einfügens oder Lesens:

Code: Alles auswählen

program Project1;
 
uses Classes;
 
var
  sl: TStringList;
  s: UTF8String;
  cp: TSystemCodePage;
begin
  sl := TStringList.Create;
  s := 'Hallo Welt';
  Writeln(StringCodePage(s));
  sl.Values['abc'] := s;
  cp := StringCodePage(sl.Values['abc']); // cp <> 65001 (UTF_8)
  Writeln(cp);
  sl.Destroy;
  readln;
end.

Ergibt folgende Ausgabe:

Code: Alles auswählen

65001
1252

[Michl]

Achso, du bist auf der Konsole. Das erklärt das natürlich. Die LCL macht einen Hack, daher ist bei der Verwendung der LCL alles in UTF8 kodiert: http://wiki.freepascal.org/Better_Unico ... in_Lazarus

Auf der Konsole greift Freepascal auf die Systemcodepage zurück. Das ist bei mir auch so.

Du kannst das auch umstellen:

Code: Alles auswählen

program Project1;
 
uses classes;
 
var
  sl: TStringList;
  s: UTF8String;
  cp: TSystemCodePage;
begin
  DefaultSystemCodepage := CP_UTF8;
 
  sl := TStringList.Create;
  s := 'Hallo Welt';
  Writeln(StringCodePage(s));
  sl.Values['abc'] := s;
  cp := StringCodePage(sl.Values['abc']);
  Writeln(cp);
  sl.Destroy;
  readln;
end. 

Jetzt hast du alles in UTF8.

Umgekehrt kannst du auch alles in der Systemcodepage haben, dazu einfach die Projektdatei in der gewünschten Kodierung speichern (und String statt UTF8String verwenden).

[Socke]

Achso, du bist auf der Konsole. Das erklärt das natürlich. Die LCL macht einen Hack, daher ist bei der Verwendung der LCL alles in UTF8 kodiert: http://wiki.freepascal.org/Better_Unico ... in_Lazarus

Auf der Konsole greift Freepascal auf die Systemcodepage zurück. Das ist bei mir auch so.

Der Einzige Zugriff auf die Konsole ist das Ausgeben der Codepage. Ob das Programm die LCL enthält oder nicht ist nebensächlich. Du kannst die Zeilen mit WriteLn und ReadLn auch entfernen und dir die Werte im Debugger anzeigen lassen: da ändert sich nichts.

Die DefaultSystemCodePage ist in der Tat ein gewisses Argument, wobei nirgends definiert ist, welche Codepages die Typen String bzw. Ansistring verwenden.

Hier nochmal ein etwas anders Programm. Wie gesagt, die Ausgabe auf der Konsole hat keinen Einfluss auf die Strings.

Code: Alles auswählen

program Project1;
{$Codepage UTF-8}
uses Classes;
var
  sl: TStringList;
  s: UTF8String;
  cp: TSystemCodePage;
begin
  sl := TStringList.Create;
  s := 'Hallo Welt';
  Writeln(StringCodePage(s));
  sl.Values['abc'] := s;
  s := sl.Values['abc'];
  cp := StringCodePage(s); // cp <> 65001 (UTF_8)
  Writeln(cp);
  sl.Destroy;
end.

Die Ausgabe ist wieder 65001 und 1252, obwohl hier eine Konvertierung nach UTF-8 hätte stattfinden sollen.

[Michl]

Ich bin jetzt leider nicht mehr am Rechner, muss morgen früh raus, daher kurz noch aus dem Kopf. AFAIK sollte man im allgemeinen den Typ String und nicht mehr den Typ UTF8Stri g verwenden. Die Kodierung kann man über das casten als RawByteString und SetCodepage erledigen.
Generell sollte man sich die Codepoints als debughilfe ausgeben lassen. Der Debugger, selbst die Ausgabe in Konsole können Fehlinterpretationen zulassen, da der Debugger nicht immer richtig konvertiert und die Konsole von deren verwendeten Codepage abhängt.
Ein UTF8String ist ein mit Codepage versehener String. Kann schon sein, dass er bei der nächsten Zuweisung diese Codierung verliert und mit dem erwähnten Casten und Setcodepage wieder zugewiesen bekommen muss. IMHO gab es dazu auch mal ein Bugreport, der dann wie eben geschrieben als no chang required gefixt wurde.

Ist ein wenig anders als mit 2.6.4 und man muss an einigen Stellen etwas umdenken, ich persönlich habe aber meinen Frieden mit den neuen Strings gemacht.

bis nächstens

Michael

[Socke]

AFAIK sollte man im allgemeinen den Typ String und nicht mehr den Typ UTF8String verwenden. Die Kodierung kann man über das casten als RawByteString und SetCodepage erledigen.

In Bezug auf Lazarus steht das (noch) auch so im Wiki, da hier immer konvertiert wird (vielleicht hilft hier DefaultCodePage?). In Bezug auf plain FPC ist mir das neu?

Ein UTF8String ist ein mit Codepage versehener String.

Genau das möchte ich doch erreichen!

Kann schon sein, dass er bei der nächsten Zuweisung diese Codierung verliert und mit dem erwähnten Casten und Setcodepage wieder zugewiesen bekommen muss. IMHO gab es dazu auch mal ein Bugreport, der dann wie eben geschrieben als no chang required gefixt wurde.

Wo soll den der Unterschied zwischen UTF8String und einem anderen String mit CP_UTF8 liegen? CP_ACP ist für mich genau so eine CodePage wie UTF-8, nur dass sie weniger spezifiziert ist als UTF-8 (abhängig vom jeweiligen System).
Es wäre schön, wenn du diesen genannten Bugreport nochmals heraussuchen und hier verlinken könntest. Vielleicht verstehe ich dann mehr von den Hintergründen.

[Michl]

Ein UTF8String ist ein mit Codepage versehener String.

Genau das möchte ich doch erreichen!

Ich habe ein falsches Wort verwendet. Besser wäre gewesen ein UTF8String ist ein mit der Codepage CP_UTF8 vorbelegter String.

Wo soll den der Unterschied zwischen UTF8String und einem anderen String mit CP_UTF8 liegen? CP_ACP ist für mich genau so eine CodePage wie UTF-8, nur dass sie weniger spezifiziert ist als UTF-8 (abhängig vom jeweiligen System).
Es wäre schön, wenn du diesen genannten Bugreport nochmals heraussuchen und hier verlinken könntest. Vielleicht verstehe ich dann mehr von den Hintergründen.

Kann sein, dass ich das irgendwo anders gelesen habe und nicht im Bugtracker. Finde ich leider nicht mehr. Bekannt ist das Verhalten allerdings bei FPC, siehe z.B. Testprogramm von Jonas Maebe: http://bugs.freepascal.org/view.php?id=29170#c87948.

Immer wieder wird auf die Seite http://wiki.freepascal.org/FPC_Unicode_support verwiesen. Allerdings ist hier (http://wiki.freepascal.org/FPC_Unicode_ ... _code_page) ja von einer statischen Codepage die Rede.

Ich selber weiß, dass ich immer nur "String" und nicht "AnsiString" oder "UTF8String" verwenden muss, da sich "AnsiString" und "UTF8String" bei der weiteren Verwendung wie normale Strings verhalten:

Code: Alles auswählen

program Project1;
 
{$codepage utf8}
 
uses sysutils;
 
const
  cp1252ae = #$E4;
 
var
  us: UTF8String;
  s: String;
  rs: RawByteString;
 
  function PStringToHex(P: Pointer; Cnt: Integer): String;
  var
    i: Integer;
  begin
    Result := '';
    for i := 1 to Cnt do begin
      Result := Result + IntToHex(PByte(P)^, 2) + ' ';
      inc(p);
    end;
  end;
 
begin
  s := 'ä';
  WriteLn(StringCodePage(s), ': ', PStringToHex(Pointer(s), Length(s)));
  us := s;
  WriteLn(StringCodePage(us), ': ', PStringToHex(Pointer(us), Length(us)));
  rs := cp1252ae;
  SetCodePage(rs, 1252, False);
  WriteLn(StringCodePage(rs), ': ', PStringToHex(Pointer(rs), Length(rs)));
  us := rs;
  WriteLn(StringCodePage(us), ': ', PStringToHex(Pointer(us), Length(us)));
  SetCodePage(RawByteString(us), CP_UTF8, True);
  WriteLn(StringCodePage(us), ': ', PStringToHex(Pointer(us), Length(us)));
  ReadLn;
end. 

Die Ausgabe ist:

Code: Alles auswählen

65001: C3 A4
65001: C3 A4
1252: E4
1252: E4
65001: C3 A4

So, wie ich es erwartet hatte.

Ich kann nicht einschätzen, ob dieses Verhalten genau so von FPC gewünscht ist (bekannt ist es). Dann müsste man den Abschnitt im Wiki http://wiki.freepascal.org/FPC_Unicode_ ... _code_page überarbeiten. Sollten die Codepages wirklich statisch sein, wäre wohl ein Bugreport sinnvoll.

[Edit] Sehe gerade, du hattest einen gemacht http://bugs.freepascal.org/view.php?id=29622. Ja, scheint so, das Wiki müsste wohl angepasst werden, evtl. sollte man vorher nochmal in der FPC Mailinglist nachfragen, ob sie tatsächlich keine statischen Codepages wollen.

[Michl]

Habe dazu nun auch noch einen Bugreport aufgemacht: http://bugs.freepascal.org/view.php?id=29625

[Socke]

Bekannt ist das Verhalten allerdings bei FPC, siehe z.B. Testprogramm von Jonas Maebe: http://bugs.freepascal.org/view.php?id=29170#c87948.

Die Ausgabe von dem verlinkden Quelltext kann ich mit FPC 3.0.0 und Quelltext in UTF-8 oder 1250 (ist dort nicht angegeben) nicht nachvollziehen; da der Bug-Report noch auf "zugewiesen" stehet, gehe ich hier von noch möglichen Änderungen aus.

Habe dazu nun auch noch einen Bugreport aufgemacht: http://bugs.freepascal.org/view.php?id=29625

Ich habe bei meinem Bug-Report auf die Unterschiede zwischen CP_ACP und einer konkret vorgebenen CodePage hingewiesen: http://bugs.freepascal.org/view.php?id=29622#c89857

[Michl]

Ich habe bei meinem Bug-Report auf die Unterschiede zwischen CP_ACP und einer konkret vorgebenen CodePage hingewiesen: http://bugs.freepascal.org/view.php?id=29622#c89857

Jonas sträubt sich

Wie gesagt, ich nutze die Möglichkeit der "statischen" Codepages nicht (seit über 2 Jahren), sondern nehme immer normale Strings, kümmere mich selbst um deren Kodierung und bin damit glücklich (bis UTF16...).

Sehr schön ist auch, dass die Zuweisung von einem statsichen String zu einem statischen String eine Konvertierung hervorruft (per Stringmagic wird der Inhalt konvertiert). Dagegen wird bei der Zuweisung eines normalen Strings zu einem statischen String die Codepage des statischen Strings geändert und keine Konvertierung vorgenommen

Code: Alles auswählen

program Project1;
 
{$codepage utf8}
 
type
  CP1252String = Type String(1252);
 
const
  cp1252ae: CP1252String = #$E4;
 
var
  us: UTF8String;
  s: String;
 
begin
  s := cp1252ae;
  WriteLn(StringCodePage(s));
  us := cp1252ae;
  WriteLn(StringCodePage(us));
  us := s;
  WriteLn(StringCodePage(us));
end.  

Daher Finger weg von UTF8String, AnsiString und Konsorten

[Socke]

Ich habe bei meinem Bug-Report auf die Unterschiede zwischen CP_ACP und einer konkret vorgebenen CodePage hingewiesen: http://bugs.freepascal.org/view.php?id=29622#c89857

Jonas sträubt sich

Er hat ja durchaus Recht bzw. was er sagt stimmt mit meinen Beobachtungen überein. Nur sind diese nicht gut verständlich dokumentiert. D.h. AnsiStrings haben zwar die statische Code Page CP_ACP, verwenden aber eigentlich die Code Page der Quellcode-Datei.