影片與字幕直接媒體下載器
瀏覽器如何使用 fetch 和 Blob 從直接鏈接下載文件
· 工作原理
下載 瀏覽器 API 科爾斯
遍歷瀏覽器工具用於將直接連結轉換為已儲存檔案的管道：取得位元組，將它們儲存為 Blob，然後將它們傳遞給下載屬性。解釋為什麼任何步驟都不需要伺服器。
該連結會開啟播放器而不是儲存檔案 - 點擊直接 MP4 或 MP3 連結通常會內聯播放，這是下載器解決的問題
點擊直接 MP3 連結可能會開啟播放器，因為瀏覽器知道如何播放該 MIME 類型。保存相同的位元組是一個單獨的操作。關鍵字是直接的：指向實際文件回應的鏈接，而不是包含播放器或列出媒體片段的清單的網頁。 ToolAcre 在提供下載之前進行了這種區分，並且不會假裝頁面 URL 是文件 URL。
第一步： fetch() 向主機詢問位元組－對所宣布的主機的 GET 請求是什麼樣的以及返回什麼
選擇「檢查連結」後，瀏覽器可能會向您提供的 URL 發出 HEAD 請求，以檢查狀態、類型和長度。取得檔案使用對該主機的 GET 請求，而不是 ToolAcre 代理程式。該請求故意省略憑證，因此需要您登入的主機可能會拒絕它。遠端伺服器還必須允許跨網域腳本讀取；如果 CORS 阻止訪問，該工具會解釋拒絕情況，而不是透過隱藏的中繼來繞過它。重定向可以更改目的地，因此請檢查公佈的主機。
第二步：回應正文變成 Blob — 如何在記憶體中收集位元組以及 Blob 為何攜帶 MIME 類型
響應主體被讀取為位元組區塊流。當主機公開它時，Progress可以使用Content-Length；如果沒有已知的長度，該工具可以顯示收到的位元組數，但不能顯示可靠的百分比。它在收集區塊時強制執行記憶體上限，然後使用傳回的內容類型組裝 Blob。這比在無限流上呼叫response.blob()更安全，但它不是零記憶體流到磁碟：完成的Blob仍然佔用瀏覽器會話中的空間。
第三步：URL.createObjectURL 和下載屬性 — 暫時 blob: URL 加上錨點如何觸發儲存對話框
Blob 是記憶體中的數據，而不是 Internet 位址。瀏覽器可以建立一個臨時的 blob:object URL 並將其附加到帶有下載檔案名稱的錨點；點擊該錨點會要求瀏覽器保存位元組。檔案名稱可能來自 Content-Disposition 標頭或 URL 路徑，而不是來自頁面標題。由於該連結現在是同頁 Blob URL，因此瀏覽器可以保存結果，而無需將其託管在 ToolAcre 上。在從不熟悉的來源開啟檔案之前檢查副檔名和 MIME 類型仍然是明智的做法。
工作範例：從其附件連結儲存播客劇集 - 將一個 MP3 從貼上的 URL 儲存到磁碟上的文件
想像一下，播客發布商公開了一個以 Episode.mp3 結尾的授權附件 URL。貼上確切的地址，檢查公佈的主機並使用檢查連結。如果允許 HEAD，它可能會顯示音訊/mpeg 和預期的位元組數；然後 Fetch 向發布者請求 MP3 字節，將它們串流傳輸到 Blob 並保存 Episode.mp3。如果主機省略 CORS 標頭，瀏覽器可以在自己的選項卡中播放該鏈接，而該頁面無法透過腳本獲取該鏈接； “鏈接另存為”可能是正確的路線。使用者保存文件的權利與其伺服器在技術上是否允許取得該文件是分開的。
清理：撤銷物件 URL 並釋放記憶體 - 為什麼建置良好的下載器會在儲存完成後釋放 Blob
臨時物件 URL 保留對其支援 Blob 的參考。讓每個 URL 保持活動狀態的下載程式可以將大檔案保留在長期存在的標籤中。 ToolAcre 的共用下載公用程式會為保存作業建立本機 URL，並在完成後撤銷它；取消釋放回應讀取器並丟棄部分區塊。對於非常大的文件，從主機下載普通瀏覽器比在頁面記憶體中收集整個回應更合適。
這不包括頁面 URL、串流媒體清單、DRM 和需要登入的鏈接
此工具不會找到隱藏在影片頁面後面的媒體、解析 HLS/DASH .m3u8 或 .mpd 清單、繞過 DRM、欺騙標頭或存取受會話保護的串流。它不會為您下載私有內容，也不會決定許可證是否授予複製檔案的權限。 403、登入頁面重定向或 CORS 錯誤是需要理解的邊界，而不是搜尋未記錄代理的提示。
重點：三個瀏覽器 API，無伺服器 — Direct Media Downloader 如何將此管道應用於您貼上的鏈接
管道從提供的主機取得 → 接收區塊 → 建立 Blob → 觸發本機下載。不涉及ToolAcre中繼，但絕對涉及對第三方主機的真實請求；它的日誌可以看到連接。 Direct Media Downloader 在進行聯繫之前會宣布該聯繫，並在瀏覽器安全規則拒絕跨來源讀取時告訴您。