影片與字幕·直接媒體下載器
下載檔案的名稱來自哪裡：URL 路徑與內容處置
· 工作原理
http 下載 媒體
解釋瀏覽器如何決定呼叫已儲存檔案的內容：URL 的最後一段、伺服器的 Content-Disposition 標頭以及工具可以設定的下載屬性。說明為什麼乾淨的 URL 有時仍然會產生錯誤的檔案名稱。
檔案儲存為「file.php」且無法開啟 - 直接連結可以隱藏的命名問題
以 `file.php?id=42` 結尾的 URL 可以傳輸視訊位元組，同時給瀏覽器留下無用的路徑名稱。相反，以 `.mp4` 結尾的位址可以傳回 HTML。檔案名稱是從請求和回應元資料中選擇的標籤，而不是有關內部有效負載的證明。
Direct Media Downloader 僅在成功的 GET 回應到達後才計算建議名稱。它首先檢查 Content-Disposition，然後檢查最後一個非空路徑段，然後檢查基於 MIME 的小型回退。與聲稱瀏覽器執行通用協商相比，此順序更窄且更可預測。這種分離可以防止臨時授權材料洩漏到磁碟名稱中，並避免整個查詢字串產生非法檔案名稱符。
最後一個路徑段：預設猜測 - 瀏覽器如何從 URL 讀取檔案名稱以及查詢字串在哪裡混淆
路徑候選是斜槓分隔後的最終段，從百分比編碼解碼。不包含查詢參數，因為 URL API 單獨儲存它們。因此 `/episodes/launch.mp3?token=...` 產生 `launch.mp3`，而尾斜槓沒有最終段並需要另一個來源。
此路徑規則不會決定擴充是否誠實。簽署的傳遞路由可以隱藏參數中的人工標題，且此實作不會挖掘任意名稱查詢鍵。這種限制可以避免將簽章元件、活動值或記錄標識符誤認為檔案名稱。當兩種形式都存在時，國際化形式可以更清楚地保留非 ASCII 名稱，而後備形式可以處理更簡單的伺服器實作。
Content-Disposition：伺服器的建議 — 標頭如何覆蓋 URL 的名稱以及為什麼某些 CDN 設定它而其他 CDN 不設定
Content-Disposition 可以攜帶普通的 `filename=` 建議或編碼的 UTF-8 `filename*=` 形式。 ToolAcre 給出編碼的星形優先級並嘗試百分比解碼；如果解碼失敗，它會轉至普通形式，然後轉至路徑邏輯，而不是使已完成的傳輸崩潰。
標頭只是服務主機的建議。應用程式程式碼不會檢查媒體元資料來驗證它，並誤導性的伺服器可能會提供誤導性的名稱。在開啟檔案之前檢查不常見的字元和副檔名，尤其是當來源主機不熟悉時。物件 URL 是臨時瀏覽器引用，而不是遠端位址，並它們的使用不會為媒體正文建立另一個上傳或 HTTP 請求。
下載屬性：工具可以自行設定的內容 — 瀏覽器端下載程式如何為其儲存的 Blob 選擇名稱
Blob 準備好後，UI 將 Blob 和選定的檔案名稱傳遞到共用下載實用程式。該實用程式使用物件 URL 和下載名稱觸發瀏覽器保存行為。最後一次點擊時不再查詢伺服器的標頭，因為它的建議已解決。
此機制不會重新命名現有磁碟檔案或選擇資料夾。瀏覽器設定仍決定是否出現對話方塊以及如何處理重複名稱。 ToolAcre 提供一名候選人；瀏覽器和訪客仍然對最終的檔案系統結果負責。使用者應該抵制僅透過重命名來「修復」不匹配的情況；在決定元資料或內容是否需要更正之前檢查實際的容器和編解碼器。
副檔名和 MIME 類型：保持它們一致 - 為什麼一個名為 .mp4 的檔案實際上是 WebM 會讓玩家感到困惑
`.mp4` 名稱與 `video/webm` 配對可能會混淆透過擴充進行路由的軟體，即使有能力的播放器可以檢查位元組。 ToolAcre 保留路徑或標頭名稱，而不是重寫其副檔名以符合 Content-Type。它還保留 Blob 上的伺服器 MIME 值。
如果不存在標頭和路徑段，則回退會識別包含 WebM 或 MP4 的內容類型並傳回 `download.webm` 或 `download.mp4`；所有其他類型都會變成 `download.bin`。音訊 MIME 值目前不透過此最後手段分支接收特殊擴展。如果簽章在 HEAD 和 GET 之間過期，則不會有任何檔案名稱獲勝，因為正文請求失敗；僅在成功讀取回應後才開始命名。
工作範例：一個已簽署的 CDN 連結和三個可能的檔案名稱 — 詳細了解哪個名稱獲勝以及原因
取得一個簽署的 CDN 位址，其路徑以 `asset` 結尾，其回應為 `filename*=UTF-8''approved%20cut.mp4`，其類型為 `video/mp4`。編碼後的標頭獲勝，產生 `approved cut.mp4`。刪除標頭，路徑產生 `asset`；也刪除該段，MIME 後備會產生 `download.mp4`。
普通的 `filename="review.webm"` 將會獲勝，即使路徑顯示 `clip.mp4`。此範例顯示優先級，而不是驗證。選擇名稱後，檢查內容類型並在受信任的軟體中開啟已儲存的結果仍然是單獨的檢查。目錄可以在儲存後另外記錄校驗和，但雜湊位於該下載程式之外，並不應透過其顯示的位元組數來暗示。
這不包括什麼 - 下載後重命名、批量命名或讀取檔案內的元資料來命名
下載程式不會對檔案進行批次處理、從媒體容器中讀取標題標籤、清理存檔目錄或在儲存後修復誤導性副檔名。它也不能保證每個內容處置語法變體都與其關注的正規表示式相符。
稍後重新命名是作業系統任務。如果歸檔命名很重要，請在您自己的目錄中記錄來源 URL、回應類型、位元組數和核准的描述性名稱。不要將方便的標頭視為來源或將檔案副檔名視為加密身分。路徑中格式錯誤的百分比編碼是另一個主機品質問題；目前的後備方案並未聲稱將每個伺服器提供的名稱清理到每個作業系統的規則中。
重點：名稱是 URL、標頭和工具之間的協商 — 使用 Direct Media Downloader 後要檢查保存檔案的名稱和副檔名
實現的優先權是具體的：有效的 UTF-8 星號檔名、普通檔名、解碼的最終路徑段，然後是 `download.webm`、`download.mp4` 或 `download.bin`。查詢字串可以授權傳送，而不會成為已儲存名稱的一部分。這解釋了許多“下載”和“索引”的意外。
使用 Direct Media Downloader 後，比較名稱、副檔名、內容類型、預期來源和實際可玩性。這些觀察回答了不同的問題。乾淨的檔案名稱可以提高處理能力，但只有主機的位元組和接收應用程式才能確定檔案真正包含的內容。檔案名稱選擇提高了可用性，而來源仍然來自授權來源、記錄的請求以及對完整位元組的獨立檢查。