Eine Pfadangabe "säubern"?

[Glados]

Ich stelle mir gerade die Frage wie man am besten eine unsaubere Pfadangabe säubert.
Wie bekomme ich etwas Dreckiges wie

Delphi-Quellcode:

C:\\123/45\67.

sauber sodass ich

Delphi-Quellcode:

C:\123\45\67

erhalte?
Aktuell mache ich das so aber das ist sicher nicht so dolle oder?

Delphi-Quellcode:

begin
 if Trim(aDir) = '' then
  begin
   Result := '';
   Exit;
  end;

  // Wenn aDir eine Dateiangabe ist warum auch immer, dann ...
  // aDir := ExtractFileDir(aDir);

 aDir := StringReplace(aDir, '/', '\', [rfReplaceAll]);

 while (AnsiEndsStr('\', aDir)) or AnsiEndsStr('.', aDir) do
  aDir := Copy(aDir, 1, Length(aDir) - 1);

 while Pos('\\', aDir) > 0 do
  aDir := StringReplace(aDir, '\\', '\', [rfReplaceAll]);

 while Pos('\ ', aDir) > 0 do
  aDir := StringReplace(aDir, '\ ', '\', [rfReplaceAll]);

 Result := Trim(aDir);
end;

Ich bin ein totaler Spagetti-Coder und möchte natürlich Neues lernen!

[p80286]

Woher kommen denn diese "dreckigen" Pfadangaben?
Hintergrund meiner Frage ist: es könnte sich jemand etwas dabei gedacht haben!

Gruß
K-H

[Glados]

Das können Benutzereingaben sein.
Ziel von mir ist es aber, alles was nicht dem Standard entspricht wegzufegen.
Doppelte Querstriche oder welche die falsch herum sind, oder das erste Zeichen nach einem \ sollte auch kein Leerzeichen sein (C:\123\ 456\789\)
und das letzte Zeichen eines Pfades sollte auch kein . sein. Das entfernt mein Code ja. Nur sicherlich alles andere als gut.

[sakura]

Und schon rennst Du in das erste Problem, da z.B. Netzwerkverweise meist mit \\ beginnen, z.B.

Code:

\\Servername\Pfad\Pfad\Datei.xyz

Aus Erfahrung, versuche nicht zu bereinigen, sondern zu testen, ob die Eingabe sich verarbeiten lässt (z.B.: TFile.Exists, TDirectory.Exists, ...).

...:cat:...

[Glados]

Zitat:

Wie bekomme ich etwas Dreckiges wie C:\\123/45\67. sauber sodass ich C:\123\45\67 erhalte?

Reicht das, wenn ich das doppelt schreibe?

[sakura]

Zitat:

Zitat von Glados (Beitrag 1380841)

Zitat:

Wie bekomme ich etwas Dreckiges wie C:\\123/45\67. sauber sodass ich C:\123\45\67 erhalte?

Reicht das, wenn ich das doppelt schreibe?

Wie meinst Du diesen letzten Beitrag? Ich wollte lediglich darauf hinweisen, dass es auch andere legale Pfade gibt, welche durch das entfernen des doppelten \\ zerstört werden - sprich deine obige Routine würde zu einem ungültigen Pfad führen...

...:cat:...

[nahpets]

Und nicht vergessen, Leerzeichen sind in Pfadangaben durchaus erlaubt.

C:\123\ 456\789\ ist zulässig, wenn auch ungewöhnlich, von daher ist der Vorschlag, die Pfade zu prüfen, sinnvoll.

Wenn dann ein Pfad ungültig ist, kann man versuchen, ihn durch das Ersetzen von (vermutlich) fehlerhaften Zeichen zu bereinigen und dann mit dem Bereinigten erneut probieren, ob es nun ein gültiger Pfad ist.

Und / statt \ funktioniert unter Windows (außer auf der Kommandozeile) auch schon etwas länger. Allerdings ist eine einheitliche Nutzung sicher vorzuziehen.

[p80286]

Also im Prinzip bist Du auf dem richtigen Weg. ich empfehle Dir nur Dich zuerst hier zu informieren.

Ich habe den Eindruck daß du ein etwas rustikales Vorgehen bevorzugst.

Gruß
k-H

[Glados]

Zitat:

C:\123\ 456\789\ ist zulässig

Wie schafft man es denn ein Verzeichnis mit [Leerzeichen]456 abzuspeichern? Habe ich bisher noch nie geschafft.

Zitat:

Ich wollte lediglich darauf hinweisen, dass es auch andere legale Pfade gibt, welche durch das entfernen des doppelten \\ zerstört werden

Ich hätte besser anfügen sollen, dass ich an einer anderen Stelle mittlerweile prüfen, ob es sich um einen Netzwerkpfad handelt. Klappt wunderbar.

Delphi-Quellcode:

var
 bIsDirectory, bIsNetworkPath: Boolean;
begin
 aPath := Trim(aPath);

 if aPath = '' then
  begin
   Result := '';
   Exit;
  end;

 aPath := StringReplace(aPath, '/', '\', [rfReplaceAll]);

 bIsNetworkPath := Copy(aPath, 1, 2) = '\\';
 bIsDirectory := ist aPath ein Verzeichnis? ...

 // Wenn aDir eine Dateiangabe ist warum auch immer, dann ...
 // aDir := ExtractFileDir(aDir);


 while Pos('\ ', aPath) > 0 do
  aPath := StringReplace(aPath, '\ ', '\', [rfReplaceAll]);

 if not bIsNetworkPath then
  while Pos('\\', aPath) > 0 do
   aPath := StringReplace(aPath, '\\', '\', [rfReplaceAll]);

 while (AnsiEndsStr('\', aPath)) or AnsiEndsStr('.', aPath) do
  aPath := Copy(aPath, 1, Length(aPath) - 1);

 Result := Trim(aPath);
end;

Zitat:

Ich habe den Eindruck daß du ein etwas rustikales Vorgehen bevorzugst.

Wie genau meinst du das?
Wenn es hierfür was Fertiges gäbe, würde ich es sofort nehmen.

Auf etwa dieselbe Art und Weise habe ich auch etwas zusammengebaut, was verbotene Zeichen in Dateinamen entfernt.
Da aber mit einem Array.

[nahpets]

Zitat:

Zitat von Glados (Beitrag 1380855)

Zitat:

C:\123\ 456\789\ ist zulässig

Wie schafft man es denn ein Verzeichnis mit [Leerzeichen]456 abzuspeichern? Habe ich bisher noch nie geschafft.

Aus Delphi heraus z. B. mit

Delphi-Quellcode:

ForceDirectories('c:\123\ 456\789\');

, von der Kommandozeile mit

Delphi-Quellcode:

md "c:\123\ 456\789\"

[p80286]

Zitat:

Zitat von Glados (Beitrag 1380855)

Zitat:

Ich habe den Eindruck daß du ein etwas rustikales Vorgehen bevorzugst.

Wie genau meinst du das?

Nun z.B. ist c:\Daten. durchaus eine zulässige Angabe. Da einfach den Punkt zu löschen ist eher ein rustikales Vorgehen.

Gruß
K-H

[TigerLilly]

Ein richtiger Pfad ist noch lange nicht gültig.

Gut wäre es, wenn die Pfade beim Eingeben validiert werden.

Sie nachträglich zu bereinigen ist problematisch, weil du da raten musst, was gemeint sein könnte. Ein ":" im Pfad ist sicher falsch, aber ev. war ja das "L" darüber gemeint - ein Entfernen des ":" macht den Code also sicher nicht gültig - obwohl syntaktisch richtig.

[Glados]

Das ist gut zu wissen. Ich sollte dem Windows-Explorer weniger Beachtung schenken.

Dann kann das hier ja schon einmal raus

Delphi-Quellcode:

while Pos('\ ', aPath) > 0 do
 aPath := StringReplace(aPath, '\ ', '\', [rfReplaceAll]);

Auch geändert habe ich das hier

Delphi-Quellcode:

 // bIsNetworkPath := Copy(aPath, 1, 2) = '\\';
 bIsNetworkPath := IsUNCPathEx(aPath);

Delphi-Quellcode:

// (teils aus der DP-Suche)

function IsUNCPathEx(aPath: string): Boolean;
begin
 // true: aPath = \\server\path, \\?\server\path or \\?\UNC\server\path
 Result := GetUNCPrefix(aPath) <> '';
end;

function GetUNCPrefix(aPath: string): string;
begin
 Result := '';

 case GetExtendedPrefix(aPath) of
  pptExtended:
   Result := '\\?\';
  pptExtendedUNC:
   Result := '\\?\UNC\'
 else
  if Copy(aPath, 1, 2) = '\\' then
   Result := '\\';
 end;
end;

[p80286]

Ich hätte da noch was:

Code:

\\.\%tmp%\123.zip

(ist ein gültiges und vorhandenes Verzeichnis)
oder

Code:

\\.\D:\

Gruß
K-H

[Glados]

Kommt man damit ins Temp-Verzeichnis? Nehme ich mal stark an

[p80286]

Zitat:

Zitat von Glados (Beitrag 1380882)

Kommt man damit ins Temp-Verzeichnis? Nehme ich mal stark an

Kommt darauf an was auf dem entsprechenden Rechner definiert wurde, aber in den meisten Fällen ja.
übrigens

Code:

"c:/Daten/Temperaturen"

funktioniert auch!

Gruß
K-H

[noisy_master]

Das

Delphi-Quellcode:

while Pos(....)

kannst du weglassen, weil du ja schon ein rfReplaceAll drin hast....

[TigerLilly]

https://msdn.microsoft.com/en-us/lib...).aspx#maxpath

[sakura]

Zitat:

Zitat von noisy_master (Beitrag 1380888)

Das

Delphi-Quellcode:

while Pos(....)

kannst du weglassen, weil du ja schon ein rfReplaceAll drin hast....

Nope, da liegst Du falsch.

Teste mal folgenden Code:

Delphi-Quellcode:

procedure TestWhile;
var
  SomeText: string;
const
  SOURCE = 'ab\\\cd';
begin
  SomeText := SOURCE;
  while Pos('\\', SomeText) > 0 do
    SomeText := StringReplace(SomeText, '\\', '\', [rfReplaceAll]);

  Writeln('WHILE: ', SomeText);

  SomeText := SOURCE;
  SomeText := StringReplace(SomeText, '\\', '\', [rfReplaceAll]);
  Writeln('DIRECT: ', SomeText);
end;

...:cat:...

[uligerhardt]

Schuss ins Blaue: PathCanonicalize ?

[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.

[p80286]

Zitat:

Zitat von nahpets (Beitrag 1380947)

. 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.

:gruebel: also ist Datei...txt das gleiche wie ..\Datei.txt ?
Krass!!

Gruß
K-H

[nahpets]

Nein, das ist nicht das Gleiche. Es können aber in einem Dateinamen beliebig viele Punkte enthalten sein. Ein Dateiname darf sogar mit mehreren Punkten beginnen.
Damit kein Konflikt mit . .. ... auftritt muss "irgendwo am Ende" noch was anderes, als ein Punkt folgen, was grundsätzlich in Dateinamen zulässig ist.

[Luckie]

Einfache Lösung: Einen "Öffnen-Dialog" bereitstellen und keine Eingabe zu lassen. Vorteil: Man braucht den Pfad nicht zu validieren. Nachteil: Ein 'Reinkopieren' geht nicht. Lässt man eine Eingabe zu, hat man eventuell syntaktisch ungültige Pfade. Kann man versuchen abzufangen mit 'Bereinigen' oder 'Säubern'. Aber das ist nicht so einfach, wie wir gesehen haben. Will man es richtig machen, bedeutet das einen ziemlichen Aufwand. Und jeder Kompromiss endet nur in einer halb herzigen Umsetzung.

Man kann jetzt überlegen. Sind meine Anwender technisch so versiert, dass sie einen fehlerhaften Pfad korrigieren können? Oder sind es DAUs, die ich mit einer Fehlermeldung überfordere? Könnte ein nicht korrekter Pfad eine Sicherheitslücke bedeuten? Könnte ein nicht korrekter Pfad das Programm 'aus dem Tritt' bringen?

Ein interessantes, nicht triviales Problem.

[Glados]

Zitat:

Man kann jetzt überlegen. Sind meine Anwender technisch so versiert, dass sie einen fehlerhaften Pfad korrigieren können? Oder sind es DAUs, die ich mit einer Fehlermeldung überfordere? Könnte ein nicht korrekter Pfad eine Sicherheitslücke bedeuten? Könnte ein nicht korrekter Pfad das Programm 'aus dem Tritt' bringen?

Ich denke das triffts auf den Punkt genau.

Ich bin für letzteres, also für die DAUs und Fehlermeldungen/Auto-Korrekturen unter bestimmten Regeln soweit wie möglich.

[Codehunter]

Was machst du, wenn deine Putzfrau beim Saubermachen auf eine Konstellation trifft, wo ein "unsauberer" Pfad bereinigt auf mehrere real existierende Verzeichnisse trifft? Zeigst du dann eine Auswahl an, welche der Möglichkeiten denn nun die richtige sein soll? Oder pickst du dir nach dem Zufallsprinzip eine der Varianten heraus?

Ich denke, das führt zu nichts. Denn einerseits willst du dem Anwender die Möglichkeit einer Freitext-Eingabe ermöglichen, andererseits aber unterstellst du ihm totale Blödheit. Vielleicht solltest du mit einer Zielgruppen-Analyse beginnen und dann entscheiden, welche Art Pfadeingabe am besten geeignet ist.

Mir persönlich würde jedenfalls ein Programm auf den Keks gehen und schleunigst ausgemustert werden, das mir meine mühsam handgetippten Pfade verbiegt. Warum? Ganz einfach: Weil ich Vertipper im Fehlerfall treffsicherer selbst korrigiere.

Letztlich reflektiert ein Dateipfad ein real exisitierendes Dateisystem. Warum sollte man die technischen Möglichkeiten nicht nutzen und den Anwender grafisch auswählen lassen? Oder geht es dir mehr darum, noch nicht existierende Ordnerstrukturen z.B. mit ForceDirectories anzulegen?