Video & subtitle · Pengunduh Gambar Kecil YouTube & Penampil Metadata
Cara browser menyimpan gambar lintas asal: ambil, URL Blob, dan unduh
· Cara kerjanya
youtube javascript kor
Menyimpan gambar dari domain lain lebih sulit daripada link dengan atribut download. Postingan ini menjelaskan mengapa atribut diabaikan untuk URL lintas asal, bagaimana URL pengambilan dan Blob menyelesaikannya, dan apa hubungannya CORS dengan atribut tersebut.
Atribut download membuka gambar alih-alih menyimpannya — tangkapan lintas asal
Jangkar yang menunjuk ke asal yang berbeda mungkin menavigasi ke gambar alih-alih menggunakan nama file yang diinginkan. Pengunduh yang dapat diandalkan memerlukan byte yang dapat dibaca berdasarkan aturan lintas asal browser, bukan hanya atribut unduhan pada URL jarak jauh. Pengujian yang terlihat sangatlah mudah: menyimpan JPEG yang terverifikasi akan membuat nama file ToolAcre tanpa menambahkan permintaan i.ytimg.com lainnya.
ToolAcre sudah mengambil setiap kandidat JPEG untuk menentukan apakah kandidat tersebut asli. Mempertahankan Blob yang berhasil berarti pengunduhan selanjutnya dapat menggunakan byte yang sama alih-alih mengeluarkan permintaan jaringan kedua. Penggunaan kembali tersebut membuat file yang disimpan tetap identik dengan gambar yang dimensi dan status placeholdernya telah diperiksa beberapa saat sebelumnya.
Mengapa browser mengabaikan unduhan dari sumber lain — keputusan keamanan dan konsekuensinya
Browser membatasi download lintas asal karena halaman tidak boleh mengganti nama secara diam-diam dan menyimpan sumber daya jarak jauh secara sembarangan. Perilaku bergantung pada respons jarak jauh dan hubungan asal, jadi tautan sederhana bukanlah API penyimpanan file universal. Atribut `download` saja tidak dapat menjamin bahwa gambar YouTube jarak jauh akan disimpan dengan nama lokal yang diminta.
Desain yang lebih aman bersifat eksplisit: meminta gambar publik yang diungkapkan, memverifikasi respons, dan membuat objek yang dikelola browser URL hanya untuk data yang boleh dibaca oleh halaman tersebut. Jika CORS memblokir akses, JavaScript tidak memiliki Blob untuk divalidasi atau disimpan, meskipun menavigasi langsung ke alamat gambar mungkin masih menampilkannya di tab.
Rute pengambilan dan Blob — mengambil byte gambar, membungkusnya dalam Blob, dan membuat blob asal yang sama: URL
Untuk JPEG, probeThumbnail melakukan CORS GET anonim, mengonversi respons yang berhasil menjadi Blob dan mendekode dimensi. Blob yang dapat digunakan dipertahankan pada hasil, sementara placeholder dibuang sehingga tidak dapat menyamar sebagai unduhan. Oleh karena itu, tombol unduh mewakili byte terverifikasi dalam memori, bukan keyakinan yang disimpulkan dari nama file atau HTTP 200 saja.
Sebuah objek URL kemudian dapat mewakili Blob dalam memori tersebut untuk tindakan penyimpanan lokal. Ini tidak membuat pengambilan asli menjadi lokal; Google menyediakan byte langsung ke browser setelah Ambil. Alamat `blob:` adalah pegangan browser sementara untuk isi respons tersebut, bukan mirror yang dihosting oleh ToolAcre atau hak yang baru diberikan atas gambar sumber.
CORS mengizinkan JPEG pengunduhan pengambilan dan Blob; WebP tetap hanya berupa tautan
Garis besarnya menyiratkan CORS adalah salah satu gerbang umum, tetapi perilaku yang dikirimkan bersifat spesifik format. JPEG unduhan pengambilan dan Blob berfungsi; jalur /vi_webp/ dilayani tanpa header lintas asal yang diperlukan, jadi ToolAcre menyediakan WebP sebagai tautan saja. Peninjau harus menguji kedua kelompok jalur secara terpisah daripada menggeneralisasi header respons JPEG ke setiap format thumbnail.
Batasan tersebut tidak diperbaiki dengan mengubah JavaScript atau mencoba ulang melalui ToolAcre, karena tidak ada proksi ToolAcre. Pemblokir, koneksi offline, atau proxy perusahaan juga dapat menghentikan sumber daya jarak jauh. Akses WebP khusus tautan secara akurat mencerminkan apa yang diizinkan oleh server jarak jauh untuk dilakukan laman: mengarahkan ke file, namun tidak membaca byte-nya untuk dikemas ulang.
Memberi nama pada file yang disimpan — mengapa pengunduh harus menamainya berdasarkan ID dan ukuran video agar file tetap dapat diidentifikasi
Nama JPEG yang diunduh menggunakan youtube-VIDEO_ID-VARIANT.jpg. Pengidentifikasi dan varian berasal dari alfabet yang divalidasi, sehingga mencegah pemisah jalur atau karakter kontrol sewenang-wenang memasukkan nama file yang disarankan. Oleh karena itu, menyimpan `maxresdefault` dan `hq2` dari satu pencarian akan menghasilkan nama yang berbeda dan dapat diprediksi yang dapat dicocokkan kembali dengan baris hasilnya.
Nama file deskriptif mempertahankan asal ketika beberapa ukuran berada dalam satu folder. Hal ini juga menghindari berpura-pura bahwa judul metadata adalah nama sistem file yang aman, karena judul dapat berisi tanda baca dan dapat berubah secara independen. ID yang tidak dapat diubah mengidentifikasi referensi video, sedangkan akhiran varian menjelaskan kandidat gambar yang dipublikasikan mana yang menyediakan byte.
Contoh praktis: menyimpan dua ukuran thumbnail untuk satu video — urutan permintaan dan file yang dihasilkan
Ambil satu video publik dan pilih dua varian JPEG yang tersedia. Masing-masing diminta satu kali selama pemeriksaan, diterjemahkan untuk membuktikan dimensi dan disimpan sebagai Blob; mengklik simpan akan menggunakan kembali hasil itu dan menghasilkan dua file dengan nama yang jelas. Dengan DevTools terbuka, tidak adanya permintaan gambar kedua mengonfirmasi bahwa penyimpanan berasal dari respons yang dipertahankan, bukan dari download jarak jauh yang baru.
Jika salah satu kandidat mengembalikan HTTP 200 sebagai placeholder 120×90, alat akan menandainya hilang dan tidak menyimpan Blob yang dapat diunduh. 404, kesalahan lain atau respons yang tidak dapat didekodekan juga dilaporkan daripada disimpan. Menonaktifkan tindakan simpan untuk baris ini mencegah placeholder umum atau muatan kesalahan memasuki folder aset dengan nama varian yang meyakinkan.
Apa yang tidak tercakup dalam hal ini — pengunduhan batch di banyak video, dan host yang memblokir pembacaan lintas asal
Tidak ada mode batch di banyak video dan tidak ada jalan pintas untuk host yang melarang pembacaan lintas asal. Produk ini menangani satu video dalam satu waktu dan membatasi dirinya pada dua layanan Google yang diungkapkan. Setiap Blob yang disimpan merupakan bagian dari kumpulan hasil saat ini, sehingga tidak boleh diperlakukan sebagai cache yang tahan lama untuk video selanjutnya atau versi mendatang dari thumbnail yang sama.
Itu juga tidak mengambil video atau audio, dan rekaman pribadi, yang dihapus atau dibatasi usia tetap tidak tersedia. Mekanisme penyimpanan file publik tidak dapat memperluas hak akses atau membuat thumbnail yang tidak ada. Pembuatan blob dimulai hanya setelah byte gambar yang dapat dibaca tiba, sehingga tidak menawarkan rute untuk respons yang ditolak atau varian yang tidak dipublikasikan.
JPEG ambil, gunakan kembali Blob, dan unduh—dengan WebP disimpan sebagai tautan
Sebelum Pengambilan, penguraian URL bersifat lokal. Setelah itu, setiap pemeriksaan JPEG dan permintaan oEmbed kanonik langsung dari browser dengan kredensial dihilangkan, tanpa perujuk, tanpa penyimpanan, dan pengalihan yang diikuti; Google melihat header Asal. Tanggal pengunduhan penting secara independen, karena baik objek URL maupun jalur sumber yang dapat diprediksi tidak mempertahankan revisi thumbnail sebelumnya.
Hasilnya sengaja dibuat asimetris: JPEG byte terverifikasi dapat menjadi unduhan Blob, sementara lima URL poster WebP tetap menjadi tautan eksternal karena tanggapan mereka tidak memiliki izin CORS. Antarmuka harus menjaga batasan jujur itu. Pengguna dapat membuka atau menyalin alamat WebP, tetapi ToolAcre tidak dapat menjanjikan file WebP lokal yang diganti namanya dari byte yang dilarang oleh browser untuk dibaca.