Atribuir nomes e referenciar partilhas, diretórios, ficheiros e metadados

Uma conta de armazenamento pode conter zero ou mais partilhas de ficheiros do Azure. Uma partilha contém propriedades, metadados e zero ou mais ficheiros ou diretórios. Um diretório contém propriedades e zero ou mais ficheiros ou diretórios. Um ficheiro é qualquer entidade individual composta por dados binários, propriedades e metadados.

Nomes de recursos

O URI para referenciar uma partilha, diretório ou ficheiro tem de ser exclusivo. Dentro de uma determinada conta de armazenamento, cada partilha tem de ter um nome exclusivo. Todos os ficheiros numa determinada partilha ou diretório também têm de ter um nome exclusivo nessa partilha ou diretório.

Se tentar criar uma partilha, diretório ou ficheiro com um nome que viole as regras de nomenclatura, o pedido falhará com o código de estado 400 (Pedido Incorreto).

Partilhar nomes

As regras para os nomes de partilha do Serviço de ficheiros são mais restritivas do que as prescritas pelo protocolo SMB para nomes de partilha SMB, para que os serviços Blob e Ficheiro possam partilhar convenções de nomenclatura semelhantes para contentores e partilhas. As restrições de nomenclatura para partilhas são as seguintes:

• Um nome de partilha tem de ser um nome DNS válido.
• Os nomes das partilhas têm de começar com uma letra ou número e podem conter apenas letras, números e o caráter hífen/subtração (-).
• Todos os carateres de hífen/subtração (-) têm de ser imediatamente precedidos e seguidos por uma letra ou número; os hífenes consecutivos não são permitidos em nomes de partilha.
• Todas as letras num nome de partilha têm de estar em minúsculas.
• Os nomes das partilhas têm de ter entre 3 e 63 carateres.

A tabela seguinte compara as restrições de nomenclatura para Ficheiros do Azure e armazenamento de Blobs do Azure:

Nomes de diretórios e ficheiros

Ficheiros do Azure impõe as seguintes regras de nomenclatura para nomes de diretórios e ficheiros:

• Os nomes de diretórios e ficheiros são de preservação de maiúsculas e minúsculas.
• Os nomes dos componentes de diretórios e ficheiros não têm de ter mais de 255 carateres de comprimento.
• Os nomes dos diretórios não podem terminar com o caráter de barra (/). Se for fornecido, será removido automaticamente.
• Os nomes de ficheiro não podem terminar com o caráter de barra (/).
• Os carateres de URL reservados devem ser escritos corretamente.
• Não são permitidos os seguintes carateres: " \ / : | < > * ?
• Não são permitidos carateres de caminho de URL ilegais. Os pontos de código, como \uE000, embora válidos em nomes de ficheiro NTFS, não são carateres Unicode válidos. Além disso, alguns carateres ASCII ou Unicode, como carateres de controlo (0x00 para 0x1F), também não são permitidos. Para regras que regem cadeias Unicode em HTTP/1.1, consulte RFC 2616, Secção 2.2: Regras Básicas e RFC 3987.
• Os carateres Unicode inválidos (referidos como pares de substituição inválidos) não são suportados.
• Os seguintes nomes de ficheiro não são permitidos: 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 (.) e dois carateres de ponto (..).
• A partir da versão 2021-12-02, os nomes de diretórios e ficheiros suportam carateres U+FFFE e U+FFFF através de todas as operações. Estes carateres também são suportados através de protocolos SMB e REST. As operações Listar Diretórios e Ficheiros e Identificadores de Lista precisarão de um processamento especial para estes carateres, conforme mencionado na respetiva documentação.

Por predefinição, os carateres de ponto (.) no final do diretório e os nomes de ficheiro nos URLs de pedido são ignorados ou deixados de fora.

• Por exemplo, se um ficheiro com o nome file1... estiver a ser criado, os pontos no final serão ignorados e será criado um ficheiro com o nome file1 . O mesmo se aplica aos diretórios no caminho. Se um pedido de criação de ficheiros incluir o caminho \Dir1\Dir2…\File1 , o ficheiro será criado em \Dir1\Dir2\File1.
• No entanto, a partir da versão 2022-11-02, o comportamento predefinido pode ser substituído ao definir o cabeçalho x-ms-allow-trailing-dot como true no pedido de URL.
• Por exemplo, se quiser criar um ficheiro com o nome file1... e incluir os pontos à direita, o x-ms-allow-trailing-dot deve ser incluído no cabeçalho do pedido e definido como true. O mesmo se aplica à criação de nomes de diretórios.
• No caso de um pedido de cópia de ficheiro, se quiser incluir pontos à direita no nome do ficheiro de origem, o x-ms-source-allow-trailing-dot cabeçalho tem de ser definido como true. Para obter mais informações, consulte as opções de cabeçalho disponíveis para cada API REST individual.

A tabela seguinte compara as restrições de nomenclatura para Ficheiros do Azure e armazenamento de Blobs do Azure:

Nomes de caminho

Um nome de caminho é composto por um ou mais componentes de nome de caminho (nome de diretório ou ficheiro) separados pelo caráter forward-slash (/). Todos os componentes de nome de caminho que não sejam o último componente de nome de caminho indicam diretórios. O último componente de nome de caminho indica um diretório ou um ficheiro. Aplicam-se as seguintes regras de nomenclatura:

• Um nome de caminho pode não ter mais de 2048 carateres de comprimento. Os componentes individuais no caminho podem ter um máximo de 255 carateres de comprimento.
• Um nome de caminho é composto por um ou mais componentes de nome de caminho separados pelo caráter forward-slash (/).
• A profundidade dos subdiretórios no caminho não pode exceder os 250.
• Não é possível utilizar o mesmo nome para um ficheiro e um diretório que partilhem o mesmo diretório principal. Por exemplo, um ficheiro e um diretório com o nome data não podem existir no mesmo caminho principal.

Nomes de metadados

Os metadados de uma partilha ou recurso de ficheiro são armazenados como pares nome-valor associados ao recurso. Os nomes de metadados têm de cumprir as regras de nomenclatura dos identificadores C#.

Tenha em atenção que os nomes de metadados preservam o caso com o qual foram criados, mas não são sensíveis a maiúsculas e minúsculas quando definidos ou lidos. Se forem submetidos dois ou mais cabeçalhos de metadados com o mesmo nome para um recurso, o serviço ficheiro do Azure devolve o código de estado 400 (Pedido Incorreto).

Sintaxe do URI do Recurso

Cada recurso tem um URI base correspondente, que se refere ao próprio recurso. Para a conta de armazenamento, o URI base inclui apenas o nome da conta:

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

Para uma partilha, o URI base inclui o nome da conta e o nome da partilha:

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

Para um diretório, o URI base inclui o nome da conta, o nome da partilha e o caminho do diretório:

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

Para um ficheiro, o URI base inclui o nome da conta, o nome da partilha e o caminho do ficheiro:

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  

Ver também

• Conceitos do Serviço de Ficheiros