Freigeben über

Benennen und Verweisen auf Freigaben, Verzeichnisse, Dateien und Metadaten

  • Artikel

Ein Speicherkonto kann null oder mehr Azure-Dateifreigaben enthalten. Eine Freigabe enthält Eigenschaften, Metadaten und keine oder mehr Dateien oder Verzeichnisse. Ein Verzeichnis enthält Eigenschaften und keine oder mehr Dateien oder Verzeichnisse. Eine Datei ist jede einzelne Entität, die aus Binärdaten, Eigenschaften und Metadaten besteht.

Ressourcennamen

Der URI zum Verweisen auf eine Freigabe, ein Verzeichnis oder eine Datei muss eindeutig sein. Innerhalb eines bestimmten Speicherkontos muss jede Freigabe einen eindeutigen Namen aufweisen. Jede Datei innerhalb einer bestimmten Freigabe oder eines Verzeichnisses muss auch innerhalb dieser Freigabe oder dieses Verzeichnisses einen eindeutigen Namen haben.

Wenn Sie versuchen, eine Freigabe, ein Verzeichnis oder eine Datei mit einem Namen zu erstellen, der gegen die Benennungsregeln verstößt, schlägt die Anforderung mit dem Statuscode 400 (Ungültige Anforderung) fehl.

Freigabenamen

Die Regeln für Dateidienst-Freigabnamen sind restriktiver als durch das SMB-Protokoll für SMB-Freigabenamen vorgeschrieben wird, sodass die Blob- und Dateidienste ähnliche Benennungskonventionen für Container und Freigaben teilen. Die Benennungseinschränkungen für Freigaben lauten wie folgt:

  • Ein Freigabename muss ein gültiger DNS-Name sein.
  • Freigabenamen müssen mit einem Buchstaben oder einer Zahl beginnen und dürfen nur Buchstaben, Zahlen und den Bindestrich/Minuszeichen (-) enthalten.
  • Jedem Bindestrich/Minuszeichen (-) muss sofort ein Buchstabe oder eine Zahl gefolgt sein; Aufeinanderfolgende Bindestriche sind in Freigabenamen nicht zulässig.
  • Alle Buchstaben in einem Freigabenamen müssen Kleinbuchstaben sein.
  • Freigabenamen müssen eine Länge zwischen 3 und 63 Zeichen aufweisen.

In der folgenden Tabelle werden die Benennungseinschränkungen für Azure Files und Azure Blob Storage verglichen:

Benennen von Containern, BLOBs und Metadaten und Verweisen auf diese SMB-Freigabenamenseinschränkungen
• Ein Containername muss ein gültiger DNS-Name sein.
• Containernamen müssen mit einem Buchstaben oder einer Zahl beginnen und dürfen nur Buchstaben, Zahlen und den Bindestrich/Minuszeichen (-) enthalten.
• Jedem Bindestrich/Minuszeichen (-) muss ein Buchstabe oder eine Zahl unmittelbar vorangestellt werden; Aufeinanderfolgende Bindestriche sind in Containernamen nicht zulässig.
• Alle Buchstaben in einem Containernamen müssen Kleinbuchstaben sein.
• Containernamen müssen 3 bis 63 Zeichen lang sein.		 • Ein Freigabename darf nicht mehr als 80 Zeichen lang sein.
• Die folgenden Zeichen sind in einem Freigabenamen unzulässig: \ / [ ] : ¦ < > + = ; , * ? "
• Steuerzeichen im Bereich 0x00 bis einschließlich 0x1F sind in einem Freigabenamen unzulässig.
• Alle anderen Unicode-Zeichen sind legal.
• Bei Namen wird die Groß-/Kleinschreibung beibehalten und die Groß-/Kleinschreibung wird nicht beachtet.

Verzeichnis- und Dateinamen

Azure Files erzwingt die folgenden Benennungsregeln für Verzeichnis- und Dateinamen:

  • Verzeichnis- und Dateinamen behalten Groß-/Kleinschreibung bei, unterscheiden aber nicht danach.
  • Verzeichnis- und Dateikomponentennamen dürfen nicht länger als 255 Zeichen sein.
  • Verzeichnisnamen können nicht mit dem Schrägstrich (/) enden. Falls eingegeben, erfolgt eine automatische Entfernung.
  • Dateinamen dürfen nicht mit dem Schrägstrich (/) enden.
  • Reservierte URL-Zeichen müssen korrekt mit Escapezeichen versehen sein.
  • Die folgenden Zeichen sind nicht zulässig: " \ / : | < > * ?
  • Ungültige Zeichen im URL-Pfad sind unzulässig. Codepunkte wie \uE000, die in NTFS-Dateinamen gültig sind, sind keine gültigen Unicode-Zeichen. Darüber hinaus sind einige ASCII- oder Unicode-Zeichen wie Steuerzeichen (0x00 bis 0x1F) ebenfalls nicht zulässig. Regeln für Unicode-Zeichenfolgen in HTTP/1.1 finden Sie unter RFC 2616, Abschnitt 2.2: Grundregeln und RFC 3987.
  • Ungültige Unicode-Zeichen (als ungültige Ersatzpaare bezeichnet) werden nicht unterstützt.
  • Die folgenden Dateinamen sind nicht zulässig: LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, PRN, AUX, NUL, CON, CLOCK$, dot character (.) und zwei Punktzeichen (.).
  • Ab Version 2021-12-02 unterstützen Verzeichnis- und Dateinamen U+FFFE- und U+FFFF-Zeichen über alle Vorgänge. Diese Zeichen werden auch über SMB- und REST-Protokolle unterstützt. Listenverzeichnis- und Datei- und Listenhandlesvorgänge benötigen eine spezielle Behandlung für diese Zeichen, wie in der jeweiligen Dokumentation erwähnt.

Standardmäßig werden Punktzeichen (.) am Ende des Verzeichnisses und der Dateinamen in Anforderungs-URLs ignoriert oder weggelassen.

  • Wenn beispielsweise eine Datei mit dem Namen file1... erstellt wird, werden die Punkte am Ende ignoriert, und eine Datei mit dem Namen file1 wird erstellt. Gleiches gilt für Verzeichnisse im Pfad. Wenn eine Dateierstellungsanforderung den Pfad \Dir1\Dir2…\File1 enthält, wird die Datei unter \Dir1\Dir2\File1erstellt.
  • Ab Version 2022-11-02 kann das Standardverhalten jedoch überschrieben werden, indem der Header x-ms-allow-trailing-dot in der URL-Anforderung auf true festgelegt wird.
  • Wenn Sie beispielsweise eine Datei mit dem Namen file1... erstellen und die nachfolgenden Punkte einschließen möchten, sollte die in den x-ms-allow-trailing-dot Anforderungsheader aufgenommen und auf festgelegt werden true. Gleiches gilt für das Erstellen von Verzeichnisnamen.
  • Wenn Sie im Fall einer Dateikopieranforderung nachfolgende Punkte in den Namen der Quelldatei einschließen möchten, muss der x-ms-source-allow-trailing-dot Header auf truefestgelegt werden. Weitere Informationen finden Sie in den verfügbaren Headeroptionen für jede einzelne REST-API.

In der folgenden Tabelle werden die Benennungseinschränkungen für Azure Files und Azure Blob Storage verglichen:

Benennen von Containern, BLOBs und Metadaten und Verweisen auf diese SMB-Protokollnamenseinschränkungen
• Ein Blobname muss mindestens ein Zeichen lang sein und darf nicht mehr als 1.024 Zeichen lang sein.
• Bei Blobnamen wird die Groß-/Kleinschreibung beachtet.
• Reservierte URL-Zeichen müssen ordnungsgemäß mit Escape versehen werden.
• Blobnamen können mit einem Virtuellen Verzeichnistrennzeichen enden, z. B. einem Schrägstrich (/)
• Ungültige URL-Pfadzeichen sind nicht zulässig: Codepunkte wie \uE000, obwohl sie in NTFS-Dateinamen gültig sind, sind keine gültigen Unicode-Zeichen. Darüber hinaus sind einige ASCII- oder Unicode-Zeichen, z. B. Steuerzeichen (0x00 bis 0x1F), ebenfalls nicht zulässig. Regeln für Unicode-Zeichenfolgen in HTTP/1.1 finden Sie unter RFC 2616, Abschnitt 2.2: Grundregeln und RFC 3987.		 • Ein Pfadname darf nicht mehr als 32.760 Zeichen lang sein.
• Jede Pfadnamenkomponente (Datei/Verzeichnis) darf nicht mehr als 255 Zeichen lang sein.
• Ein Pfadname besteht aus einer oder mehreren Pfadnamenkomponenten, die durch das Schrägstrichzeichen (\) getrennt sind.
• Beim Pfadnamen wird die Groß-/Kleinschreibung beibehalten und die Groß-/Kleinschreibung wird nicht beachtet (zwei Namen, die sich nur unterscheiden, wenn dies nicht zulässig ist).
• Es kann kein Verzeichnispfad vorhanden sein, der mit einem Dateipfad identisch ist.
• Die folgenden Zeichen sind in einem Komponentennamen unzulässig: \ / : ¦ < > * ? "
• Steuerzeichen im Bereich 0x00 bis einschließlich 0x1F sind in einem Freigabenamen unzulässig.

Pfadnamen

Ein Pfadname besteht aus einer oder mehreren Pfadnamenkomponenten (Verzeichnis- oder Dateiname), die durch das Schrägstrichzeichen (/) getrennt sind. Alle Pfadnamenkomponenten mit Ausnahme der Komponente des letzten Pfadnamens bezeichnen Verzeichnisse. Die letzte Pfadnamenkomponente kennzeichnet ein Verzeichnis oder eine Datei. Die folgenden Benennungsregeln gelten:

  • Ein Pfadname darf nicht mehr als 2.048 Zeichen lang sein. Einzelne Komponenten im Pfad können maximal 255 Zeichen lang sein.
  • Ein Pfadname besteht aus einer oder mehreren Pfadnamenkomponenten, die durch das Schrägstrichzeichen (/) getrennt sind.
  • Die Tiefe der Unterverzeichnisse im Pfad darf 250 nicht überschreiten.
  • Derselbe Name kann nicht für eine Datei und ein Verzeichnis verwendet werden, die dasselbe übergeordnete Verzeichnis verwenden. Beispielsweise können eine Datei und ein Verzeichnis, die jeweils benannt data sind, nicht unter demselben übergeordneten Pfad vorhanden sein.

Metadatennamen

Metadaten für eine Freigabe- oder Dateiressource werden als Name-Wert-Paare gespeichert, die der Ressource zugeordnet sind. Metadatennamen müssen den Benennungsregeln für C#-Bezeichner entsprechen.

Beachten Sie, dass für Metadatennamen die Groß-/Kleinschreibung beibehalten wird, die bei der Erstellung verwendet wurde. Beim Festlegen oder Lesen wird die Groß-/Kleinschreibung aber nicht berücksichtigt. Wenn zwei oder mehr Metadatenheader mit demselben Namen für eine Ressource gesendet werden, gibt der Azure-Dateidienst den Statuscode 400 zurück (Ungültige Anforderung).

Ressourcen-URI-Syntax

Jede Ressource weist einen entsprechenden Basis-URI auf, der auf die Ressource selbst verweist. Für das Speicherkonto schließt der Basis-URI nur den Namen des Kontos ein:

https://myaccount.file.core.windows.net

Bei einer Freigabe enthält der Basis-URI den Namen des Kontos und den Namen der Freigabe:

https://myaccount.file.core.windows.net/myshare

Für ein Verzeichnis schließt der Basis-URI den Namen des Kontos, den Namen der Freigabe und den Pfad des Verzeichnisses ein:

https://myaccount.file.core.windows.net/myshare/myparentdir/mydir

Für eine Datei schließt der Basis-URI den Namen des Kontos, den Namen der Freigabe und den Pfad der Datei ein:

https://myaccount.file.core.windows.net/myshare/myfile  
https://myaccount.file.core.windows.net/myshare/mydir/myfile  
https://myaccount.file.core.windows.net/myshare/myparentdir/mydir/myfile

Weitere Informationen