AssignFile und WideString Dateiname

[martinf16]

Hallo,
ich wollte einen Code zum Öffnen einer Datei auf WideStrings umstellen. Der wichtigste Ausschnitt des Codes ist folgender:

Delphi-Quellcode:

var
  FileName: WideString;
  F: File;
begin
  {...}
  AssignFile(F, FileName);    
  Reset(F, 1); 
  BlockRead(....
  {...}
end;

Der Code funktioniert super bis zu dem Moment wo andere als ANSI-Zeichen im FileName vorkommen. Offenbar kann AssignFile nicht mit diesen Zeichen umgehen?! Wie kann ich das nun aber lösen?
Ich habe mich bereits überall umgesehen, den einzigen Lösungsansatz, den ich bisher fand, war den Dateinamen in seinen kurzen Dateinamen (8.3) umzuwandeln, der kein Unicode enthalten soll. Diese Lösung finde ich aber nicht sehr elegant, das muss doch einfacher gehen. Also sowas wie WideAssignFile oder ähnliches. In den TNT's habe ich mich auch schon umgeschaut aber auch nichts gefunden.
Vielen Dank schonmal!

[sx2008]

Bitte gib' doch deine Delphi Version an (im Profil); ist wichtig für die Beurteilung der Frage.
Der Datentyp "File" ist übrigens völlig veraltet, man sollte stattdessen Streams benützen.
Wenn du kein Delphi 2009 oder neuer hast, dann fehlt dir die Unicode Unterstützung und
TFileStream.Create() nimmt nur einen normalen Ansi-String entgegen.

Trotzdem muss man dann noch nicht aufgeben, denn man kann sich mit der Windows-API
Funktion CreateFileW() ein Handle erzeugen und dieses Handle einem THandleStream Objekt übergeben.

Da man der Funktion CreateFileW() sehr viele Parameter übergeben muss, ist es empfehlenswert,
sich eine Klasse von THandleStream abzuleiten (Namensvorschlag TFileStreamW).

[p80286]

Zitat:

Zitat von sx2008

...Der Datentyp "File" ist übrigens völlig veraltet, man sollte stattdessen Streams benützen....

Auch wenn ich pers. in der Zwischenzeit Streams nutze (sind meist genauso schnell wie "files") würde mich trotzdem interessieren was an File veraltet sein soll.

Nur weil es "File" schon zu seligen Pascalzeiten gab und er somit relativ alt ist, ist er noch längst nicht veraltet. Daß er mit WideStrings als Dateinamen nicht umgehen kann, würde ich nicht als veraltet, sondern als inkompatibel oder "unfähig" bezeichnen. Aber die grundsätzliche Funktionalität ist heute immer noch gewährleistet.
(Den wahrhaftig mickkrigen Puffer bei Textfile lassen wir einmal aussen vor).

Gruß
K-H

[himitsu]

Vorallem das "File" einen internen Puffer verwendet, wobei Windows schon einen einsetzt (die WindowsFileCache) und was am Schlimmsten ist, daß dieser Puffer auch noch mit seinen 128 Byte völlig "schwachsinnig" dimensioniert ist.

Ansonsten ist es einfach nicht so schön OOP. :stupid:

[gammatester]

Zitat:

Zitat von himitsu

Vorallem das "File" einen internen Puffer verwendet, wobei Windows schon einen einsetzt (die WindowsFileCache) und was am Schlimmsten ist, daß dieser Puffer auch noch mit seinen 128 Byte völlig "schwachsinnig" dimensioniert ist.

Ansonsten ist es einfach nicht so schön OOP. :stupid:

Was für einen "internen Puffer" meinst Du? Ich sehe keinen in der Definition.

Delphi-Quellcode:

type
{ Typed-file and untyped-file record }

  TFileRec = packed record (* must match the size the compiler generates: 592 bytes *)
    Handle: Integer;
    Mode: Word;
    Flags: Word;
    case Byte of
      0: (RecSize: Cardinal);   //  files of record
      1: (BufSize: Cardinal;    //  text files
          BufPos: Cardinal;
          BufEnd: Cardinal;
          BufPtr: PAnsiChar;
          OpenFunc: Pointer;
          InOutFunc: Pointer;
          FlushFunc: Pointer;
          CloseFunc: Pointer;
          UserData: array[1..32] of Byte;
          {$IFNDEF UNICODE}
          Name: array[0..259] of AnsiChar;
          {$ELSE}
          Name: array[0..259] of WideChar;
          {$ENDIF}
      );
  end;

Aber vielleicht meinst Du ja gar nicht file sondern text, das mit read/ln, write/ln bearbeitet wird. Aber da kannst Du, wenn Du 128 Bytes als schwachsinning ansiehst, die Größe mit SetTextBuf ändern.

[himitsu]

wo? > .BufPtr

Abgesehn davon kann AssignFile ab D2009 zwar Unicode-Dateinamen,
aber Write/WriteLn machen aus den ihnen übergebenen UnicodeString nette Ansi-Strings.


Ich sagte nicht, daß AssignFile und Co. extrem schlecht sind ... für kleine Dinge nutze selbst ich ieses manchmal, aber bei größeren Dateien machen sich die "neueren" OOP-Funktionen/Klassen schon besser.

Und im Normalfall braucht man programmintern eigentlich keinen Puffer, da der ja standardmäßig schon seitens Windows vorhanden ist.

[martinf16]

Okay, ich habe mein Profil aktualisiert. Ich nutze den Turbo Explorer.
Ich habe für die Unicode Unterstützung bislang die TNT Komponenten genutzt und natürlich diverse angepasserte Codes aus dem Internet.

[himitsu]

In den TNTs sollte eine TWideStringList und ein TWideFileStream vorhanden sein,
genau wegen der fehlenden Unicodeunterstützung seitens deines Delphis gibt es diese Klassen.

AssignFile ist nunmal nativ nur ANSI.

Du müßtest dir also einen neuen Unicopde-FileRec erstellen, ein eigenes AssignFile, welches den UnicodeNamen entgegennimmt und alle (nötigen) Datei-Öffnen-Prozedure, wie Reset, Rewrite und Append, denn erst darin wird die Datei wirklich geöffnet.

[gammatester]

Zitat:

Zitat von himitsu

wo? > .BufPtr

Wie man leicht sieht, gilt das nur für Textfiles und nicht für file bzw. file of <type>.

[himitsu]

Stimmt, grad nochmal nachgesehn ... mir war aber so, als hätte ich dort auch mal 'nen Puffer gesehn :gruebel:

Aber mal anderstum: Was spricht gegen die neuen OOP-Varianten?

[gammatester]

Zitat:

Zitat von himitsu

Stimmt, grad nochmal nachgesehn ... mir war aber so, als hätte ich dort auch mal 'nen Puffer gesehn :gruebel:

Aber mal anderstum: Was spricht gegen die neuen OOP-Varianten?

Für jemanden, der es nur so kennt, wahrscheinlich nichts. Ansonsten die üblichen Verdächtigen: Vorhandene Codebasis, Kompatibilität/Portabilität und Gewohnheit/Vertrautheit. Für mich wär's jedenfalls eine grauenhafte Vorstellung, wenn ich ein und dieselbe Funktionen mal mit Streams für Delphi und mit Files für Pascal schreiben müßte.

[Bbommel]

Zitat:

Zitat von himitsu

AssignFile ist nunmal nativ nur ANSI.

Du meinst das aber jetzt nur im Kontext des Fragestellers, also für Delphi <2009, richtig?

Ich nutze AssignFile/reset/readln hier und da aus alter Gewohnheit noch ganz gerne und es wäre schon blöd, wenn das dann plötzlich beim Öffnen von Dateien am Zeichensatz scheitert. Delphi selbst sagt dazu allerdings:

Delphi-Quellcode:

  procedure (var F: File; FileName: String)

Und String heißt ja seit D2009 eigentlich immer: Ist Unicode.

Bis denn
Bommel

[himitsu]

Ab Delphi 2009 ist AssignFile, Reset/Rewrite/Append und die FileRecs auf Unicode umgestellt,

aber Read/ReadLn/Write/WriteLn nicht ... diese nehmen zwar UnicodeStrings an, wandeln diese aber intern in Ansi um.

Delphi hat, um Kompatibilitätsproblemen vorzubeugen, die Dateiinhalte ANSI gelassen (es sei denn man stellt die WinAPI auf OEM um, dann wird dort der alte DOS-mäßige OEM-Zeichensatz verwendet und die Daten werden entsprechend konvertiert)

[Bbommel]

Zitat:

Zitat von himitsu

aber Read/ReadLn/Write/WriteLn nicht ... diese nehmen zwar UnicodeStrings an, wandeln diese aber intern in Ansi um.

Jupp, das ist klar. Das habe ich bei mir so gelöst, dass ich die Zeilen mit readLn in einen RawByteString lese... dann wandelt Delphi erst mal gar nichts um und ich kann mich selbst in aller Ruhe drum kümmern - in der Regel heißt das dann von/nach UTF8 wandeln.

Klar, da könnte ich auch die Encoding-Geschichten von TStringList nehmen, aber da bin ich auch schon ein paar mal mit gestolpert - erst gestern hatten wir hier ja ein schönes Beispiel.

Bis denn
Bommel

[himitsu]

Und ich nehm seit Jahren oftmals direkt die WinAPIs, da gibt's auch nie Probleme, wobei ich seit 'ner Weile doch öfters mal wieder zu FileStreams tendiere.