Delen via

Shares, mappen, bestanden en metagegevens een naam geven en hiernaar verwijzen

  • Artikel

Een opslagaccount kan nul of meer Azure-bestandsshares bevatten. Een share bevat eigenschappen, metagegevens en nul of meer bestanden of mappen. Een map bevat eigenschappen en nul of meer bestanden of mappen. Een bestand is één entiteit die bestaat uit binaire gegevens, eigenschappen en metagegevens.

Resourcenamen

De URI die naar een share, map of bestand verwijst, moet uniek zijn. Binnen een bepaald opslagaccount moet elke share een unieke naam hebben. Elk bestand in een bepaalde share of map moet ook een unieke naam binnen die share of map hebben.

Als u probeert een share, map of bestand te maken met een naam die de naamgevingsregels schendt, mislukt de aanvraag met statuscode 400 (Ongeldige aanvraag).

Namen delen

De regels voor bestandsservicesharenamen zijn beperkender dan wat is voorgeschreven door het SMB-protocol voor SMB-sharenamen, zodat de blob- en bestandsservices vergelijkbare naamconventies voor containers en shares kunnen delen. De naamgevingsbeperkingen voor shares zijn als volgt:

  • Een sharenaam moet een geldige DNS-naam zijn.
  • Namen van delen moeten beginnen met een letter of cijfer en mogen alleen letters, cijfers en het afbreekstreepje/minteken (-) bevatten.
  • Elk afbreekstreepje/minteken (-) moet onmiddellijk worden voorafgegaan en gevolgd door een letter of cijfer; opeenvolgende afbreekstreepjes zijn niet toegestaan in sharenamen.
  • Alle letters in een sharenaam moeten kleine letters zijn.
  • Deelnamen moeten tussen 3 en 63 tekens lang zijn.

In de volgende tabel worden de naamgevingsbeperkingen voor Azure Files en Azure Blob Storage vergeleken:

Naamgeving van en verwijzen naar containers, blobs en metagegevens Naambeperkingen voor SMB-share
• Een containernaam moet een geldige DNS-naam zijn.
• Containernamen moeten beginnen met een letter of cijfer en mogen alleen letters, cijfers en het afbreekstreepje/minteken (-) bevatten.
• Elk afbreekstreepje/minteken (-) moet onmiddellijk worden voorafgegaan en gevolgd door een letter of cijfer; opeenvolgende afbreekstreepjes zijn niet toegestaan in containernamen.
• Alle letters in een containernaam moeten uit kleine letters bestaan.
• Containernamen moeten 3 tot 63 tekens lang zijn.		 • Een sharenaam mag niet langer zijn dan 80 tekens.
• De volgende tekens zijn ongeldig in de naam van een share: \ / [ ] : ¦ < > + = ; , * ? "
• Controletekens in het bereik 0x00 tot 0x1F, inclusief, zijn illegaal in een sharenaam.
• Alle andere Unicode-tekens zijn legaal.
• Namen zijn hoofdletterbehoud en hoofdlettergevoelig.

Map- en bestandsnamen

Azure Files dwingt de volgende naamgevingsregels af voor map- en bestandsnamen:

  • Map- en bestandsnamen zijn hoofdletterbewaarbaar en niet hoofdlettergevoelig.
  • Namen van mappen en bestandsonderdelen mogen niet langer zijn dan 255 tekens.
  • Mapnamen mogen niet eindigen met het schuine streepje (/). Indien opgegeven, wordt deze automatisch verwijderd.
  • Bestandsnamen mogen niet eindigen met het schuine streepje (/).
  • Gereserveerde tekens voor URL's moeten op de juiste wijze van een escape-teken zijn voorzien.
  • De volgende tekens zijn niet toegestaan: " \ / : | < > * ?
  • Ongeldige URL-padtekens zijn niet toegestaan. Codepunten zoals \uE000, zijn geldig in NTFS-bestandsnamen, maar zijn geen geldige Unicode-tekens. Bovendien zijn sommige ASCII- of Unicode-tekens, zoals besturingstekens (0x00 tot 0x1F), ook niet toegestaan. Zie RFC 2616, Sectie 2.2: Basisregels en RFC 3987 voor regels voor Unicode-tekenreeksen in HTTP/1.1.
  • Ongeldige Unicode-tekens (ook wel ongeldige surrogaatparen genoemd) worden niet ondersteund.
  • De volgende bestandsnamen zijn niet toegestaan: LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, PRN, AUX, NUL, CON, CLOCK$, puntteken (.) en twee punttekens (..).
  • Vanaf versie 2021-12-02 ondersteunen map- en bestandsnamen U+FFFE- en U+FFFF-tekens via alle bewerkingen. Deze tekens worden ook ondersteund via SMB- en REST-protocollen. De bewerkingen List Directory en Files en List Handles hebben speciale verwerking nodig voor deze tekens, zoals vermeld in hun respectieve documentatie.

Standaard worden punttekens (.) aan het einde van map- en bestandsnamen in aanvraag-URL's genegeerd of weggelaten.

  • Als er bijvoorbeeld een bestand met de naam file1... wordt gemaakt, worden de puntjes aan het einde genegeerd en wordt er een bestand met de naam file1 gemaakt. Hetzelfde geldt voor mappen in het pad. Als een aanvraag voor het maken van een bestand het pad \Dir1\Dir2…\File1 bevat, wordt het bestand gemaakt op \Dir1\Dir2\File1.
  • Vanaf versie 2022-11-02 kan het standaardgedrag echter worden overschreven door de header x-ms-allow-trailing-dot in te true stellen op in de URL-aanvraag.
  • Als u bijvoorbeeld een bestand met de naam file1... wilt maken en de afsluitende puntjes wilt opnemen, moet de worden opgenomen in de x-ms-allow-trailing-dot aanvraagheader en ingesteld op true. Hetzelfde geldt voor het maken van mapnamen.
  • Als u in het geval van een aanvraag voor het kopiëren van een bestand afsluitende puntjes wilt opnemen in de naam van het bronbestand, moet de x-ms-source-allow-trailing-dot header worden ingesteld op true. Bekijk de beschikbare headeropties voor elke afzonderlijke REST API voor meer informatie.

In de volgende tabel worden de naamgevingsbeperkingen voor Azure Files en Azure Blob Storage vergeleken:

Naamgeving van en verwijzen naar containers, blobs en metagegevens Naambeperkingen voor SMB-protocol
• Een blobnaam moet ten minste één teken lang zijn en mag niet langer zijn dan 1024 tekens.
• Blobnamen zijn hoofdlettergevoelig.
• Gereserveerde URL-tekens moeten correct worden ge escaped.
• Blob-namen kunnen eindigen met een scheidingsteken voor virtuele mappen, zoals een schuine streep (/)
• Ongeldige URL-padtekens zijn niet toegestaan: codepunten zoals \uE000 zijn geldig in NTFS-bestandsnamen, maar zijn geen geldige Unicode-tekens. Bovendien zijn sommige ASCII- of Unicode-tekens, zoals besturingstekens (0x00 aan 0x1F), ook niet toegestaan. Zie RFC 2616, Sectie 2.2: Basisregels en RFC 3987 voor regels voor Unicode-tekenreeksen in HTTP/1.1.		 • Een padnaam mag niet langer zijn dan 32.760 tekens.
• Elk padnaamonderdeel (bestand/map) mag niet langer zijn dan 255 tekens.
• Een padnaam bestaat uit een of meer padnaamonderdelen, gescheiden door het achterste slash-teken (\).
• Padnaam is hoofdletterbehoud en niet hoofdlettergevoelig (twee namen die alleen verschillen in het geval dat niet is toegestaan).
• Kan geen mappad hebben dat hetzelfde is als een bestandspad.
• De volgende tekens zijn ongeldig in de naam van een onderdeel: \ / : ¦ < > * ? "
• Controletekens in het bereik 0x00 tot 0x1F, inclusief, zijn illegaal in een sharenaam.

Padnamen

Een padnaam bestaat uit een of meer padnaamonderdelen (map- of bestandsnaam) gescheiden door het teken forward-slash (/). Alle padnaamonderdelen, behalve het achterpadnaamonderdeel, geven mappen aan. Het achternaamonderdeel van het pad geeft een map of een bestand aan. De volgende naamgevingsregels zijn van toepassing:

  • Een padnaam mag niet langer zijn dan 2048 tekens. Afzonderlijke onderdelen in het pad mogen maximaal 255 tekens lang zijn.
  • Een padnaam bestaat uit een of meer padnaamonderdelen, gescheiden door de slash (/).
  • De diepte van submappen in het pad mag niet groter zijn dan 250.
  • Dezelfde naam kan niet worden gebruikt voor een bestand en een map die dezelfde bovenliggende map delen. Een bestand en een map met de naam data kunnen bijvoorbeeld niet onder hetzelfde bovenliggende pad bestaan.

Namen van metagegevens

Metagegevens voor een share of bestandsresource worden opgeslagen als naam-waardeparen die aan de resource zijn gekoppeld. Namen van metagegevens moeten voldoen aan de naamgevingsregels voor C#-id's.

Houd er rekening mee dat metagegevensnamen de hoofdletters behouden waarmee ze zijn gemaakt, maar niet hoofdlettergevoelig zijn wanneer ze worden ingesteld of gelezen. Als twee of meer metagegevensheaders met dezelfde naam worden verzonden voor een resource, retourneert de Azure File-service statuscode 400 (Ongeldige aanvraag).

Resource-URI-syntaxis

Elke resource heeft een bijbehorende basis-URI, die verwijst naar de resource zelf. Voor het opslagaccount bevat de basis-URI alleen de naam van het account:

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

Voor een share bevat de basis-URI de naam van het account en de naam van de share:

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

Voor een map bevat de basis-URI de naam van het account, de naam van de share en het pad van de map:

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

Voor een bestand bevat de basis-URI de naam van het account, de naam van de share en het pad van het bestand:

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

Zie ook