Именование контейнеров, больших двоичных объектов и метаданных и ссылка на них

В этом разделе описываются правила именования и обращения к контейнерам, большим двоичным объектам, метаданным и моментальным снимкам. Учетная запись хранилища может содержать нуль или больше контейнеров. Контейнер содержит свойства, метаданные и нуль или больше BLOB-объектов. Если у вашей учетной записи есть иерархическое пространство имен, контейнер также может содержать ноль или несколько каталогов, а эти каталоги могут содержать ноль или более БОЛЬШИХ ДВОИЧНЫх объектов. Большой двоичный объект — это любая сущность, состоящая из двоичных данных, свойств и метаданных.

Имена ресурсов

URI-адрес для обращения к контейнеру или большому двоичному объекту должен быть уникальным. Поскольку имя каждой учетной записи уникально, то две записи могут иметь контейнеры с одинаковым именем. Однако в пределах одной учетной записи хранения каждый контейнер должен иметь уникальное имя. Каждый большой двоичный объект контейнера также должен иметь уникальное имя в пределах контейнера.

При попытке создания контейнера или большого двоичного объекта с именем, которое нарушает правила именования, запрос завершается ошибкой с кодом состояния 400 (Bad Request).

Имена большого двоичного объекта и контейнера передаются в службу BLOB-объектов в URL-адресе. Некоторые символы необходимо перекодировать (в последовательность с процентом) для использования в URL-адресе. При этом используется кодировка UTF-8 (рекомендуется) или многобайтовая кодировка (MBCS). Эта кодировка происходит автоматически при использовании клиентских библиотек службы хранилища Azure. Однако есть некоторые символы, которые недопустимы в URL-адресе, даже будучи перекодированы. Если эти символы отображаются в именах больших двоичных объектов или контейнеров, запрос может завершиться ошибкой. Список этих символов см. в разделе Символы Юникода, которые не рекомендуется использовать в именах контейнеров или BLOB-объектов.

Кодовые точки вроде \ uE000 допустимы в NTFS-именах, но не являются допустимыми символами Юникода, поэтому их использовать нельзя. Кроме того, некоторые символы ASCII и Юникода, например, управляющие символы (от 0x00 до 0x1F, \u0081 и т. д.), также не являются допустимыми.

Дополнительные правила, регулирующие строки Юникода в HTTP/1.1, см. в статье RFC 2616, Раздел 2.2. Основные правила и RFC 3987.

Имена контейнеров

Имя контейнера должно быть допустимым DNS-именем и соответствовать указанным ниже правилам именования.

• Имена контейнеров должны начинаться или заканчиваться буквой или цифрой и содержать только буквы, цифры и дефис или минус (-).

• Каждый дефис или минус (-) должен быть непосредственно перед символом, за которым следует буква или цифра; Последовательные дефисы не допускаются в именах контейнеров.

• Все знаки в имени контейнера должны быть строчными.

• Имя контейнера должно содержать от 3 до 63 знаков.

Имена каталогов

Если у вашей учетной записи есть иерархическое пространство имен, имя каталога должно соответствовать следующим правилам именования:

• Имя каталога может содержать любое сочетание символов.

• Имя каталога должно содержать по крайней мере один символ и не может содержать более 1024 символов.

• В именах каталогов учитывается регистр.

• Зарезервированные веб-адреса должны быть надлежащим образом экранированы.

Имена больших двоичных объектов

Имя большого двоичного объекта должно соответствовать следующим правилам именования. Эти правила применяются также к большим двоичным объектам в учетных записях с иерархическим пространством имен, если не указано иное.

• Имя BLOB-объекта может содержать любую комбинацию знаков.

• Имя большого двоичного объекта в службе хранилища Azure должно быть длиной не меньше одного символа, но не больше 1 024 символов.

  Эмулятор службы хранилища Azure поддерживает имена BLOB-объектов длиной до 256 символов. Дополнительные сведения см. в статье Использование эмулятора хранения Azure для разработки и тестирования.

• В именах blob-объектов учитывается регистр символов.

• Зарезервированные веб-адреса должны быть надлежащим образом экранированы.

• Существуют ограничения на количество сегментов пути, составляющих имя большого двоичного объекта. Сегмент пути — это строка между последовательными символами разделителя (например, косая черта /), соответствующая каталогу или виртуальному каталогу. К именам BLOB-объектов применяются следующие ограничения сегментов пути:

  • Если в учетной записи хранения не включено иерархическое пространство имен, количество сегментов пути, составляющих имя большого двоичного объекта, не может превышать 254.
  • Если в учетной записи хранения включено иерархическое пространство имен, количество сегментов пути, составляющих имя BLOB-объекта, не может превышать 63 (включая сегменты пути для имени учетной записи и имени контейнера).

По умолчанию служба BLOB-объектов основана на схеме неструктурированного хранилища, а не на иерархической схеме. Однако для создания виртуальной иерархии внутри имени большого двоичного объекта можно указать определенный символ или разделитель строк. Например, в следующем списке приведены допустимые и уникальные имена больших двоичных объектов. Обратите внимание, что строка в пределах контейнера может быть как допустимым именем большого двоичного объекта, так и именем виртуального каталога.

• /a

• /a.txt

• /a/b

• /a/b.txt

При перечислении больших двоичных объектов можно воспользоваться символом разделителя.

Имена метаданных

Метаданные для ресурсов больших двоичных объектов или контейнера хранятся как пары «имя-значение», связанные с ресурсом. Имена метаданных должны соответствовать правилам именования для идентификаторов C#.

Обратите внимание, что имена метаданных сохраняют регистр, с которым они были созданы, однако при задании и чтении регистр не учитывается. Если в ресурс отправляются два или более заголовка метаданных с одним именем, то служба BLOB-объектов возвращает код состояния 400 (неправильный запрос).

Синтаксис URI ресурса

Каждый ресурс имеет соответствующий базовый URI-адрес, который ссылается на сам ресурс.

Для учетной записи хранения базовый URI-адрес содержит только имя учетной записи:

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

Для контейнера базовый URI-адрес содержит имя учетной записи и имя контейнера:

https://myaccount.blob.core.windows.net/mycontainer

Для больших двоичных объектов базовый URI-адрес включает имя записи, имя контейнера и имя большого двоичного объекта:

https://myaccount.blob.core.windows.net/mycontainer/myblob

Учетная запись хранилища может иметь корневой контейнер — контейнер по умолчанию, который можно не указывать в URI-адресе. Можно ссылаться на большой двоичный объект в корневом контейнере без именования контейнера или же явно указать корневой контейнер по его имени ($root). Дополнительные сведения см. в статье Работа с корневым контейнером . Следующие URI-адреса указывают на большой двоичный объект в корневом контейнере.

https://myaccount.blob.core.windows.net/myblob  
https://myaccount.blob.core.windows.net/$root/myblob  

Моментальные снимки больших двоичных объектов

Моментальный снимок — это версия большого двоичного объекта только для чтения. Содержит все данные объекта на момент создания снимка. Моментальные снимки можно использовать для создания резервной копии или контрольной точки большого двоичного объекта. Имя моментального снимка большого двоичного объекта включает базовый URI-адрес объекта и значение date-time, которое показывает время создания снимка.

Например, предположим, что объект имеет следующий URI-адрес:

https://myaccount.blob.core.windows.net/mycontainer/myblob

URI для моментального снимка данного большого двоичного объекта формируется следующим образом:

https://myaccount.blob.core.windows.net/mycontainer/myblob?snapshot=<DateTime>

Символы Юникода не рекомендуется использовать в именах контейнеров или BLOB-объектов

В следующей таблице приведен список символов Юникода, которые не рекомендуется использовать в именах контейнеров или BLOB-объектов. При использовании этих символов в сочетании с другими символами в этом списке может произойти сбой декодирования UTF-8 или MBCS, что приведет к сбою запроса к службе BLOB-объектов.

См. также раздел

• Использование службы хранения BLOB-объектов
• Перечисление ресурсов больших двоичных объектов
• Основные понятия службы BLOB-объектов
• Работа с корневым контейнером
• Создание моментального снимка большого двоичного объекта