FindFirstUTF8 und Umlaute?

[MmVisual]

Hallo,

Ich möchte in einer Routine alle Dateien überprüfen. Doch gibt es einige Dateien die haben Zeichen wie "ي". Also rigend welche arabische Buchstaben.

FindFirst hat die Datei als "???????.xxx" eingelesen (in sr.Name). Dann habe ich es auf FindFirstUTF8 umgestellt, und es geht dennoch nicht. In sr.Name stehen die arabischen Umlaute nicht drin.
Ich habe auch den Dateiname mit SysToUTF8(sr.Name) gewandelt, aber hilft auch nicht.

Was mache ich falsch?
Oder wie geht das richtig?

Code: Alles auswählen

procedure TForm1.DoTest(sDir: String);
Var sr: TSearchRec;
    s: String;
    sl: TStringList;
Begin
  sl := TStringList.Create;
  If FindFirstUTF8(sDir + PathDelim + '*.*',faAnyFile, sr) = 0 Then
  Begin
    Repeat
      s := Copy(sr.Name, Length(sr.Name) - 4, 4);
      If SameText(s, '.htm') Then
      Begin
        s := sDir + PathDelim + SysToUTF8(sr.Name); // <--- hier Dateiname = '???????.xxx'
        sl.LoadFromFile(s); // <----- Hier Fehler
      end Else If (sr.Attr And faDirectory) = faDirectory Then
      Begin
        If (sr.Name <> '.') And (sr.Name <> '..') Then
          DoTest(sDir + PathDelim + sr.Name);
      end;
    until FindNextUTF8(sr) <> 0;
  end;
  sl.Free;
  FindClose(sr);
End;

Vielen Dank für eure Hilfe, Gruß Markus.

[Socke]

Dann habe ich es auf FindFirstUTF8 umgestellt, und es geht dennoch nicht. In sr.Name stehen die arabischen Umlaute nicht drin.
Ich habe auch den Dateiname mit SysToUTF8(sr.Name) gewandelt, aber hilft auch nicht.

FindFirstUTF8 und FindNextUTF8 konvertieren alles automatisch von UTF8 zu Systemkodierung und vice versa. Sie sorgen also dafür, dass in sr.Name immer ein UTF8-String steht.
Soviel zur Theorie. Zur Praxis weiß ich relativ wenig. Woher weißt du denn, was in diesem sr.Name steht?

[theo]

Soviel ich weiss geht das auf Windows im Moment nicht mit "beliebigen" Unicode Zeichen, nur mit der Systemcodierung.
Hier gäbe es ein paar Ersatzfunktionen:
http://bugs.freepascal.org/view.php?id=15795" onclick="window.open(this.href);return false;

[MmVisual]

Diese Ersatzfunktionen scheinen zu funktionieren, ich kann den richtigen Name jetzt in ein Memo schreiben.

Ich teste nachher ob auch das LoadFromFile() geht, ansonsten mache ich das über einen Stream, dafür gibt es auch ein Demo.

[mschnell]

FindFirstUTF8 und FindNextUTF8 konvertieren alles automatisch von UTF8 zu Systemkodierung und vice versa.

Nö, Soweit ich weiß wird nichts konvertiert. Alle String-Funktionen mit Byte-Strings (also wenn nicht explizit "Widestring" angegeben ist) gehen immer davon aus, dass der Inhalt UTF-8 kodiert ist.

Wenn ein Widestring Typ verwendet wird, wird zwar bei einer Zuordnung automatisch von/zu konvertiert, das Ergebnis ist aber manchmal nicht wie erwartet (siehe diverse Diskussion hier vor einigen Monaten). Verwende deshalb immer explizit die richtige Konvertierungs-Funktion !

-Michael

[MmVisual]

Das mit der richtigen String-Konvertierung habe ich soweit schon begriffen. Nur manchmal machen die Funktionen noch nicht das was man erwartet, weil noch nicht implementiert.

Ich habe heute Morgen das aktuellste Lazarus installiert, damit geht FindFirstUTF8() richtig und liefert mir die arabischen Zeichen.
In der Version von Juli ging das noch nicht, daher dieser Thread.

Auf die schnelle kapiert die Funktion " sl.LoadFromFile(s);" das noch nicht, also der findet die Datei nicht. Im String s steht der richtige Dateiname (mit den arabischen Zeichen).

Ich muss da noch ein wenig suchen.

Danke für eure Antworten. Gruß Markus.

[MmVisual]

Die Unicode-Variante:

TFileStreamU.Create(UTF8Decode(s), fmOpenReadWrite);

von der Unit ufiles geht prima.

Vielen Dank!

[Socke]

Nö, Soweit ich weiß wird nichts konvertiert. Alle String-Funktionen mit Byte-Strings (also wenn nicht explizit "Widestring" angegeben ist) gehen immer davon aus, dass der Inhalt UTF-8 kodiert ist.

Ich wills nur noch mal klarstellen: die RTL gibt den String Eins zu Eins an die OS-API weiter. Die von mir angeführten Funktionen gehen davon aus, dass die übergebenen Zeichenketten in UTF-8 kodiert sind und konvertieren diese! Bitte einmal den Quelltext anschauen, der ist recht übersichtlich.

[MmVisual]

> Ich wills nur noch mal klarstellen: die RTL gibt den String Eins zu Eins an die OS-API weiter. Die von mir angeführten Funktionen gehen davon aus, dass die übergebenen Zeichenketten in UTF-8 kodiert sind und konvertieren diese!

Genau das geht nicht mit TFileStream. Wenn ich im TFileStream.Create(); einen UTF8-String übergebe, der arabische Zeichen enthält, dann wird zwar was konvertiert, aber diese Zeichen werden zu "?" somit wird die Datei nicht gefunden.

In der Unit ufiles wird dies mit TFileStreamU korrekt behandelt, siehe hier:
http://bugs.freepascal.org/view.php?id=15795" onclick="window.open(this.href);return false;
(Posting von theo)

(Genauso auch bei TStringList.LoadFromFile(); ... geht auch nicht.)

[Socke]

So langsam verstehe ich, worauf ihr hinaus wollt.
Ich denke, das ist kein direkter Fehler der RTL, sondern eher das Problem, dass unter Windows die ANSI-Funktionen (single byte character set) verwendet werden. Unter Linux funktioniert das ganze ganz wunderbar nur mit der RTL allein, da hier das OS UTF-8 erwartet.

[MmVisual]

Ja, genau das meinte ich.

[mschnell]

Ich denke, das ist kein direkter Fehler der RTL, sondern eher das Problem, dass unter Windows die ANSI-Funktionen (single byte character set) verwendet werden. Unter Linux funktioniert das ganze ganz wunderbar nur mit der RTL allein, da hier das OS UTF-8 erwartet.

Wenn ich mich nicht sehr täusche, muss das Programm (hier also die RTL) in Windows explizit entweder die 8-Bit ANSI-API Funktion oder die 16 Bit (UC-2 / Widestring) ANSI-API aufrufen. Beides ist nicht UTF-8, was die RTL heute verwendet. Die RTL muss also in jedem Fall konvertieren. Ein Unicode-Programm (also die neuere Version der RTL) sollte dann natürlich die Widestring API von Windows verwenden, sonst geht ja das verloren, was Unicode bringen soll.

In Linux ist das natürlich kein Problem, das hier (meist) UTF-8 verwendet wird, genau wie in der RTL. Es ist also keine Konvertierung nötig.

Michael

[MmVisual]

Ich habe gestern das aktuellste Lazarus-Snapshot geladen:
Lazarus-0.9.29-28634-fpc-2.4.2-20101206-win32.exe

Da es hiermit nicht geht, vermute ich mal dass die Lazarus UTF8-Umstellung noch nicht ganz abgeschlossen ist, zumindest für Windows.

Wenn man für Windows eine einfache "UTF8ToSys()" Konvertierung verwendet, dann macht der aus den arabischen Zeichen ein ?.

[theo]

Da es hiermit nicht geht, vermute ich mal dass die Lazarus UTF8-Umstellung noch nicht ganz abgeschlossen ist, zumindest für Windows.

Damit schliesst sich der Kreis dieses Threads. Das wussten wir doch von Anfang an.

Nicht Lazarus ist das Problem sondern Freepascal. Die RTL will bis Dato von Unicode nichts wissen.

[mschnell]

Nicht Lazarus ist das Problem sondern Freepascal. Die RTL will bis Dato von Unicode nichts wissen.

Ohne die entsprechende Unterstützung durch den Compiler muss in Lazarus die UTF-8 Funktionalität sehr unkomfortabel bleiben (wenig Problem für die Amis, schlimmer für die Deutschen, ganz schlecht für Araber).

Die "New Delphi String" Version ist im FPC snv, aber noch lange nicht fertig. Ich glaube auch nicht, dass im Moment aktiv daran gearbeitet wird. Und wenn das fertig ist, muss Lazaruns ja auch noch darauf umgestellt werden.

Ob wir das noch wohl erleben dürfen ....

-Michael