CanonicalFileUtils.java..- und .-Pfadkomponenten eliminiert und Pfadtrennzeichen über File.getCanonicalPath() normalisiert. Behandelt E/A-Fehler elegant durch Rückgriff auf getAbsolutePath(). Bietet sowohl zeichenkettenbasierte als auch File-Objekt-basierte Überladungen für die Pfadauflösung. Wird überall dort verwendet, wo ProjectForge Dateipfade vergleichen oder eine konsistente Pfaddarstellung sicherstellen muss.java.io.File — JDK-Dateiabstraktionjava.io.IOException — Geprüfte Ausnahme von getCanonicalPath()org.slf4j.Logger — Fehlerprotokollierung für E/A-FehlerGibt den kanonischen Pfad einer Datei als Zeichenkette zurück. Wenn getCanonicalPath() eine IOException auslöst (z. B. wenn die Datei nicht existiert und das Dateisystem ihre kanonische Form nicht auflösen kann), wird auf getAbsolutePath() zurückgegriffen und der Fehler protokolliert.
Gleiche Logik, gibt aber ein File-Objekt über getCanonicalFile() / getAbsoluteFile() zurück.
Bequemlichkeitsüberladung, die einen Zeichenkettenpfad in new File(path) kapselt und an absolute(File) delegiert.
Javas File.getCanonicalPath() bietet mehrere Garantien, die getAbsolutePath() nicht bietet:
. (aktuelles Verzeichnis) und .. (übergeordnetes Verzeichnis) werden aufgelöst// wird zusammengezogenDies ist entscheidend für sicherheitsrelevante Operationen, bei denen Pfade aus Benutzereingaben mit erlaubten Pfaden verglichen werden müssen – zwei unterschiedliche Zeichenkettenrepräsentationen könnten auf dieselbe Datei verweisen (z. B. /home/user/../user/file und /home/user/file).
Die Klasse verwendet ein Muster der eleganten Degradierung: Wenn die kanonische Auflösung fehlschlägt (IOException), wird auf den absoluten Pfad zurückgegriffen und der Fehler protokolliert. Dies ist wichtig, da getCanonicalPath() aus Gründen, die außerhalb der Kontrolle der Anwendung liegen (z. B. Dateisystemberechtigungen, NFS-Mount-Probleme oder nicht vorhandene Datei), eine IOException auslösen kann. Der Rückgriff stellt sicher, dass die Anwendung weiterhin funktioniert, wenn auch mit einem potenziell nicht normalisierten Pfad.
Alle Methoden behandeln null-Eingaben elegant – sie geben null zurück, ohne eine NullPointerException auszulösen. Dies vereinfacht den Aufrufercode, da keine Null-Prüfungen vor dem Aufruf des Dienstprogramms erforderlich sind.
CanonicalFileUtils wird in Szenarien wie diesen verwendet:
..-Durchgriff aus einem Basisverzeichnis ausbrichtInterner Fehler beim Versuch, den kanonischen Pfad zu ermitteln“ ist etwas irreführend – eine IOException von getCanonicalPath() ist nicht unbedingt ein „interner Fehler“, sondern oft eine Umgebungsbedingung (fehlende Datei, fehlende Berechtigung). Der Rückgriff auf getAbsolutePath() akzeptiert stillschweigend einen potenziell nicht normalisierten Pfad.FileHelper-Klasse. Dies folgt dem Prinzip der einzigen Verantwortung (Single Responsibility Principle) und hält Dienstprogramme fokussiert und testbar.868d6abb7 2025 -> 2026 63081666f Quelltextdatei-Header: 2024 -> 2025. b6092df09 Copyright 2023 -> 2024 ab45d51fa Copyright 2001-2022 -> 2001-2023. 5f7ef41b8 Copyright 2021 -> 2022 ceb63e8a1 Quelltext-Header: (C) 2001-2021. 7c79f1922 Copyright des Quelltext-Headers -> 2020. bd25a85fb WIP: Einrichtungsassistent (Swing und Lanterna)