Verzeichnis mit Unicode-Dateinamen rekursiv abarbeiten

[UliBru]

Hallo,
ich bearbeite Verzeichnisse rekursiv mit Stringlisten und TSearchRec. Dabei bin ich nun wohl auch auf ein Unicode-Problem gestossen. Verstehen tue ich es nicht wirklich. Strings sind doch neuerdings in Delphi Unicode-Strings. Wenn dann alles als String verarbeitet wird, weshalb gibt es dann Probleme beim Verarbeiten der Dateien? Und bei einer writeln-Ausgabe steht dann z.B.
Herbert Gro¨nemeyer
was vorher im Verzeichnis
Herbert Grönemeyer
war. Ergo passiert da was im Hintergrund mit den Strings, was doch eigentlich nicht sein sollte. Kann mir das einer erklären und wie man es denn richtig macht?

[Bummi]

Delphi-Quellcode:

uses
  SysUtils,Windows;
  Function Get4Oem(s:String):AnsiString;
    begin
      SetLength(Result,Length(s));
      CharToOem(Pchar(s),PAnsiChar(Result));
    end;
begin
  try
     Writeln('Grönemayer');

     Writeln(Get4Oem('Grönemayer'));
     Readln;
    { TODO -oUser -cConsole Main : Code hier einfügen }
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
end.

[UliBru]

Das Beispiel mag klappen, ich verstehe trotzdem damit nichts. Vielleicht war mein Beispiel zu simpel.
Ich geh davon aus, dass z.B. ein Nutzer in Dänemark irgendwelche Dateinamen mit speziellen Zeichen hat, im Extremfall wäre es ein Nutzer in Taiwan.
Da wird im Explorer also irgendwas angezeigt.
Delphi liest nun das Verzeichnis mit

Delphi-Quellcode:

FindFirst

und

Delphi-Quellcode:

FindNext

und speichert das Ergebnis in Unicode-Strings.
Da hilft mir denn doch keine Umwandlung in Ansistrings, wenn ich denn z.B. die gefundenen Dateien öffnen/bearbeiten/mit_leicht_geänderten_Dateinamen_abspeichern und dem Anwender den Dateinamen in einem Protokoll angeben möchte.

Eigentlich erwarte ich, dass die gefundenen Dateinamen einfach so verarbeitbar wären. Wozu sonst Unicode?

[Gausi]

Ist das vielleicht einfach nur ein Anzeigeproblem in der Konsole? Ich habe hier Delphi 2009, und da gibt ein simples writeln('Grönemeyer'); auf der Konsole ein "Gr÷nemeyer" aus. Ich hatte bei Delphi2009 bisher keine Probleme mit Unicode-Dateinamen, und ich denke nciht , dass in XE2 da welche eingebaut wurden. ;-)

[gammatester]

Die Konsolausgabe arbeitet mW immer mit Ansistrings.

[UliBru]

Also ich hab mal grad einen Test gemacht:
aus 輝遠報價單.flac wurde doch richtigerweise eine Datei 輝遠報價單_processed.flac erzeugt.
In der Protokolldatei steht aber nur ein ?????_processed.flac.

1. Demzufolge scheint das

Delphi-Quellcode:

Writeln

der falsche Befehl zu sein, das einfache Schreiben in eine

Delphi-Quellcode:

textfile

klappt so nicht. Da schau ich mal wie ich sonst den Unicode-String richtig mitprotokolliere (TStrings.SaveToFile reicht leider nicht, es muss in der log-Datei angehängt werden).

2. Ansonsten muss ich doch noch mal beim Anwender nachfragen, warum bestimmte Dateien nicht bearbeitet wurden. Er hat berichtet, dass eben besagtes Grönemeyer richtig verarbeitet wird, nachdem er es in Groenemeyer umbenamst hat. Mir steht seine Datei nicht zur Vefügung, eine Testdatei hier mit dem ö im Namen (im Explorer einfach so definiert) wird bearbeitet UND es wird auch korrekt protokolliert.

Also zwei Probleme zu lösen.

[Bernhard Geyer]

Zitat:

Zitat von UliBru (Beitrag 1155346)

1. Demzufolge scheint das

Delphi-Quellcode:

Writeln

der falsche Befehl zu sein, das einfache Schreiben in eine

Delphi-Quellcode:

textfile

klappt so nicht.

Delphi-Textfiles sind per definition nicht Unicode. Dazu wurden diese Uraltfunktionen nicht aktualisiert.

Zitat:

Zitat von UliBru (Beitrag 1155346)

Da schau ich mal wie ich sonst den Unicode-String richtig mitprotokolliere (TStrings.SaveToFile reicht leider nicht, es muss in der log-Datei angehängt werden).

Sollte doch mit ein paar Pascal-Zeilen lösbar sein (Filestream öffnen, Text anhängen (mit Zeilenumbruch)) und stream schließen.