Создание контейнера BLOB-объектов с помощью Java
Большие двоичные объекты в службе хранилища Azure упорядочиваются в контейнеры. Прежде чем вы сможете отправить большой двоичный объект, сперва необходимо создать контейнер. В этой статье показано, как создать контейнеры с помощью клиентской библиотеки служба хранилища Azure для Java.
Необходимые компоненты
- В этой статье предполагается, что у вас уже есть проект, настроенный для работы с клиентской библиотекой Хранилище BLOB-объектов Azure для Java. Сведения о настройке проекта, включая установку пакетов, добавление
import
директив и создание авторизованного клиентского объекта, см. в статье "Начало работы с служба хранилища Azure и Java". - Механизм авторизации должен иметь разрешения на создание контейнера BLOB-объектов. Дополнительные сведения см. в руководстве по авторизации для следующей операции REST API:
О именовании контейнеров
Имя контейнера должно быть допустимым DNS-именем, поскольку оно является частью уникального URI, используемого для адресации контейнера или его больших двоичных объектов. При присвоении имени контейнеру следуйте нижеприведенным правилам:
- Имена контейнеров могут содержать от 3 до 63 символов.
- Имена контейнеров должны начинаться с буквы или цифры и могут содержать только строчные буквы, цифры и тире (-).
- Последовательные символы дефиса не допускаются в именах контейнеров.
URI для ресурса контейнера форматируется следующим образом:
https://my-account-name.blob.core.windows.net/my-container-name
Создание контейнера
Чтобы создать контейнер, вызовите один из следующих методов из BlobServiceClient
класса:
Вы также можете создать контейнер с помощью одного из следующих методов из BlobContainerClient
класса:
Контейнеры создаются для учетной записи хранилища немедленно. Нельзя вложить один контейнер в другой. create
Для методов createBlobContainer
создается исключение, если контейнер с тем же именем уже существует.
В следующем примере создается контейнер из BlobServiceClient
объекта:
public BlobContainerClient createContainer(BlobServiceClient blobServiceClient, String containerName) {
// Create the container using the service client object
BlobContainerClient blobContainerClient = blobServiceClient.createBlobContainer(containerName);
return blobContainerClient;
}
Создание корневого контейнера
Корневой контейнер является контейнером по умолчанию для вашей учетной записи хранения. У каждой учетной записи хранения может быть один корневой контейнер, который должен называться $root. Корневой контейнер должен быть явным образом создан или удален.
Вы можете ссылаться на большой двоичный объект, хранящийся в корневом контейнере, не включая имя корневого контейнера. Корневой контейнер позволяет ссылаться на большой двоичный объект на верхнем уровне иерархии учетной записи хранения. К примеру, вы можете ссылаться на большой двоичный объект, находящийся в корневом контейнере, следующим образом:
https://accountname.blob.core.windows.net/default.html
В следующем примере создается новый BlobContainerClient
объект с именем контейнера $root, а затем создается контейнер, если он еще не существует в учетной записи хранения:
public void createRootContainer(BlobServiceClient blobServiceClient) {
// Creates a new BlobContainerClient object by appending the containerName to
// the end of the URI
BlobContainerClient blobContainerClient = blobServiceClient.getBlobContainerClient("$root");
// If the container does not already exist, create it using the container client
blobContainerClient.createIfNotExists();
}
Ресурсы
Дополнительные сведения о создании контейнера с помощью клиентской библиотеки Хранилище BLOB-объектов Azure для Java см. в следующих ресурсах.
Операции REST API
Пакет SDK Azure для Java содержит библиотеки, которые создаются на основе REST API Azure, что позволяет взаимодействовать с операциями REST API через знакомые парадигмы Java. Методы клиентской библиотеки для создания контейнера используют следующую операцию REST API:
- Создание контейнера (REST API)
Примеры кода
Ресурсы клиентской библиотеки
Обратная связь
https://aka.ms/ContentUserFeedback.
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделеОтправить и просмотреть отзыв по