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 bestaat uit éé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 binnen een bepaalde share of map moet ook een unieke naam hebben binnen die share of map.

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

Namen delen

De regels voor bestandsservicesharenamen zijn meer beperkend dan wordt 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 delen moeten beginnen met een letter of cijfer en mogen alleen letters, cijfers en het afbreekstreepje/minteken (-) bevatten.
  • Elk afbreekstreepje/minteken (-) moet direct worden voorafgegaan en gevolgd door een letter of cijfer; opeenvolgende afbreekstreepjes zijn niet toegestaan in sharenamen.
  • Alle letters in een sharenaam moeten kleine letters bevatten.
  • Deelnamen moeten tussen 3 en 63 tekens lang zijn.

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

containers, blobs en metagegevens benoemen en hiernaar verwijzen SMB-sharenaambeperkingen
• 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 direct worden voorafgegaan en gevolgd door een letter of cijfer; opeenvolgende afbreekstreepjes zijn niet toegestaan in containernamen.
• Alle letters in een containernaam moeten kleine letters zijn.
• Containernamen moeten 3 tot 63 tekens lang zijn.		 • Een sharenaam mag niet langer zijn dan 80 tekens.
• De volgende tekens zijn ongeldig in een sharenaam: \ / [ ] : ¦ < > + = ; , * ? "
• Besturingstekens in bereik 0x00 via 0x1F, inclusief, zijn ongeldig 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 hoofdletterbehoud en hoofdlettergevoelig.
  • Namen van map- en bestandsonderdelen mogen niet langer zijn dan 255 tekens.
  • Adreslijstnamen kunnen niet eindigen met het slash-teken (/). Indien opgegeven, wordt deze automatisch verwijderd.
  • Bestandsnamen mogen niet eindigen met het slash-teken (/).
  • Gereserveerde URL-tekens moeten correct worden ontsnapt.
  • De volgende tekens zijn niet toegestaan: " \ / : | < > * ?
  • Ongeldige URL-padtekens zijn niet toegestaan. Codepunten zoals \uE000, terwijl geldig zijn in NTFS-bestandsnamen, zijn geen geldige Unicode-tekens. Daarnaast zijn sommige ASCII- of Unicode-tekens, zoals besturingstekens (0x00 aan 0x1F), ook niet toegestaan. Zie voor regels voor Unicode-tekenreeksen in HTTP/1.1 RFC 2616, sectie 2.2: Basisregels en RFC 3987.
  • Ongeldige Unicode-tekens (ook wel ongeldig 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$, dot character (.) 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. lijstmap en bestanden en lijstgrepen bewerkingen speciale verwerking nodig hebben 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 voor bestandsshares waarvoor het SMB-protocol is ingeschakeld.

  • 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-02kan het standaardgedrag echter worden overschreven door de header-x-ms-allow-trailing-dot in te stellen op true in de URL-aanvraag.
  • Als u bijvoorbeeld een bestand met de naam file1... wilt maken en de volgpunten wilt opnemen, moet de x-ms-allow-trailing-dot worden opgenomen in de aanvraagheader en ingesteld op true. Hetzelfde geldt voor het maken van mapnamen.
  • In het geval van een aanvraag voor het kopiëren van bestanden, moet de x-ms-source-allow-trailing-dot header worden ingesteld op trueals u volgpunten in de naam van het bronbestand wilt opnemen. Bekijk de beschikbare headeropties voor elke afzonderlijke REST API voor meer informatie.

Standaard worden punttekens (.) aan het einde van map- en bestandsnamen in aanvraag-URL's niet genegeerd voor bestandsshares waarvoor NFS-protocol is ingeschakeld.

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

containers, blobs en metagegevens benoemen en hiernaar verwijzen SMB-protocolnaambeperkingen
• 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 ontsnapt.
• Blobnamen kunnen eindigen met een scheidingsteken voor virtuele mappen, zoals een slash (/)
• Ongeldige URL-padtekens zijn niet toegestaan: Codepunten zoals \uE000, terwijl geldig zijn in NTFS-bestandsnamen, zijn geen geldige Unicode-tekens. Daarnaast zijn sommige ASCII- of Unicode-tekens, zoals besturingstekens (0x00 aan 0x1F), ook niet toegestaan. Zie voor regels voor Unicode-tekenreeksen in HTTP/1.1 RFC 2616, sectie 2.2: Basisregels en RFC 3987.		 • 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 is niet toegestaan).
• Kan geen mappad hebben dat hetzelfde is als een bestandspad.
• De volgende tekens zijn ongeldig in een onderdeelnaam: \ / : ¦ < > * ? "
• Besturingstekens in bereik 0x00 via 0x1F, inclusief, zijn ongeldig 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 achternaamonderdeel van het pad geven mappen aan. Het onderdeel achterpadnaam geeft een map of 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 het slash-teken (/).
  • 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 deelt. Een bestand en een map met elke naam data kunnen bijvoorbeeld niet bestaan onder hetzelfde bovenliggende pad.

Namen van metagegevens

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

Namen van metagegevens behouden de case waarmee ze zijn gemaakt, maar zijn niet hoofdlettergevoelig 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).

Syntaxis van resource-URI

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