Benennen von Dateien, Pfaden und Namespaces
Die von Windows unterstützten Dateisysteme verwenden das Konzept von Dateien und Verzeichnissen, um auf Daten zuzugreifen, die auf einem Datenträger oder Gerät gespeichert sind. Windows-Entwickler, die mit den Windows-APIs für Datei- und Geräte-E/A arbeiten, sollten die Regeln, Konventionen und Einschränkungen von Namen für Dateien und Verzeichnisse verstehen.
Auf Daten kann über Datenträger, Geräte und Netzwerkfreigaben über Datei-E/A-APIs zugegriffen werden. Dateien und Verzeichnisse sowie Namespaces sind Teil des Konzepts eines Pfads. Dabei handelt es sich um eine Zeichenfolgendarstellung, wo die Daten abgerufen werden sollen, unabhängig davon, ob sie von einem Datenträger, einem Gerät oder einer Netzwerkverbindung für einen bestimmten Vorgang stammen.
Einige Dateisysteme, z. B. NTFS, unterstützen verknüpfte Dateien und Verzeichnisse, die auch Dateibenennungskonventionen und -regeln folgen, genau wie eine normale Datei oder ein Verzeichnis. Weitere Informationen finden Sie unter Feste Links und Verbindungen und Analysepunkte und Dateivorgänge.
Informationen zum Konfigurieren von Windows zur Unterstützung langer Dateipfade finden Sie unter Maximale Begrenzung der Pfadlänge.
Datei- und Verzeichnisnamen
Alle Dateisysteme folgen den gleichen allgemeinen Benennungskonventionen für eine einzelne Datei: ein Basisdateiname und eine optionale Erweiterung, getrennt durch einen Punkt. Jedes Dateisystem, z. B. NTFS, CDFS, exFAT, UDFS, FAT und FAT32, kann jedoch spezifische und unterschiedliche Regeln für die Bildung der einzelnen Komponenten im Pfad zu einem Verzeichnis oder einer Datei aufweisen. Beachten Sie, dass ein Verzeichnis einfach eine Datei mit einem speziellen Attribut ist, das es als Verzeichnis bezeichnet, andernfalls jedoch dieselben Benennungsregeln wie eine reguläre Datei befolgen muss. Da sich der Begriff Verzeichnis einfach auf einen speziellen Dateityp bezieht, was das Dateisystem betrifft, verwenden einige Referenzmaterialien den allgemeinen Begriff Datei, um sowohl Konzepte von Verzeichnissen als auch Datendateien als solche zu umfassen. Aus diesem Grund sollten, sofern nicht anders angegeben, alle Benennungs- oder Verwendungsregeln oder Beispiele für eine Datei auch für ein Verzeichnis gelten. Der Begriff Pfad bezieht sich auf ein oder mehrere Verzeichnisse, umgekehrte Schrägstriche und möglicherweise einen Volumenamen. Weitere Informationen finden Sie im Abschnitt Paths.
Einschränkungen für die Zeichenanzahl können auch unterschiedlich sein und je nach verwendetem Dateisystem und Pfadnamenpräfixformat variieren. Dies wird durch die Unterstützung von Abwärtskompatibilitätsmechanismen noch komplizierter. Beispielsweise unterstützt das ältere MS-DOS FAT-Dateisystem maximal 8 Zeichen für den Basisdateinamen und 3 Zeichen für die Erweiterung, insgesamt 12 Zeichen einschließlich des Punkttrennzeichens. Dies wird allgemein als Dateiname 8.3 bezeichnet. Die Windows FAT- und NTFS-Dateisysteme sind nicht auf 8.3-Dateinamen beschränkt, da sie lange Dateinamen unterstützen, aber sie unterstützen weiterhin die Version 8.3 von langen Dateinamen.
Namenskonventionen
Mit den folgenden grundlegenden Regeln können Anwendungen unabhängig vom Dateisystem gültige Namen für Dateien und Verzeichnisse erstellen und verarbeiten:
Verwenden Sie einen Punkt, um den Namen der Basisdatei von der Erweiterung im Namen eines Verzeichnisses oder einer Datei zu trennen.
Verwenden Sie einen umgekehrten Schrägstrich (\), um die Komponenten eines Pfads zu trennen. Der umgekehrte Schrägstrich unterteilt den Dateinamen aus dem Pfad und einen Verzeichnisnamen aus einem anderen Verzeichnisnamen in einem Pfad. Sie können keinen umgekehrten Schrägstrich im Namen für die tatsächliche Datei oder das eigentliche Verzeichnis verwenden, da es sich um ein reserviertes Zeichen handelt, das die Namen in Komponenten trennt.
Verwenden Sie einen umgekehrten Schrägstrich nach Bedarf als Teil von Volumenamen, z. B. "C:\". in "C:\path\file" oder "\\server\share" in "\\server\share\path\file" für UNC-Namen (Universal Naming Convention) Weitere Informationen zu UNC-Namen finden Sie im Abschnitt Maximale Pfadlängenbegrenzung.
Gehen Sie nicht von Der Groß-/Kleinschreibung aus. Betrachten Sie beispielsweise die Namen OSCAR, Oscar und oscar als identisch, auch wenn einige Dateisysteme (z. B. ein POSIX-kompatibles Dateisystem) diese als unterschiedlich betrachten. Beachten Sie, dass NTFS POSIX-Semantik für die Groß-/Kleinschreibung unterstützt, dies ist jedoch nicht das Standardverhalten. Weitere Informationen finden Sie unter CreateFile.
Volume-Bezeichner (Laufwerkbuchstaben) unterscheiden die Groß-/Kleinschreibung ebenfalls nicht. Beispiel: "D:\" und "d:\" verweisen auf dasselbe Volume.
Verwenden Sie ein beliebiges Zeichen auf der aktuellen Codepage für einen Namen, einschließlich Unicode-Zeichen und Zeichen im erweiterten Zeichensatz (128–255), mit Ausnahme von folgendem:
Die folgenden reservierten Zeichen:
- < (kleiner als)
- Größer als >
- : (Doppelpunkt)
- " (doppeltes Anführungszeichen)
- / (Schrägstrich)
- \ (umgekehrter Schrägstrich)
- | (vertikaler Balken oder Pipe)
- ? (Fragezeichen)
- * (Sternchen)
Ganzzahliger Wert null, manchmal auch als ASCII-NUL-Zeichen bezeichnet.
Zeichen, deren ganzzahlige Darstellungen im Bereich von 1 bis 31 liegen, mit Ausnahme alternativer Datenströme, in denen diese Zeichen zulässig sind. Weitere Informationen zu Dateidatenströmen finden Sie unter Dateidatenströme.
Alle anderen Zeichen, die das Zieldateisystem nicht zulässt.
Verwenden Sie einen Punkt als Verzeichniskomponente in einem Pfad, um das aktuelle Verzeichnis darzustellen, z. B. ".\temp.txt". Weitere Informationen finden Sie unter Paths.
Verwenden Sie zwei aufeinanderfolgende Punkte (..) als Verzeichniskomponente in einem Pfad, um das übergeordnete Element des aktuellen Verzeichnisses darzustellen, z. B. ".. \temp.txt". Weitere Informationen finden Sie unter Paths.
Verwenden Sie nicht die folgenden reservierten Namen für den Namen einer Datei:
CON, PRN, AUX, NUL, COM0, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, COM¹, COM², COM³, LPT0, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9, LPT¹, LPT², and LPT³. Vermeiden Sie auch diese Namen, gefolgt von einer Erweiterung. beispielsweise sind NUL.txt und NUL.tar.gz äquivalent zu NUL. Weitere Informationen finden Sie unter Namespaces.
Hinweis
Windows erkennt die hochgestellten 8-Bit ISO/IEC 8859-1-Ziffern ¹, ² und ³ als Ziffern und behandelt sie als gültige Teile von COM#- und LPT#-Gerätenamen, wodurch sie in jedem Verzeichnis reserviert werden. Z. B.
echo test > COM¹
kann keine Datei erstellen.Beenden Sie einen Datei- oder Verzeichnisnamen nicht mit einem Leerzeichen oder einem Punkt. Obwohl das zugrunde liegende Dateisystem solche Namen möglicherweise unterstützt, trifft dies für Windows-Shell und die Benutzeroberfläche nicht zu. Es ist jedoch akzeptabel, einen Punkt als erstes Zeichen eines Namens anzugeben. Beispiel: ".temp".
Kurze vs. Lange Namen
Ein langer Dateiname wird als ein beliebiger Dateiname betrachtet, der die kurze Benennungskonvention im MS-DOS-Format (auch als 8.3 bezeichnet) überschreitet. Wenn Sie einen langen Dateinamen erstellen, erstellt Windows möglicherweise auch eine kurze 8.3-Form des Namens, den Alias 8.3 oder den kurzen Namen, und speichern Sie ihn auch auf dem Datenträger. Dieses 8.3-Aliasing kann aus Leistungsgründen entweder systemweit oder für ein angegebenes Volumen deaktiviert werden, abhängig vom jeweiligen Dateisystem.
Windows Server 2008, Windows Vista, Windows Server 2003 und Windows XP: 8.3-Aliasing kann für bestimmte Volumes erst unter Windows 7 und Windows Server 2008 R2 deaktiviert werden.
Auf vielen Dateisystemen enthält ein Dateiname eine Tilde (~) in jeder Komponente des Namens, die zu lang ist, um die Benennungsregeln von 8.3 zu erfüllen.
Hinweis
Nicht alle Dateisysteme folgen der Tildeersetzungskonvention, und Systeme können so konfiguriert werden, dass die Aliasgenerierung von Version 8.3 deaktiviert wird, auch wenn sie dies normalerweise unterstützen. Gehen Sie daher nicht davon aus, dass der 8.3-Alias bereits auf dem Datenträger vorhanden ist.
Wenn Sie 8.3-Dateinamen, lange Dateinamen oder den vollständigen Pfad einer Datei vom System anfordern möchten, sollten Sie die folgenden Optionen in Betracht ziehen:
- Verwenden Sie die Funktion GetShortPathName, um die Form 8.3 eines langen Dateinamens abzurufen.
- Verwenden Sie die Funktion GetLongPathName, um die Version des langen Dateinamens eines kurzen Namens abzurufen.
- Um den vollständigen Pfad zu einer Datei abzurufen, verwenden Sie die Funktion GetFullPathName.
Auf neueren Dateisystemen wie NTFS, exFAT, UDFS und FAT32 speichert Windows die langen Dateinamen auf dem Datenträger in Unicode, was bedeutet, dass der ursprüngliche lange Dateinamen immer beibehalten wird. Dies gilt auch dann, wenn ein langer Dateiname erweiterte Zeichen enthält, unabhängig von der Codepage, die während eines Lese- oder Schreibvorgangs des Datenträgers aktiv ist.
Dateien mit langen Dateinamen können zwischen NTFS-Dateisystempartitionen und Windows FAT-Dateisystempartitionen kopiert werden, ohne dass Dateinameninformationen verloren gehen. Dies gilt möglicherweise nicht für die ältere MS-DOS FAT und einige Arten von CDFS -Dateisystemen (CD-ROM), abhängig vom tatsächlichen Dateinamen. In diesem Fall wird der kurze Dateiname nach Möglichkeit ersetzt.
Paths
Der Pfad zu einer angegebenen Datei besteht aus einer oder mehreren Komponenten, die durch ein Sonderzeichen (umgekehrter Schrägstrich) getrennt sind, wobei jede Komponente in der Regel ein Verzeichnisname oder Dateinamen ist, aber mit einigen beachtenswerten Ausnahmen, die unten erläutert werden. Für die Systeminterpretation eines Pfads ist es häufig entscheidend, wie der Anfang oder das Präfix des Pfads aussieht. Dieses Präfix bestimmt den Namespace, den der Pfad verwendet, und darüber hinaus, welche Sonderzeichen an welcher Position innerhalb des Pfads verwendet werden, einschließlich des letzten Zeichens.
Wenn eine Komponente eines Pfads ein Dateiname ist, muss es sich um die letzte Komponente handeln.
Jede Komponente eines Pfads wird auch durch die maximale Länge eingeschränkt, die für ein bestimmtes Dateisystem angegeben ist. Im Allgemeinen fallen diese Regeln in zwei Kategorien: kurz und lang. Beachten Sie, dass Verzeichnisnamen vom Dateisystem als spezieller Dateityp gespeichert werden, die Benennungsregeln für Dateien gelten jedoch auch für Verzeichnisnamen. Zusammenfassend ist ein Pfad einfach die Zeichenfolgendarstellung der Hierarchie zwischen allen Verzeichnissen, die für einen bestimmten Datei- oder Verzeichnisnamen vorhanden sind.
Vollqualifizierte vs. Relative Pfade
Bei Windows-API-Funktionen, die Dateien bearbeiten, können Dateinamen häufig relativ zum aktuellen Verzeichnis sein, während einige APIs einen vollqualifizierten Pfad erfordern. Ein Dateiname ist relativ zum aktuellen Verzeichnis, wenn er nicht mit einem der folgenden beginnt:
- Ein UNC-Name eines beliebigen Formats, der immer mit zwei umgekehrten Schrägstrichzeichen ("\\") beginnt. Weitere Informationen finden Sie im nächsten Abschnitt.
- Ein Datenträger-Bezeichner mit einem umgekehrten Schrägstrich, z. B. "C:\" oder "d:\".
- Ein einzelner umgekehrter Schrägstrich, z. B. "\directory" oder "\file.txt". Dies wird auch als absoluter Pfad bezeichnet.
Wenn ein Dateiname nur mit einem Datenträger-Bezeichner beginnt, aber nicht mit dem umgekehrten Schrägstrich nach dem Doppelpunkt, wird er als relativer Pfad zum aktuellen Verzeichnis auf dem Laufwerk mit dem angegebenen Buchstaben interpretiert. Beachten Sie, dass das aktuelle Verzeichnis das Stammverzeichnis sein kann oder nicht, je nachdem, auf was es während des letzten Vorgangs "Verzeichnis wechseln" auf diesem Datenträger festgelegt wurde. Beispiele für dieses Format sind wie folgt:
- "C:tmp.txt" bezieht sich auf eine Datei namens "tmp.txt" im aktuellen Verzeichnis auf Laufwerk C.
- "C:tempdir\tmp.txt" bezieht sich auf eine Datei in einem Unterverzeichnis des aktuellen Verzeichnisses auf Laufwerk C.
Ein Pfad wird auch als relativ bezeichnet, wenn er "doppelte Punkte" enthält; Das heißt, zwei Punkte in einer Komponente des Pfads. Dieser spezielle Bezeichner wird verwendet, um das Verzeichnis über dem aktuellen Verzeichnis zu kennzeichnen, das auch als "übergeordnetes Verzeichnis" bezeichnet wird. Beispiele für dieses Format sind wie folgt:
- ".. \tmp.txt" gibt eine Datei namens tmp.txt an, die sich im übergeordneten Verzeichnis befindet.
- ".. \.. \tmp.txt" gibt eine Datei an, die sich in zwei Verzeichnissen oberhalb des aktuellen Verzeichnisses befindet.
- ".. \tempdir\tmp.txt" gibt eine Datei namens tmp.txt in einem Verzeichnis namens tempdir an, das ein Peerverzeichnis zum aktuellen Verzeichnis ist.
Relative Pfade können beide Beispieltypen kombinieren, z. B. "C:..\tmp.txt". Dies ist nützlich, da das System zwar das aktuelle Laufwerk zusammen mit dem aktuellen Verzeichnis dieses Laufwerks nachverfolgt, aber auch die aktuellen Verzeichnisse in jedem der verschiedenen Laufwerkbuchstaben nachverfolgt (wenn Ihr System mehrere hat), unabhängig davon, welcher Laufwerkskennzeichner als aktuelles Laufwerk festgelegt ist.
Maximale Längenbeschränkung für Pfade
In Windows-Editionen vor Windows 10 Version 1607 beträgt die maximale Länge für einen Pfad MAX_PATH, der als 260 Zeichen definiert ist. In späteren Versionen von Windows ist das Ändern eines Registrierungsschlüssels oder die Verwendung des Gruppenrichtlinie-Tools erforderlich, um den Grenzwert zu entfernen. Ausführliche Informationen finden Sie unter Maximale Längenbeschränkung für Pfade.
Namespaces
Es gibt zwei wesentliche Kategorien von Namespacekonventionen, die in den Windows-APIs verwendet werden, die häufig als NT-Namespaces und win32-Namespaces bezeichnet werden. Der NT-Namespace wurde so konzipiert, dass er der Namespace der niedrigsten Ebene ist, auf dem andere Subsysteme und Namespaces vorhanden sein können, einschließlich des Win32-Subsystems und der Win32-Namespaces. POSIX ist ein weiteres Beispiel für ein Subsystem in Windows, das auf dem NT-Namespace basiert. Frühe Versionen von Windows definierten auch mehrere vordefinierte oder reservierte Namen für bestimmte spezielle Geräte, wie z. B. Kommunikationsports (serielle und parallele) Ports und die Standardanzeigekonsole als Teil des heutigen NT-Gerätenamespace, und werden in aktuellen Versionen von Windows aus Gründen der Abwärtskompatibilität weiterhin unterstützt.
Win32-Dateinamespaces
Die Präfixe und Konventionen des Win32-Namespaces sind in diesem Und im folgenden Abschnitt mit Beschreibungen ihrer Verwendung zusammengefasst. Beachten Sie, dass diese Beispiele für die Verwendung mit den Windows-API-Funktionen vorgesehen sind und nicht alle mit Windows-Shellanwendungen wie Windows Explorer funktionieren. Aus diesem Grund gibt es eine größere Palette möglicher Pfade, als normalerweise von Windows-Shellanwendungen verfügbar ist, und Windows-Anwendungen, die dies nutzen, können mit diesen Namespacekonventionen entwickelt werden.
Bei Datei-E/A weist das Präfix "\\?\" zu einer Pfadzeichenfolge die Windows-APIs an, alle Zeichenfolgenanalyse zu deaktivieren und die darauf folgende Zeichenfolge direkt an das Dateisystem zu senden. Wenn das Dateisystem beispielsweise große Pfade und Dateinamen unterstützt, können Sie die MAX_PATH Grenzwerte überschreiten, die andernfalls von den Windows-APIs erzwungen werden.
Da die automatische Erweiterung der Pfadzeichenfolge deaktiviert wird, ermöglicht das Präfix "\\?\" auch die Verwendung von ".." und "." in den Pfadnamen. Dies kann hilfreich sein, wenn Sie versuchen, Vorgänge für eine Datei mit diesen ansonsten reservierten relativen Pfadspezifizierern als Teil des vollqualifizierten Pfads auszuführen.
Viele, aber nicht alle Datei-E/A-APIs unterstützen "\\?\"; Sie sollten sich das Referenzthema für jede API ansehen, um sicher zu sein.
Beachten Sie, dass Unicode-APIs verwendet werden sollten, um sicherzustellen, dass das Präfix "\\?\" Ihnen ermöglicht, die MAX_PATH-Grenzwerte zu überschreiten.
Win32-Gerätenamespaces
Das Präfix "\\.\" greift auf den Win32-Gerätenamespace statt auf den Win32-Dateinamespace zu. So erfolgt der Zugriff auf physische Datenträger und Volumes direkt, ohne das Dateisystem zu durchlaufen, wenn die API diese Zugriffsart unterstützt. Auf diese Weise können Sie auf viele andere Geräte als Datenträger zugreifen (z. B. mit den Funktionen CreateFile und DefineDosDevice).
Wenn Sie beispielsweise den seriellen Kommunikationsport 1 des Systems öffnen möchten, können Sie "COM1" im Aufruf der Funktion CreateFile verwenden. Dies funktioniert, da COM1–COM9 Teil der reservierten Namen im NT-Namespace ist, obwohl die Verwendung des Präfixes "\\.\" auch mit diesen Gerätenamen funktioniert. Wenn Sie dagegen ein serielles Erweiterungsboard mit 100 Ports installiert haben und COM56 öffnen möchten, können Sie es nicht mit "COM56" öffnen, da kein vordefinierter NT-Namespace für COM56 vorhanden ist. Sie müssen es mit "\.\COM56" öffnen, da "\\.\" direkt in den Gerätenamespace wechselt, ohne zu versuchen, einen vordefinierten Alias zu suchen.
Ein weiteres Beispiel für die Verwendung des Win32-Gerätenamespace ist die Verwendung der Funktion CreateFile mit "\.\PhysicalDriveX" (wobei X ein gültiger ganzzahliger Wert ist) oder "\\.\CdRomX". Dadurch können Sie direkt auf diese Geräte zugreifen und das Dateisystem umgehen. Dies funktioniert, da diese Gerätenamen vom System erstellt werden, da diese Geräte aufgelistet werden, und einige Treiber auch andere Aliase im System erstellen. Beispielsweise der Gerätetreiber, der den Namen "C:\" implementiert. verfügt über einen eigenen Namespace, der auch das Dateisystem ist.
APIs, die die Funktion CreateFile durchlaufen, funktionieren in der Regel mit dem Präfix "\\.\", da CreateFile abhängig von den verwendeten Parametern die Funktion zum Öffnen von Dateien und Geräten ist.
Wenn Sie mit Windows-API-Funktionen arbeiten, sollten Sie das Präfix "\\.\" verwenden, um nur auf Geräte und nicht auf Dateien zuzugreifen.
Die meisten APIs unterstützen "\\.\"; nur diejenigen, die für die Verwendung mit dem Gerätenamespace konzipiert sind, erkennen dies. Überprüfen Sie immer das Referenzthema für jede API, um sicher zu sein.
NT Namespaces
Es gibt auch APIs, die die Verwendung der NT-Namespacekonvention zulassen, aber der Windows-Objekt-Manager macht dies in den meisten Fällen überflüssig. Zur Veranschaulichung ist es nützlich, die Windows-Namespaces im Systemobjektbrowser mit dem Windows Sysinternals Tools WinObj zu durchsuchen. Wenn Sie dieses Tool ausführen, wird der NT-Namespace angezeigt, der am Stamm beginnt, oder "\". Im Unterordner "Global??" befindet sich der Win32-Namespace. Benannte Geräteobjekte befinden sich im NT-Namespace im Unterverzeichnis "Device". Hier finden Sie auch Serial0 und Serial1, die Geräteobjekte, die die ersten beiden COM-Ports darstellen, sofern auf Ihrem System vorhanden. Ein Geräteobjekt, das ein Volume darstellt, wäre etwa "HarddiskVolume1", obwohl das numerische Suffix variieren kann. Der Name "DR0" im Unterverzeichnis "Harddisk0" ist ein Beispiel für das Geräteobjekt, das einen Datenträger darstellt usw.
Um diese Geräteobjekte für Windows-Anwendungen zugänglich zu machen, erstellen die Gerätetreiber einen symbolischen Link (symlink) im Win32-Namespace , "Global??", zu ihren jeweiligen Geräteobjekten. Beispielsweise sind COM0 und COM1 unter dem Unterverzeichnis "Global??" einfach Symlinks zu Serial0 und Serial1, "C:" ist ein Symlink zu HarddiskVolume1, "Physicaldrive0" ist ein Symlink zu DR0 usw. Ohne einen Symlink steht ein angegebenes Gerät "Xxx" für keine Windows-Anwendung mit Win32-Namespacekonventionen zur Verfügung, wie zuvor beschrieben. Ein Handle kann jedoch mit allen APIs geöffnet werden, die den absoluten Pfad des NT-Namespace im Format "\Device\Xxx" unterstützen.
Mit der Zusätzlichen Unterstützung für mehrere Benutzer über Terminaldienste und virtuelle Computer ist es auch erforderlich geworden, das systemweite Stammgerät im Win32-Namespace zu virtualisieren. Dies wurde erreicht, indem Der Symlink mit dem Namen "GLOBALROOT" zum Win32-Namespace hinzugefügt wurde, den Sie im Unterverzeichnis "Global??" des zuvor beschriebenen WinObj-Browsertools sehen können, und auf den Sie über den Pfad "\\?\GLOBALROOT" zugreifen können. Dieses Präfix stellt sicher, dass der darauf folgende Pfad im wahren Stammpfad des Systemobjekt-Managers und nicht in einem sitzungsabhängigen Pfad sucht.