Eine Pfadangabe "säubern"?

[himitsu]

Warum willst du eigentich sowas ändern?

Vorallem Windows ist da sehr Fehlertolerant und lässt Vieles durch,
* Punkt am Ende (leere Dateierweiterung)
* / statt \
* \\ in Pfaden (also "leere" Verzeichnisnamen, welche einem \.\ entsprechen würden und was \\ im Root betrifft, das wurde ja schon erwähnt)

Fast immer würde der "fehlerhafte" Pfad von den meisten APIs verstanden werden und wenn nicht, dann soll eben der Benutzer seine Falscheingabe berichtigen.
Im Gegenzug kannst du so "valide" Pfade fälschlich zerstören, wenn du sie nach falschen Regeln veränderst.

C:\WINDOWS\clock.avi
file:///C:/WINDOWS/clock.avi
file://localhost/C:/WINDOWS/clock.avi

[Codehunter]

Zitat:

Zitat von Glados (Beitrag 1380822)

Wie bekomme ich etwas Dreckiges wie

Delphi-Quellcode:

C:\\123/45\67.

sauber sodass ich

Delphi-Quellcode:

C:\123\45\67

erhalte?

Da stellen sich bei mir alle Nackenhaare auf. Das würde ich nicht machen. Wenn es Benutzereingaben sind, dann würde ich den Pfad lediglich auf Gültigkeit prüfen (DirectoryExists, FileExists) und bei einem Fehler eine verständliche Fehlermeldung ausgeben. Denn so schlau kannst du deine Putzfrau nicht machen, dass sie jede unsinnige Benutzereingabe gerade biegen kann. Du handelst dir zwangsläufig irgendwelche Probleme ein. Einige wurden hier ja schon genannt. Eine weitere, gültige Pfadangabe wäre z.B.

Code:

file:///C:/Users/EinBenutzerName/Desktop/TopFolder/SubFolder1/SubSub/../../SubFolder2/SubSub/Datei...txt

Deine Putzfrau würde das gnadenlos zerschießen.

NACHTRAG: Verwende wenn möglich TOpenDialog zur benutzerfreundlichen Auswahl von Dateipfaden. Dann bekommst du ganz automatisch einen wunderbar sauberen Pfad und verleitest den Anwender durch Freitextangaben nicht geradezu zu Tippfehlern.

[Glados]

Zitat:

Da stellen sich bei mir alle Nackenhaare auf.

Zitat:

Fast immer würde der "fehlerhafte" Pfad von den meisten APIs verstanden werden und wenn nicht, dann soll eben der Benutzer seine Falscheingabe berichtigen.

Das sehe ich anders. Wenn ein Programm fehlerhafte Eingaben noch korrigieren kann, ist doch alles OK.
Und genau dieses fast immer ist der springende Punkt. Ich will mich nicht auf irgendeine API verlassen, die sich gegebenenfalls von XP bis Windows 10 geändert haben könnte.
Da mache ich das lieber selber. Ich weiß ja welche Art Pfade das Programm im Allgemeinen verarbeitet und welche nicht. Und die, die verarbeitet werden, kann ich dann korrigieren.

Zitat:

file:///
Deine Putzfrau würde das gnadenlos zerschießen.

Würde sie definitiv. Aber da ich solche Pfade grundsätzlich nicht im Programm verarbeite ist das auch vollkommen egal.

[Codehunter]

Anmerkung: Es ist üblich, hier anzugeben, wen du zitierst. Sonst legst du mir Worte in den Mund die andere geschrieben haben.

[Glados]

Zusammengefasst möchte ich nur sagen:
Pfadangaben zu korrigieren halte ich für vollkommen in Ordnung wenn man genau weiß welches Format man braucht.
Da ich file:/// und andere Exoten nicht brauche, kann ich auch genau dahingehend Falscheingaben korrigieren.

Falscheingaben aber komplett zu ignorieren halte ich für nicht gut. Man kann ja korrigieren und anschließend noch immer prüfen, ob etwas nicht stimmt.

[nahpets]

Ich würd' erst prüfen, ob es funktioniert und nur wenn nicht einen Korrekturversuch starten.

Prüfst Du direkt nach der Eingabe durch den Anwender oder eher alles eingegebene zu einem späteren Zeitpunkt?

Wenn direkt bei der Eingabe, den Anwender (nach dem Test) sofort auf eine nicht funktionierende Eingabe hinweisen und ihn erst weiterarbeiten lassen, wenn die Eingabe als funktionierend verifiziert werden konnte.

Oder kann der Anwender Eingaben machen, die erst zu einem späteren Zeitpunkt genutzt werden sollen, also z. B. Eingabe von Dateinamen für das zukünftige Speichern von Daten (ggfls. sogar in einer anderen Systemumgebung)?

Wenn die Eingabe zum Zeitpunkt der Eingabe nicht überprüft werden kann, da sie erst später verwendet werden soll und zum Zeitpunkt der Eingabe weder Pfade noch Dateien existieren müssen, wird es schwierig.

Deine Überprüfung kann dann zwangsläufig nicht "perfekt" werden, sondern nur von der Annahme ausgehen, dass höchstwahrscheinlich alle Eingaben funktionieren werden und bei der Veränderung keine potentiellen Fehler erzeugt werden.

Alternative:

Klare Vorgaben machen, was als Eingabe zulässig ist und diese Vorgaben rigoros programmtisch auf Einhaltung überprüfen.

[Glados]

Zitat:

Ich würd' erst prüfen, ob es funktioniert und nur wenn nicht einen Korrekturversuch starten.

Meinst du, ob das Verzeichnis bzw ob die Datei existiert?

Zitat:

Prüfst Du direkt nach der Eingabe durch den Anwender oder eher alles eingegebene zu einem späteren Zeitpunkt?

Ich prüfe während der Eingabe. Wenn es Fehleingaben gibt, wird das mitgeteilt.
Dieselben Eingaben werden später beim erneuten Auslesen für Arbeit XY wieder geprüft und wenn es Fehler gibt bekommt der Nutzer das auch mitgeteilt.

Zitat:

und zum Zeitpunkt der Eingabe weder Pfade noch Dateien existieren müssen, wird es schwierig.

Ich fahre mit meiner aktuellen Lösung recht gut. Pfade und Dateien existieren zu schätzungsweise 50%+ nicht während der Eingabe.

Zitat:

Klare Vorgaben machen, was als Eingabe zulässig ist und diese Vorgaben rigoros programmtisch auf Einhaltung überprüfen.

Das mache ich doch aktuell exakt so. Die Eingabe darf im UNC- oder Normalformat vorliegen. file:\\\ usw sind aber nicht erlaubt.

[nahpets]

Zitat:

Zitat von Glados (Beitrag 1380912)

Zitat:

Ich würd' erst prüfen, ob es funktioniert und nur wenn nicht einen Korrekturversuch starten.

Meinst du, ob das Verzeichnis bzw ob die Datei existiert?

ja

Zitat:

Zitat von Glados (Beitrag 1380912)

Zitat:

Prüfst Du direkt nach der Eingabe durch den Anwender oder eher alles eingegebene zu einem späteren Zeitpunkt?

Ich prüfe während der Eingabe. Wenn es Fehleingaben gibt, wird das mitgeteilt.
Dieselben Eingaben werden später beim erneuten Auslesen für Arbeit XY wieder geprüft und wenn es Fehler gibt bekommt der Nutzer das auch mitgeteilt.

Hier würd' ich prüfen, ob die angegebene Datei existiert.
Wenn nein, prüfen ob der Pfad existiert.
Wenn nein, prüfen, ob gemachte Vorgaben strikt eingehalten werden.

Zitat:

Zitat von Glados (Beitrag 1380912)

Zitat:

und zum Zeitpunkt der Eingabe weder Pfade noch Dateien existieren müssen, wird es schwierig.

Ich fahre mit meiner aktuellen Lösung recht gut. Pfade und Dateien existieren zu schätzungsweise 50%+ nicht während der Eingabe.

Dürfte weitgehend mit meinen oben gemachten Vorschlägen überprüfbar sein.

Zitat:

Zitat von Glados (Beitrag 1380912)

Zitat:

Klare Vorgaben machen, was als Eingabe zulässig ist und diese Vorgaben rigoros programmtisch auf Einhaltung überprüfen.

Das mache ich doch aktuell exakt so. Die Eingabe darf im UNC- oder Normalformat vorliegen. file:\\\ usw sind aber nicht erlaubt.

Ok: Du hast eine klare Vorgabe. Die muss rigoros eingehalten werden. Das kann man an den Nutzer kommunizieren und die Einhaltung überprüfen.

Das dürfte im Endergebnis dann schon passen.

[p80286]

@codehunter
Was ist denn das für ein Schätzchen?
file:///C:/Users/EinBenutzerName/Desktop/TopFolder/SubFolder1/SubSub/../../SubFolder2/SubSub/Datei...txt
Datei.1.1.txt ist klar, aber Datei...txt ?

Gruß
K-H

[nahpets]

Ein sicherlich ungewöhnliches. Alles ab dem letzten Punkt ist Dateiendung.

. ist das aktuelle Verzeichnis, .. das darüberliegende und ...txt ein gültiger Dateiname.
... ist allerdings kein gültiger Dateiname, denn .. ist das drüberliegende Verzeichnis und der dritte . ist die Trennung zwischen .. und der nicht vorhandenen Dateiendung.

dir Verzeichnisname. führt zum gleichen Ergebnis wie dir Verzeichnisname

Es ist aberwitzig, was man mit Punkten in Pfadangaben für Verwirrung schaffen kann, auch wenn es syntaktisch vollkommen korrekt ist und anstandslos genutzt werden kann.