视频和字幕·直接媒体下载器
下载文件的名称来自哪里：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 后，比较名称、扩展名、内容类型、预期来源和实际可玩性。这些观察回答了不同的问题。干净的文件名可以提高处理能力，但只有主机的字节和接收应用程序才能确定文件真正包含的内容。文件名选择提高了可用性，而来源仍然来自授权来源、记录的请求以及对完整字节的独立检查。