影片和字幕 · YouTube 縮圖下載器和元資料檢視器
瀏覽器如何保存跨來源影像：取得、Blob URL 和下載
· 工作原理
youtube JavaScript 科爾斯
保存來自另一個網域的圖片比保存具有下載屬性的連結更困難。這篇文章解釋了為什麼跨域 URL 會忽略該屬性、fetch 和 Blob URL 如何解決它以及 CORS 與它有何關係。
下載屬性打開了圖片而不是保存它 - 跨源捕獲
指向不同原點的錨點可能會導覽至影像，而不是遵循所需的檔案名稱。可靠的下載程式需要在瀏覽器跨網域規則下具有可讀字節，而不僅僅是遠端 URL 上的下載屬性。可見測試很簡單：儲存經過驗證的 JPEG 應該建立 ToolAcre 檔案名，而無需新增另一個 i.ytimg.com 要求。
ToolAcre 已取得每個 JPEG 候選者以確定其是否真實。保留成功的 Blob 意味著稍後的下載可以使用這些相同的字節，而不是發出第二個網路請求。這種重複使用使已儲存的檔案與先前檢查過尺寸和占位符狀態的影像相同。
為什麼瀏覽器會忽略其他來源的下載 - 安全決策及其後果
瀏覽器限制跨來源下載，因為頁面不應默默地重新命名和保存任意遠端資源。行為取決於遠端回應和來源關係，因此簡單的連結並不是通用的檔案保存 API。僅 `download` 屬性無法保證遠端 YouTube 映像將以請求的本機名稱儲存。
更安全的設計是明確的：請求公開的公共映像，驗證回應，並僅為允許頁面讀取的資料建立瀏覽器管理的物件 URL。如果 CORS 阻止訪問，JavaScript 就沒有 Blob 來驗證或儲存，即使直接導航到影像位址仍可能在分頁中顯示它。
fetch-and-Blob 路由 — 取得影像位元組，將它們包裝在 Blob 中並建立同源 blob：URL
對於 JPEG，probeThumbnail 執行匿名 CORS GET，將成功回應轉換為 Blob 並解碼維度。結果中保留了可用的 Blob，而佔位符則被丟棄，因此它們無法偽裝成下載。因此，下載按鈕代表記憶體中經過驗證的位元組，而不是單獨從檔案名稱或 HTTP 200 推斷出的置信度。
然後，物件 URL 可以代表本機保存作業的記憶體中 Blob。這不會使原始的 fetch 成為本地的； Google 在 Fetch 後直接將位元組提供給瀏覽器。 `blob:` 位址是該回應正文的臨時瀏覽器句柄，而不是 ToolAcre 所託管的鏡像或新授予的來源影像權限。
CORS 允許 JPEG fetch-and-Blob 下載； WebP 仍然僅連結
摘要暗示 CORS 是一種通用門，但交付的行為是特定於格式的。 JPEG fetch-and-Blob 下載有效； /vi_webp/ 路徑在沒有所需的跨域標頭的情況下提供，因此 ToolAcre 僅提供 WebP 作為連結。審查者應分別測試兩個路徑系列，而不是將 JPEG 回應標頭推廣到每種縮圖格式。
此限制無法透過更改 JavaScript 或透過 ToolAcre 重試來修復，因為不存在 ToolAcre 代理程式。阻止程式、離線連線或公司代理也可以停止任一遠端資源。僅連結 WebP 存取準確地反映了遠端伺服器允許頁面執行的操作：指向檔案，但不讀取其位元組以進行重新打包。
命名已儲存的檔案 - 為什麼下載器應按視訊 ID 和大小命名，以便檔案保持可識別性
下載的 JPEG 名稱使用 youtube-VIDEO_ID-VARIANT.jpg。標識符和變體都來自經過驗證的字母表，防止路徑分隔符號或任意控製字元輸入建議的檔案名稱。因此，從一次查找中儲存 `maxresdefault` 和 `hq2` 應該會產生不同的、可預測的名稱，這些名稱可以符合回其結果行。
當多個尺寸位於一個資料夾中時，描述性檔案名稱可以保留出處。它還避免假裝元資料標題是安全的檔案系統名稱，因為標題可以包含標點符號並可以獨立更改。不可變 ID 標識視訊參考，而變體後綴解釋哪個已發布的圖片候選者提供了位元組。
工作範例：為一個影片儲存兩個縮圖大小 - 請求序列和產生的檔案
取得公開影片並選擇兩個可用的 JPEG 變體。每個在探測過程中都被請求一次，解碼以證明維度並保留為 Blob；點擊「儲存」應重複使用該結果並產生兩個名稱明確的檔案。開啟 DevTools 後，如果沒有第二個映像請求，則確認儲存來自保留的回應，而不是新的遠端下載。
如果候選者傳回 HTTP 200 作為 120×90 佔位符，工具會將其標記為遺失，並不會儲存可下載的 Blob。 404、其他錯誤或無法解碼的回應同樣會被報告而不是保存。停用這些行的儲存操作可防止通用佔位符或錯誤負載以令人信服的變體名稱進入資產資料夾。
這不包括 - 跨多個視訊的批次下載，以及阻止跨來源讀取的主機
許多視訊沒有批次模式，也沒有繞過禁止跨來源讀取的主機。該產品一次處理一個視頻，並將其自身限制為兩項公開的谷歌服務。每個保留的 Blob 都屬於當前結果集，因此不應將其視為後續視訊或同一縮圖的未來版本的持久快取。
它也不會檢索視頻或音頻，並私人、已刪除或有年齡限制的記錄仍然不可用。公共檔案保存機制無法擴展存取權限或製作缺失的縮圖。 Blob 建立僅在可讀影像位元組到達後開始，因此它不提供繞過拒絕回應或未發布變體的路由。
JPEG 取得、Blob 重複使用和下載 - 將 WebP 保留為連結
在 Fetch 之前，URL 解析是本地的。之後，每個 JPEG 探測和規範的 oEmbed 請求直接從瀏覽器發出，省略憑證、無引薦來源網址、無儲存並遵循重定向； Google 會看到 Origin 標頭。獨立地確定重要下載的日期，因為物件 URL 和可預測的來源路徑都不會保留早期的縮圖修訂版本。
結果是故意不對稱的：經過驗證的 JPEG 位元組可以成為 Blob 下載，而五個 WebP 海報 URL 仍然是外部連結，因為它們的回應缺乏 CORS 權限。介面應該保留誠實的邊界。使用者可以開啟或複製 WebP 位址，但 ToolAcre 無法承諾從瀏覽器禁止讀取的位元組重新命名本機 WebP 檔案。