Dateinamen mit Umlauten

[eikeble]

Hallo zusammen,

ich habe bei lazarus unter Windows das Problem, dass ich keine Dateien öffnen kann, die Umlaute enthalten. Ich habe versucht die UTF8 strings die mir eine OpenDialog liefert per UTF8ToSys in AnsiStrings umzuwandeln. Dies funktioniert auch, ich bekommen wenigstens keinen Fehler mehr. Beim auslesen der Datei aber bekomme ich nur einen leeren String.

Zuerst trat das Problem bei der ReadXMLFile Funktion auf aber auch ein Versuch mit TFileStream löst das Problem nicht.

Gibt es vieleicht irgend einen Trick?
Lazarus: 0.9.28.2Beta
FPC: 2.2.4
Widgetset: Win32

Vielen Dank schon mal.
Gruß

Eike

[himitsu]

Sicher daß der OpenDialog einen UTF-8-String liefert?

In Delphi macht er es nicht
und dort wird ebenfalls bei Utf8ToAnsi ein Leerstring geliefert, wenn der UTF-8-String defekt ist, bzw falls er nicht der UTF-8-Codierung entspricht.

[eikeble]

Ja, ziemlich sicher. Die Konvertierung funktioniert auch einwandfrei. Daran liegt es also leider nicht.

[Bernhard Geyer]

Kann es evtl. ein Bug in Lazarus sein der darauf begründet ist das man die besch*** Entscheidung getroffen hat den Unicode-Datentyp intern als UTF8 zu realisieren? Ich hatte auch mal eine OpenOffice-Beta-Version im test welche auch keine Dateien mit Umlauten lesen konnte.

[eikeble]

Das kann natürlich sein, hilft mir nur ledier nicht wirklich weiter ;-)
Gruß

Eike

[JamesTKirk]

Hi!

Ich weiß nicht was genau du machst, aber folgender Code funktioniert bei mir unter Win32 und Lazarus 0.9.28:

Delphi-Quellcode:

var
  s: String;
  fs: TFileStream;
begin
  if OpenDialog1.Execute then begin
    Memo1.Lines.Clear;
    s := UTF8ToSys(OpenDialog1.FileName);
    fs := TFileStream.Create(s, fmOpenRead);
    try
      Memo1.Lines.LoadFromStream(fs);
    finally
      fs.Free;
    end;
  end;
end;

Eine Datei namens "file-with-ü.txt" wird erfolgreich ausgelesen und in das Memo geschrieben.

Zitat:

Zitat von Bernhard Geyer

Kann es evtl. ein Bug in Lazarus sein der darauf begründet ist das man die besch*** Entscheidung getroffen hat den Unicode-Datentyp intern als UTF8 zu realisieren? Ich hatte auch mal eine OpenOffice-Beta-Version im test welche auch keine Dateien mit Umlauten lesen konnte.

Ich glaub, dass da jeder eine andere Ansicht darüber hat, wer hier jetzt was falsch gemacht hat ;) - und nein, ich möchte hier jetzt keine Diskussion darüber starten.

Gruß,
Sven

[Bernhard Geyer]

Zitat:

Zitat von JamesTKirk

Ich glaub, dass da jeder eine andere Ansicht darüber hat, wer hier jetzt was falsch gemacht hat ;)

Egal ob man nun alle mit Unicode nach UTF16 (Delphi) nimmt oder nach UTF8 (Lazarus) sollte man auf jedenfall dafür sorgen das alle Methdoen das verwenden. Und dein obiges Beispiel zeit das hier Lazarus nicht konsequent ist. Wenn schon UTF8 dann überall. Delphi mit seiner Implementierung (seit D2) kann z.B über einen eigenen Wrapper für TOpendialog einen Widestring bekommen und diese dann der TFileStream.Create-Methode übergeben und die Compilermagic sorgt dafür das Sonderzeichne die in der aktuellen Codepage vorhanden sind auch korregt zur verfügung stehen.

[eikeble]

Vielen Dank für die Hilfe. Habe den Fehler jetzt gefunden. Selten dämlich, wenn die Datei, die man öffnet keine Daten enthält. Dann kann das ja auch nicht funktionieren ;)

Edit: Was wirklich nicht sehr konsequent ist, dass bei einigen Funktionen (z.B.: TPortableNetworkGraphic.SaveToFile() ) die konvertierung schon implementiert ist und somit bei einer doppelten konvertierung ein leerer String entsteht. Meiner Meinung nach entweder immer die konvertierung dem Programierer überlassen oder halt überall schon übernehmen.

Edit2: Noch inkonsequenter ist, dass einige funktionen (ExtratcFileDir() ) Ansistrings und keine UTF8 Strings zurückliefern. Diese müssen also auch wieder nicht konvertiert werden.

Gruß

Eike

[JamesTKirk]

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von JamesTKirk

Ich glaub, dass da jeder eine andere Ansicht darüber hat, wer hier jetzt was falsch gemacht hat ;)

Egal ob man nun alle mit Unicode nach UTF16 (Delphi) nimmt oder nach UTF8 (Lazarus) sollte man auf jedenfall dafür sorgen das alle Methdoen das verwenden. Und dein obiges Beispiel zeit das hier Lazarus nicht konsequent ist. Wenn schon UTF8 dann überall. Delphi mit seiner Implementierung (seit D2) kann z.B über einen eigenen Wrapper für TOpendialog einen Widestring bekommen und diese dann der TFileStream.Create-Methode übergeben und die Compilermagic sorgt dafür das Sonderzeichne die in der aktuellen Codepage vorhanden sind auch korregt zur verfügung stehen.

Das Problem dieser Inkonsistenz liegt an der zweigeteilten Natur von Lazarus und Free Pascal. Während Lazarus, um die Mehrsprachigkeit bis hin zu Russland, China und Co zu ermöglichen, bereits das komplette Interface auf UTF-8 umgestellt hat, wurde das in RTL und FCL von Free Pascal eben nicht gemacht (deswegen sind auch TFileStream und ExtractFileDir nicht UTF-8-fähig, während TPortableNetworkGraphic Teil der LCL und damit UTF-8-fähig ist). Es wird allerdings vom FPC Team daran gearbeitet dieses Manko mit einem Schwung Compilermagic zu beseitigen.

Gruß,
Sven

[Bernhard Geyer]

Zitat:

Zitat von JamesTKirk

Es wird allerdings vom FPC Team daran gearbeitet dieses Manko mit einem Schwung Compilermagic zu beseitigen.

Und was ist für den Fragesteller die anzustrebende Lösung so das sein Programm nicht mit einen der nächsten Update der RTL/FCL wieder nicht läuft? Oder sollte er nach jedem Update jede UTF8ToSys-Funktionsaufruf checken ob er noch nötig ist?

[JamesTKirk]

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von JamesTKirk

Es wird allerdings vom FPC Team daran gearbeitet dieses Manko mit einem Schwung Compilermagic zu beseitigen.

Und was ist für den Fragesteller die anzustrebende Lösung so das sein Programm nicht mit einen der nächsten Update der RTL/FCL wieder nicht läuft? Oder sollte er nach jedem Update jede UTF8ToSys-Funktionsaufruf checken ob er noch nötig ist?

Ich würde dem Fragesteller raten so weiter zu machen, wie bisher (mit UTF8ToSys und Co). Wenn ich etwas aus den ganzen Mailing List Threads von Free Pascal gelernt hab, dann dass die Entwickler keine Lust (krass ausgedrückt) haben die ganze RTL, FCL und auch die LCL deswegen umzubauen. Deshalb denke ich, dass sie die Compilermagic so einbauen werden, dass alter Code weiterhin ohne Änderungen verwendbar bleibt. Allerdings wird das wohl noch bis mindestens Free Pascal 2.6 dauern, da die Entwicklung dieses Features noch immer in einem extra Branch stattfindet (vielleicht wird die Einführung dieses Features auch 3.0 markieren).

Gruß,
Sven

[himitsu]

Zitat:

Zitat von JamesTKirk

Deshalb denke ich, dass sie die Compilermagic so einbauen werden, dass alter Code weiterhin ohne Änderungen verwendbar bleibt.

Dann wird FP ja wirklich dem Delphi immer ähnlicher.

Seit D2009 gibt es da Funktionen wir AnsiUpperCase, welche aber Unicode sind ... nur damit man als Programmierer es bei der Umstelltung leichter hat,
aber wenn man etwas neu erstellt, dann ist das Chaos groß. :wall: