Masukkan Daftar Blokir
Operasi menulis Put Block List
blob dengan menentukan daftar ID blok yang membentuk blob. Untuk ditulis sebagai bagian dari blob, blok harus berhasil ditulis ke server dalam operasi Put Block sebelumnya.
Anda dapat memanggil Put Block List
untuk memperbarui blob dengan hanya mengunggah blok yang telah berubah lalu menerapkan blok baru dan yang sudah ada bersama-sama. Anda dapat melakukan ini dengan menentukan apakah akan melakukan blok dari daftar blokir yang diterapkan atau dari daftar blokir yang tidak dikomit, atau untuk menerapkan versi blok yang terakhir diunggah, daftar mana pun blok tersebut.
Minta
Anda dapat membuat Put Block List
permintaan sebagai berikut. Kami menyarankan agar Anda menggunakan HTTPS. Ganti myaccount dengan nama akun penyimpanan Anda:
URI permintaan metode PUT | Versi HTTP |
---|---|
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist |
HTTP/1.1 |
Permintaan layanan penyimpanan yang ditimulasi
Saat Anda membuat permintaan terhadap layanan penyimpanan yang ditimulasi, tentukan nama host emulator dan port blob service sebagai 127.0.0.1:10000
, diikuti dengan nama akun penyimpanan yang ditimulasi:
URI permintaan metode PUT | Versi HTTP |
---|---|
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=blocklist |
HTTP/1.1 |
Emulator penyimpanan hanya mendukung ukuran blob hingga 2 gibibyte (GiB).
Untuk informasi selengkapnya, lihat Gunakan emulator Azurite untuk pengembangan Microsoft Azure Storage lokal.
Parameter URI
Anda dapat menentukan parameter tambahan berikut pada permintaan URI:
Parameter | Deskripsi |
---|---|
timeout |
Opsional. Parameter timeout dinyatakan dalam hitung detik. Untuk informasi selengkapnya, lihat Mengatur waktu habis untuk operasi Blob service. |
Header permintaan
Header permintaan yang diperlukan dan opsional dijelaskan dalam tabel berikut:
Meminta kop | Deskripsi |
---|---|
Authorization |
Wajib diisi. Menentukan skema otorisasi, nama akun, dan tanda tangan. Untuk informasi selengkapnya, lihat Mengotorisasi permintaan ke Azure Storage. |
Date atau x-ms-date |
Wajib diisi. Menentukan Waktu Universal Terkoordinasi (UTC) untuk permintaan tersebut. Untuk informasi selengkapnya, lihat Mengotorisasi permintaan ke Azure Storage. |
x-ms-version |
Diperlukan untuk semua permintaan yang diotorisasi. Menentukan versi operasi yang akan digunakan untuk permintaan ini. Untuk informasi selengkapnya, lihat Penerapan versi untuk layanan Azure Storage. |
Content-Length |
Wajib diisi. Panjang konten permintaan, dalam byte. Header ini mengacu pada panjang konten daftar blok, bukan dari blob itu sendiri. |
Content-MD5 |
Opsional. Hash MD5 dari konten permintaan. Hash ini digunakan untuk memverifikasi integritas konten permintaan selama transportasi. Jika dua hash tidak cocok, operasi gagal dengan kode kesalahan 400 (Permintaan Buruk). Header ini dikaitkan dengan konten permintaan, dan bukan dengan konten blob itu sendiri. |
x-ms-content-crc64 |
Pilihan. Hash CRC64 dari konten permintaan. Hash ini digunakan untuk memverifikasi integritas konten permintaan selama transportasi. Jika dua hash tidak cocok, operasi gagal dengan kode kesalahan 400 (Permintaan Buruk). Header ini dikaitkan dengan konten permintaan, dan bukan dengan konten blob itu sendiri. Jika header Content-MD5 dan x-ms-content-crc64 ada, permintaan gagal dengan 400 (Permintaan Buruk). Header ini didukung dalam versi 2019-02-02 dan yang lebih baru. |
x-ms-blob-cache-control |
Pilihan. Mengatur kontrol cache blob. Jika properti ini ditentukan, properti disimpan dengan blob dan dikembalikan dengan permintaan baca. Jika properti tidak ditentukan dengan permintaan, properti akan dihapus untuk blob jika permintaan berhasil. |
x-ms-blob-content-type |
Pilihan. Mengatur jenis konten blob. Jika ditentukan, properti ini disimpan dengan blob dan dikembalikan dengan permintaan baca. Jika jenis konten tidak ditentukan, jenis konten diatur ke jenis default, yaitu application/octet-stream . |
x-ms-blob-content-encoding |
Pilihan. Mengatur pengodean konten blob. Jika ditentukan, properti ini disimpan dengan blob dan dikembalikan dengan permintaan baca. Jika properti tidak ditentukan dengan permintaan, properti akan dihapus untuk blob jika permintaan berhasil. |
x-ms-blob-content-language |
Pilihan. Mengatur bahasa konten blob. Jika ditentukan, properti ini disimpan dengan blob dan dikembalikan dengan permintaan baca. Jika properti tidak ditentukan dengan permintaan, properti akan dihapus untuk blob jika permintaan berhasil. |
x-ms-blob-content-md5 |
Pilihan. Hash MD5 dari konten blob. Hash ini tidak divalidasi, karena hash untuk blok individual divalidasi saat masing-masing diunggah. Operasi Dapatkan Blob mengembalikan nilai header ini di header respons Content-MD5. Jika properti ini tidak ditentukan dengan permintaan, properti akan dibersihkan untuk blob jika permintaan berhasil. |
x-ms-meta-name:value |
Pilihan. Pasangan nama-nilai yang ditentukan pengguna yang terkait dengan blob. Pada versi 2009-09-19, nama metadata harus mematuhi aturan penamaan untuk pengidentifikasi C#. |
x-ms-encryption-scope |
Pilihan. Menunjukkan cakupan enkripsi yang akan digunakan untuk mengenkripsi blob. Nilai ini harus cocok dengan cakupan enkripsi yang digunakan untuk mengenkripsi semua blok yang sedang diterapkan. Header ini didukung dalam versi 2019-02-02 dan yang lebih baru. |
x-ms-encryption-context |
Pilihan. Defaultnya adalah "Kosong". Jika nilai diatur, nilai akan mengatur metadata sistem blob. Panjang maksimum-1024. Hanya berlaku saat Namespace Hierarki diaktifkan untuk akun tersebut. Header ini didukung dalam versi 2021-08-06 dan yang lebih baru. |
x-ms-tags |
Pilihan. Mengatur tag yang dikodekan string kueri yang ditentukan pada blob. Untuk informasi tambahan, lihat bagian Keterangan . Didukung dalam versi 2019-12-12 dan yang lebih baru. |
x-ms-lease-id:<ID> |
Diperlukan jika blob memiliki sewa aktif. Untuk melakukan operasi ini pada blob dengan sewa aktif, tentukan ID sewa yang valid untuk header ini. |
x-ms-client-request-id |
Pilihan. Menyediakan nilai buram yang dihasilkan klien dengan batas karakter 1 kibibyte (KiB) yang dicatat dalam log analitik saat pengelogan analitik penyimpanan dikonfigurasi. Kami sangat menyarankan Anda menggunakan header ini untuk menghubungkan aktivitas sisi klien dengan permintaan yang diterima server. |
x-ms-blob-content-disposition |
Pilihan. Mengatur header blob Content-Disposition . Tersedia untuk versi 2013-08-15 dan yang lebih baru.Bidang Content-Disposition header menyampaikan informasi tambahan tentang cara memproses payload respons, dan dapat digunakan untuk melampirkan metadata tambahan. Misalnya, jika diatur ke attachment , header ini menunjukkan bahwa agen pengguna tidak boleh menampilkan respons, tetapi sebaliknya harus menampilkan dialog Simpan Sebagai.Respons dari operasi Dapatkan Properti Blob dan Dapatkan Blob menyertakan header disposisi konten. |
x-ms-access-tier |
Pilihan. Versi 2018-11-09 dan yang lebih baru. Menunjukkan tingkat yang akan diatur pada blob. Untuk blob blok, header ini didukung pada penyimpanan blob atau akun v2 tujuan umum hanya dengan versi 2018-11-09 dan yang lebih baru. Nilai yang valid untuk tingkat blob blok adalah Hot , , Cold Cool , dan Archive .
Catatan: Cold tingkat didukung untuk versi 2021-12-02 dan yang lebih baru. Untuk informasi terperinci tentang tingkatan blob blok, lihat Tingkat penyimpanan panas, dingin, dan arsip. |
x-ms-immutability-policy-until-date |
Versi 2020-06-12 dan yang lebih baru. Menentukan tanggal retensi-hingga yang akan diatur pada blob. Ini adalah tanggal hingga blob dapat dilindungi agar tidak dimodifikasi atau dihapus. Mengikuti format RFC1123. |
x-ms-immutability-policy-mode |
Versi 2020-06-12 dan yang lebih baru. Menentukan mode kebijakan imutabilitas yang akan diatur pada blob. Nilai yang berlaku adalah unlocked atau locked . Nilai unlocked menunjukkan bahwa pengguna dapat mengubah kebijakan dengan meningkatkan atau mengurangi tanggal retensi hingga . Nilai locked menunjukkan bahwa tindakan ini dilarang. |
x-ms-legal-hold |
Versi 2020-06-12 dan yang lebih baru. Menentukan penahanan legal yang akan ditetapkan pada blob. Nilai yang valid adalah true dan false . |
x-ms-expiry-option |
Opsional. Versi 2023-08-03 dan yang lebih baru. Menentukan opsi tanggal kedaluwarsa untuk permintaan, lihat ExpiryOption. Header ini valid untuk akun dengan namespace hierarki diaktifkan. |
x-ms-expiry-time |
Pilihan. Versi 2023-08-03 dan yang lebih baru. Menentukan waktu ketika blob diatur untuk kedaluwarsa. Format untuk tanggal kedaluwarsa bervariasi menurut x-ms-expiry-option . Untuk informasi selengkapnya, lihat ExpiryOption. Header ini valid untuk akun dengan namespace hierarki diaktifkan. yang expiryTime sudah ada pada blob tidak dikosongkan jika permintaan tidak berisi nilai baru expiryTime |
Operasi ini juga mendukung penggunaan header bersyar untuk menerapkan daftar blokir hanya jika kondisi tertentu terpenuhi. Untuk informasi selengkapnya, lihat Menentukan header kondisional untuk operasi Blob Storage.
Header permintaan (kunci enkripsi yang disediakan pelanggan)
Pada versi 2019-02-02, Anda dapat menentukan header berikut pada permintaan untuk mengenkripsi blob dengan kunci yang disediakan pelanggan. Enkripsi dengan kunci yang disediakan pelanggan (dan set header yang sesuai) bersifat opsional.
Meminta kop | Deskripsi |
---|---|
x-ms-encryption-key |
Wajib diisi. Kunci enkripsi AES-256 yang dikodekan Base64. |
x-ms-encryption-key-sha256 |
Wajib diisi. Hash SHA256 yang dikodekan Base64 dari kunci enkripsi. |
x-ms-encryption-algorithm: AES256 |
Wajib diisi. Menentukan algoritma yang akan digunakan untuk enkripsi. Nilai header ini harus AES256 . |
Isi permintaan
Dalam isi permintaan, Anda dapat menentukan daftar blokir bahwa Blob Storage harus memeriksa blok yang diminta. Dengan cara ini, Anda dapat memperbarui blob yang ada dengan menyisipkan, mengganti, atau menghapus blok individual, daripada memuat ulang seluruh blob. Setelah mengunggah blok atau blok yang telah berubah, Anda dapat menerapkan versi baru blob dengan menerapkan blok baru bersama dengan blok yang ada yang ingin Anda simpan.
Untuk memperbarui blob, Anda dapat menentukan bahwa layanan harus mencari ID blok dalam daftar blok yang diterapkan, dalam daftar blok yang tidak diterapkan, atau dalam daftar blok yang tidak diterapkan terlebih dahulu lalu di daftar blok yang diterapkan. Untuk menunjukkan pendekatan mana yang akan digunakan, tentukan ID blok yang berada dalam elemen XML yang sesuai dalam isi permintaan, sebagai berikut:
Tentukan ID blok dalam
Committed
elemen untuk menunjukkan bahwa Blob Storage hanya boleh mencari daftar blok yang diterapkan untuk blok bernama. Jika blok tidak ditemukan dalam daftar blok yang diterapkan, blok tersebut tidak ditulis sebagai bagian dari blob, dan Blob Storage mengembalikan kode status 400 (Permintaan Buruk).Tentukan ID blok dalam
Uncommitted
elemen untuk menunjukkan bahwa Blob Storage hanya harus mencari daftar blok yang tidak diterapkan untuk blok bernama. Jika blok tidak ditemukan dalam daftar blok yang tidak dikomit, blok tersebut tidak ditulis sebagai bagian dari blob, dan Blob Storage mengembalikan kode status 400 (Permintaan Buruk).Tentukan ID blok dalam
Latest
elemen untuk menunjukkan bahwa Blob Storage harus terlebih dahulu mencari daftar blok yang tidak diterapkan. Jika blok ditemukan dalam daftar yang tidak dikomit, versi blok tersebut adalah yang terbaru dan harus ditulis ke blob. Jika blok tidak ditemukan dalam daftar yang tidak dikomit, layanan harus mencari daftar blok yang diterapkan untuk blok bernama dan menulis blok tersebut ke blob jika ditemukan.
Isi permintaan untuk versi Put Block List
ini menggunakan format XML berikut:
<?xml version="1.0" encoding="utf-8"?>
<BlockList>
<Committed>first-base64-encoded-block-id</Committed>
<Uncommitted>second-base64-encoded-block-id</Uncommitted>
<Latest>third-base64-encoded-block-id</Latest>
...
</BlockList>
Permintaan sampel
Untuk menunjukkan Put Block List
, asumsikan Anda telah mengunggah tiga blok yang sekarang ingin Anda terapkan. Contoh berikut menerapkan blob baru dengan menunjukkan bahwa versi terbaru dari setiap blok yang tercantum harus digunakan. Tidak perlu mengetahui apakah blok ini telah dilakukan.
Request Syntax:
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist HTTP/1.1
Request Headers:
x-ms-date: Wed, 31 Aug 2011 00:17:43 GMT
x-ms-version: 2011-08-18
Content-Type: text/plain; charset=UTF-8
Authorization: SharedKey myaccount:DJ5QZSVONZ64vAhnN/wxcU+Pt5HQSLAiLITlAU76Lx8=
Content-Length: 133
Request Body:
<?xml version="1.0" encoding="utf-8"?>
<BlockList>
<Latest>AAAAAA==</Latest>
<Latest>AQAAAA==</Latest>
<Latest>AZAAAA==</Latest>
</BlockList>
Selanjutnya, mari kita asumsikan bahwa Anda ingin memperbarui blob. Blob baru memiliki perubahan berikut:
Blok baru dengan ID
ANAAAA==
. Blok ini harus terlebih dahulu diunggah dengan panggilan ke Put Block, dan muncul di daftar blokir yang tidak dikomit hingga panggilan kePut Block List
.Versi blok yang diperbarui dengan ID
AZAAAA==
. Blok ini harus terlebih dahulu diunggah dengan panggilan ke Put Block, dan muncul di daftar blokir yang tidak dikomit hingga panggilan kePut Block List
.Penghapusan blok dengan ID
AAAAAA==
. Karena blok ini tidak disertakan dalam panggilan berikutnya kePut Block List
, blok dihapus secara efektif dari blob.
Contoh berikut menunjukkan panggilan ke Put Block List
yang memperbarui blob:
Request Syntax:
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist HTTP/1.1
Request Headers:
x-ms-date: Wed, 31 Aug 2009 00:17:43 GMT
x-ms-version: 2011-08-18
Content-Type: text/plain; charset=UTF-8
x-ms-expiry-option: RelativeToNow
x-ms-expiry-time: 30000
Authorization: SharedKey myaccount:DJ5QZSVONZ64vAhnN/wxcU+Pt5HQSLAiLITlAU76Lx8=
Content-Length: 133
Request Body:
<?xml version="1.0" encoding="utf-8"?>
<BlockList>
<Uncommitted>ANAAAA==</Uncommitted>
<Committed>AQAAAA==</Committed>
<Uncommitted>AZAAAA==</Uncommitted>
</BlockList>
Respons
Respons mencakup kode status HTTP dan sekumpulan header respons.
Kode status
Operasi yang berhasil mengembalikan kode status 201 (Dibuat).
Untuk informasi selengkapnya tentang kode status, lihat Status dan kode kesalahan.
Header respons
Respons untuk operasi ini mencakup header berikut. Respons juga dapat mencakup header HTTP standar tambahan. Semua header standar sesuai dengan spesifikasi protokol HTTP/1.1.
Respons | Deskripsi |
---|---|
ETag |
Tag entitas berisi nilai yang dapat digunakan klien untuk melakukan operasi kondisional GET/PUT dengan menggunakan If-Match header permintaan. Jika versi permintaan adalah 2011-08-18 atau yang lebih baru, nilai ETag diapit dalam tanda kutip. |
Last-Modified |
Tanggal/waktu blob terakhir diubah. Format tanggal mengikuti RFC 1123. Untuk informasi selengkapnya, lihat Mewakili nilai tanggal/waktu di header. Setiap operasi yang memodifikasi blob, termasuk pembaruan metadata atau properti blob, mengubah waktu terakhir blob yang dimodifikasi. |
Content-MD5 |
Dikembalikan sehingga klien dapat memeriksa integritas konten pesan. Header ini mengacu pada konten permintaan (dalam hal ini, daftar blok dan bukan konten blob itu sendiri). Untuk versi 2019-02-02 dan yang lebih baru, header ini dikembalikan hanya ketika permintaan memiliki header ini. |
x-ms-content-crc64 |
Untuk versi 2019-02-02 dan yang lebih baru, header ini dikembalikan sehingga klien dapat memeriksa integritas konten pesan. Header ini mengacu pada konten permintaan (dalam hal ini, daftar blok dan bukan konten blob itu sendiri). Header ini dikembalikan ketika Content-md5 header tidak ada dalam permintaan. |
x-ms-request-id |
Secara unik mengidentifikasi permintaan yang dibuat, dan Anda dapat menggunakannya untuk memecahkan masalah permintaan. Untuk informasi selengkapnya, lihat Memecahkan masalah operasi API. |
x-ms-version |
Versi Blob Storage yang digunakan untuk menjalankan permintaan. Header ini dikembalikan untuk permintaan yang dibuat terhadap versi 2009-09-19 dan yang lebih baru. |
Date |
Nilai tanggal/waktu UTC yang dihasilkan oleh layanan, yang menunjukkan kapan respons dimulai. |
x-ms-request-server-encrypted: true/false |
Versi 2015-12-11 dan yang lebih baru. Nilai header ini diatur ke true jika konten permintaan berhasil dienkripsi menggunakan algoritma yang ditentukan. Jika tidak, nilai diatur ke false . |
x-ms-encryption-key-sha256 |
Versi 2019-02-02 dan yang lebih baru. Header ini dikembalikan jika permintaan menggunakan kunci yang disediakan pelanggan untuk enkripsi, sehingga klien dapat memastikan bahwa konten permintaan berhasil dienkripsi dengan menggunakan kunci yang disediakan. |
x-ms-encryption-scope |
Versi 2019-02-02 dan yang lebih baru. Header ini dikembalikan jika permintaan menggunakan cakupan enkripsi, sehingga klien dapat memastikan bahwa konten permintaan berhasil dienkripsi dengan menggunakan cakupan enkripsi. |
x-ms-version-id: <DateTime> |
Versi 2019-12-12 dan yang lebih baru. Mengembalikan nilai buram DateTime yang secara unik mengidentifikasi blob. Nilai header ini menunjukkan versi blob, dan dapat digunakan dalam permintaan berikutnya untuk mengakses blob. |
x-ms-client-request-id |
Dapat digunakan untuk memecahkan masalah permintaan dan respons yang sesuai. Nilai header ini sama dengan nilai x-ms-client-request-id header jika ada dalam permintaan dan nilai berisi tidak lebih dari 1.024 karakter ASCII yang terlihat.
x-ms-client-request-id Jika header tidak ada dalam permintaan, header tidak ada dalam respons. |
Respons sampel
Response Status:
HTTP/1.1 201 Created
Response Headers:
Transfer-Encoding: chunked
x-ms-content-crc64: 77uWZTolTHU
Date: Sun, 25 Sep 2011 00:17:44 GMT
ETag: “0x8CB172A360EC34B”
Last-Modified: Sun, 25 Sep 2011 00:17:43 GMT
x-ms-version: 2011-08-18
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
x-ms-version-id: <DateTime>
Authorization
Otorisasi diperlukan saat memanggil operasi akses data apa pun di Azure Storage. Anda dapat mengotorisasi operasi seperti yang Put Block List
dijelaskan di bawah ini.
Jika permintaan menentukan tag dengan x-ms-tags
header permintaan, pemanggil harus memenuhi persyaratan otorisasi operasi Atur Tag Blob .
Penting
Microsoft merekomendasikan penggunaan Microsoft Entra ID dengan identitas terkelola untuk mengotorisasi permintaan ke Azure Storage. Microsoft Entra ID memberikan keamanan yang unggul dan kemudahan penggunaan dibandingkan dengan otorisasi Kunci Bersama.
Azure Storage mendukung penggunaan Microsoft Entra ID untuk mengotorisasi permintaan ke data blob. Dengan Microsoft Entra ID, Anda dapat menggunakan kontrol akses berbasis peran Azure (Azure RBAC) untuk memberikan izin kepada prinsip keamanan. Prinsip keamanan dapat berupa pengguna, grup, perwakilan layanan aplikasi, atau identitas terkelola Azure. Prinsip keamanan diautentikasi oleh Microsoft Entra ID untuk mengembalikan token OAuth 2.0. Token kemudian dapat digunakan untuk mengotorisasi permintaan terhadap Blob service.
Untuk mempelajari selengkapnya tentang otorisasi menggunakan Microsoft Entra ID, lihat Mengotorisasi akses ke blob menggunakan Microsoft Entra ID.
Izin
Tercantum di bawah ini adalah tindakan RBAC yang diperlukan untuk pengguna Microsoft Entra, grup, identitas terkelola, atau perwakilan layanan untuk memanggil Put Block List
operasi, dan peran Azure RBAC bawaan yang paling tidak istimewa yang mencakup tindakan ini:
- Tindakan Azure RBAC:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
- Peran bawaan yang paling tidak istimewa:Kontributor Data Blob Penyimpanan
Untuk mempelajari selengkapnya tentang menetapkan peran menggunakan Azure RBAC, lihat Menetapkan peran Azure untuk akses ke data blob.
Keterangan
Operasi memberlakukan Put Block List
urutan di mana blok akan digabungkan untuk membuat blob.
ID blok yang sama dapat ditentukan lebih dari satu kali dalam daftar blok. Jika ID blok ditentukan lebih dari satu kali, id tersebut mewakili rentang byte di masing-masing lokasi tersebut dalam daftar blokir untuk blob akhir yang diterapkan. Jika ID blok muncul lebih dari sekali dalam daftar, kedua instans ID blok harus ditentukan dalam daftar blok yang sama. Dengan kata lain, kedua instans harus ditentukan dalam Committed
elemen , Uncommitted
elemen , atau Latest
elemen .
Dengan Put Block List
, Anda dapat memodifikasi blob yang ada dengan menyisipkan, memperbarui, atau menghapus blok individual tanpa harus mengunggah seluruh blob lagi. Anda dapat menentukan ID blok dari daftar blok yang diterapkan saat ini dan daftar blok yang tidak diterapkan untuk membuat blob baru atau memperbarui konten blob yang ada. Dengan cara ini, Anda dapat memperbarui blob dengan menentukan beberapa blok baru dari daftar blok yang tidak dikomit, dan sisanya dari daftar blok yang diterapkan, yang sudah menjadi bagian dari blob yang ada.
Jika ID blok ditentukan dalam Latest
elemen , dan ID blok yang sama ada di daftar blok yang diterapkan dan tidak diterapkan, Put Block List
lakukan blok dari daftar blok yang tidak dilakukan. Jika ID blok ada dalam daftar blok yang diterapkan tetapi tidak dalam daftar blokir yang tidak dikomit, Put Block List
lakukan blok dari daftar blok yang diterapkan.
Setiap blok dalam blob blok bisa menjadi ukuran yang berbeda. Blob blok dapat mencakup maksimum 50.000 blok yang diterapkan. Jumlah maksimum blok yang tidak dikomit yang mungkin terkait dengan blob adalah 100.000.
Tabel berikut menjelaskan ukuran blok dan blob maksimum yang diizinkan, berdasarkan versi layanan:
Versi layanan. | Ukuran blok maksimum (melalui Put Block ) |
Ukuran blob maksimum (melalui Put Block List ) |
Ukuran blob maksimum melalui operasi tulis tunggal (melalui Put Blob ) |
---|---|---|---|
Versi 12-12-2019 dan yang lebih baru | 4.000 mebibyte (MiB) | Sekitar 190,7 tebibyte (TiB) (4.000 MiB × 50.000 blok) | 5.000 MiB |
Versi 2016-05-31 hingga 2019-07-07 | 100 MiB | Sekitar 4,75 TiB (100 MiB × 50.000 blok) | 256 MiB |
Versi yang lebih lama dari 2016-05-31 | 4 MiB | Sekitar 195 GiB (4 MiB × 50.000 blok) | 64 MiB |
Saat Anda memanggil Put Block List
untuk memperbarui blob yang ada, properti dan metadata blob yang ada akan ditimpa. Namun, setiap rekam jepret yang ada dipertahankan dengan blob. Anda dapat menggunakan header permintaan kondisional untuk melakukan operasi hanya jika kondisi tertentu terpenuhi.
Put Block List
Jika operasi gagal karena blok yang hilang, Anda perlu mengunggah blok yang hilang.
Setiap blok yang tidak dikomit adalah sampah yang dikumpulkan jika tidak ada panggilan yang berhasil ke Put Block
atau Put Block List
pada blob dalam seminggu setelah operasi terakhir yang berhasil Put Block
. Jika Put Blob dipanggil pada blob, setiap blok yang tidak dikomit adalah sampah yang dikumpulkan.
Jika tag disediakan di x-ms-tags
header, tag harus dikodekan dengan string kueri. Kunci dan nilai tag harus sesuai dengan persyaratan penamaan dan panjang, seperti yang ditentukan dalam Set Blob Tags
. Selanjutnya, x-ms-tags
header mungkin berisi tag berukuran hingga 2 KiB. Jika diperlukan lebih banyak tag, gunakan operasi Atur Tag Blob .
Jika blob memiliki sewa aktif, klien harus menentukan ID sewa yang valid pada permintaan untuk menerapkan daftar blokir. Jika klien tidak menentukan ID sewa atau menentukan ID sewa yang tidak valid, Blob Storage mengembalikan kode status 412 (Prasyarat Gagal). Jika klien menentukan ID sewa tetapi blob tidak memiliki sewa aktif, Blob Storage juga mengembalikan kode status 412 (Prasyarat Gagal). Jika klien menentukan ID sewa pada blob yang belum ada, Blob Storage mengembalikan kode status 412 (Prasyarat Gagal) untuk permintaan yang dibuat terhadap versi 2013-08-15 atau yang lebih baru. Untuk versi sebelumnya, Blob Storage mengembalikan kode status 201 (Dibuat).
Jika blob memiliki sewa aktif dan Anda memanggil Put Block List
untuk memperbarui blob, sewa dipertahankan pada blob yang diperbarui.
Put Block List
hanya berlaku untuk blob blok.
Put Block List
Panggilan pada blob halaman menghasilkan kode status 400 (Permintaan Buruk).
Menimpa blob yang diarsipkan gagal, dan menimpa hot
atau cool
blob mewarisi tingkat dari blob lama jika header x-ms-access-tier tidak disediakan.
Billing
Permintaan harga dapat berasal dari klien yang menggunakan API Blob Storage, baik langsung melalui Blob Storage REST API, atau dari pustaka klien Azure Storage. Permintaan ini mengumpulkan biaya per transaksi. Jenis transaksi memengaruhi cara akun ditagih. Misalnya, transaksi baca bertambah ke kategori penagihan yang berbeda dari transaksi tulis. Tabel berikut ini memperlihatkan kategori penagihan untuk Put Block List
permintaan berdasarkan jenis akun penyimpanan:
Operasi | Jenis akun penyimpanan | Kategori penagihan |
---|---|---|
Masukkan Daftar Blokir | Objek besar biner blok premium Tujuan umum standar v2 Tujuan umum standar v1 |
Operasi tulis |
Untuk mempelajari tentang harga untuk kategori penagihan yang ditentukan, lihat harga Azure Blob Storage.
Lihat juga
Memahami blob blok, blob penambahan, dan blob halaman
Mengotorisasi permintaan ke Azure Storage
Status dan kode galat
Kode kesalahan blob service
Mengatur waktu habis untuk operasi Blob service