Hallo zusammen!

Ich hoffe, der Beitrag bleibt hier im Forum, da er sonst nirgends besser gepasst hat!

Ich habe folgendes Problem:
In einem Netzwerk werden von Mac-Rechnern Dateien auf einen Windows-Server geschoben.
Diese sollen nun gesichert werden mit einer eigenen Software mit Delphi5 geschrieben! Jetzt enthalten manche Dateinamen aber komische Mac-Symbole oder chinesische Schriftzeichen. Wenn ich ein Verzeichnis einlese mit "FindFirst" und "FindNext", liefert mir Windows diese Dateinamen als String mit Fragezeichen an den entsprechenden Stellen der Sonderzeichen zurück. Versuche ich nun, auf diese Dateien lesend zuzugreifen, sagt Windows, dass die Datei nicht existiert. Stimmt ja auch, weil der Dateiname da ja kein Fragezeichen, sondern ein anderes hat.
Unter Windows selbst wird im Explorer so ein Zeichen beispielsweise mit einem Punkt unter dem vorherigen Buchstaben angezeigt, in den Dateieigenschaften wiederum als Rechteck (Unbekanntes Zeichen).

Hat jemand eine Idee, wie man solche Dateinamen handlen kann? Vielleicht mit einem erweiterten Zeichensatz, also was anderes ausser String?

vg, benny

Vergiss Codepages/Charsets. Du kannst mit den TNTWare-Kompos auch fremdsprachig Codierte Dateinamen bearbeiten da diese Wrapper für die Wide-API Funktionen bereitstellen.

Oder du stellst auf Delphi 2009 um. Dieses ist dann Full-Unicode-Enabled und du kannst dein Programm einfach damit kompilieren (nach u.U. kleinen Anpassungen) und deine Probleme sind auch weg.

aus kostengründen kann ich nicht auf 2009 umsteigen, daher scheidet diese variante aus!
sind diese tntware-kompos freeware oder opensource?

und diese stellen direkt funtionen zur verfügung, mit denen ich auf solche dateinamen zugreifen kann? oder nur, um den dateinamen auszulesen?

Zitat von necromundo:

sind diese tntware-kompos freeware oder opensource?

Ältere Versionen ware kostenlos. Diese wurden aber vom Entwickler u.a. auch wegen fehlender Unterstützung der Community an TMS Software verkauft und werden dort weiterentwickelt.

Zitat von necromundo:

und diese stellen direkt funtionen zur verfügung, mit denen ich auf solche dateinamen zugreifen kann? oder nur, um den dateinamen auszulesen?

Sehr viele Nicht-Unicodefähigen API-Wrapper haben in TNTWare eine Unicodefähige Entsprechnung bekommen.

ok, ich habe jetzt seit gestern gesucht, aber keine version davon mehr gefunden, die mit delphi5 funktioniert!
entweder sind die links dazu tot, oder die version, die ich bekomme, ist ab delphi6! das package dafür lässt sich nicht installieren!
hat jemand vielleicht eine version davon für delphi5?

ich weiss aber auch gar nicht, ob ich mit unicode da weiterkomme, weil das zeichen, das dort nicht interpretiert wird, wohl ein mac-spezifisches ist! ich habe mal ein bild angehängt!
links: wie es im windows-explorer aussieht
mitte: so siehts in den dateieigenschaften aus
rechts: so siehts unter delphi aus, wenn es es mit der filelistbox anzeige

unter windows lässt sich so eine datei einfach kopieren, das komische zeichen bleibt! also könnte ich doch sicher auch die windows-api-funktion zum kopieren benutzen! das ist aber nicht copyfile, gibts das entsprechend auch für widestrings?
ausserdem müsste ich dann erstmal den widestring-dateinamen bekommen! ginge das wohl mit "FindFirstFileW" und "FindNextFileW"? das attribut "cFilename" von "WIN32_FIND_DATAW" ist in dem fall ja widestring!

vg, benny

Zitat von necromundo:

ich weiss aber auch gar nicht, ob ich mit unicode da weiterkomme, weil das zeichen, das dort nicht interpretiert wird, wohl ein mac-spezifisches ist! ich habe mal ein bild angehängt!

Wie soll den die Extension unter MacOS heißen. Schaut eher aus das beim Datei-kopieren von MAC nach PC irgend ein Programmfehler auf MAC oder Windows vorhanden ist. Falls der Server ein Windows Home Server ist würde ich mal auf diesen Tippen. Dieser ist so fehlerhaft implementiert das man diesem nur Dateien anvertrauen sollte die man eh löschen will.

Kopier mal den Dateinamen hier im Forum. Evtl. auch in eine Textdatei die Du mit dem Dateinamen unter MacOS speicherst und eine unter Windows.

Zitat von necromundo:

unter windows lässt sich so eine datei einfach kopieren, das komische zeichen bleibt! also könnte ich doch sicher auch die windows-api-funktion zum kopieren benutzen! das ist aber nicht copyfile, gibts das entsprechend auch für widestrings?

Viele API-Funktionen für Widechars haben einfach ein W am ende. Also statt CopyFile -> CopyFileW

Zitat von Bernhard Geyer:

Wie soll den die Extension unter MacOS heißen. Schaut eher aus das beim Datei-kopieren von MAC nach PC irgend ein Programmfehler auf MAC oder Windows vorhanden ist.

Nö, nö, das ist so schon alles richtig und kann mit den Unicode-Varianten einwandfrei gelesen werden.
Da ich genau dieses Problem auch hatte in der gleichen Konstellation.

Es hat bei mir auch eine Ewigkeit gedauert, da der Dateiname am Mac aussah wie z.B. "MeineDatei.mac"
Unter Windows ausgelesen kam dann aber "MeineDatei.ma?"
Nach langem Suchen und Fluchen schaute ich mir den Dateinamen am Mac nochmal sehr genau an.
Dabei fiel mir dann ein kleiner Schutzfleck auf dem Bildschirm auf, den ich als Pedant natürlich sofort entfernen wollte.
Aber da kannst schrubben wie ein Blöder ... der ging nicht weg ... bis ich irgendwie an Maus oder Tastatur kam, der Finder scrollte und der Fleck mitwanderte ...
Der Fleck klebte direkt unter dem "c" von "MeineDatei.mac" und das war des Rätsels Lösung

Mit den Unicode-Varianten waren diese und andere Dateien dann kein Problem mehr.

Bei dem Preisproblem müsste doch eigentlich die Turbo-Version helfen, kostet nix und müsste auch schon Unicode-Varianten haben (Achtung, die muss man aber explizit auswählen, wie hier schon erwähnt)

cu

Oliver

P.S.: Und beim Mac die Frage "was für eine Erweiterung soll denn das sein" zu stellen ist eh überflüssig ... da ist die Erweiterung nur als Name zu gebrauchen und ist nicht die Grundlage für die Programmverknüpfung wie unter Windows.

okay, das hilft mir doch schonmal weiter, dass ich nicht der einizge mit dem problem bin und das auch noch lösbar ist!

der server dort ist ein windows server 2003, dass es daran liegt schliesse ich auch aus! die dateinamen kann ich hier nicht posten, da es sich um dateien meiner auftragsgeberfirma handelt.

also muss ich beim kopieren der dateien an allen stellen widestrings handlen, also beim suchen mit findnextfilew und dann kopieren mit copyfilew!
gibt es auch methoden, um die attribute und größe, datum, etc von solchen dateien auszulesen? mit den dateien haben die standardmethoden auch ihre probleme!

vg, benny

Zitat von necromundo:

die dateinamen kann ich hier nicht posten, da es sich um dateien meiner auftragsgeberfirma handelt.

es reicht wenn du jeweils die Extension postest.

Zitat von necromundo:

gibt es auch methoden, um die attribute und größe, datum, etc von solchen dateien auszulesen? mit den dateien haben die standardmethoden auch ihre probleme!

Schau was die VCL im hintergrund für WinAPI-Funktionen verwendet und schreib dir eine Methode welche die Wide-Version verwendet.

okay, das ist hier biespielhaft einmal eine datei mit der endung ".eps" und eine datei, die auf " 45" endet, ohne endung!

okay, ich beschäftige mich nachher mal mit der lösung des problems und lass es euch wissen, wenn ich fortschritte mache!