Видео и субтитры · Загрузчик медиафайлов по прямой ссылке
Откуда берется имя загруженного файла: URL путь vs Content-Disposition
· Как это работает
http загрузки СМИ
Объясняет, как браузер решает, как называть сохраненный файл: последний сегмент URL, заголовок Content-Disposition сервера и атрибут загрузки, который может установить инструмент. Показывает, почему чистый URL иногда по-прежнему дает неправильное имя файла.
Файл сохранен как «file.php» и не открывается — проблема с именованием, которую может скрыть прямая ссылка.
URL, заканчивающийся на `file.php?id=42`, может доставлять видеобайты, оставляя браузер с бесполезным именем пути. И наоборот, адрес, заканчивающийся на `.mp4`, может возвращать HTML. Имя файла — это метка, выбранная из метаданных запроса и ответа, а не подтверждение полезной нагрузки внутри.
Direct Media Downloader вычисляет предложенное имя только после получения успешного ответа GET. Сначала он проверяет Content-Disposition, затем последний непустой сегмент пути, а затем небольшой резервный вариант на основе MIME. Этот порядок уже и более предсказуем, чем утверждение, что браузер выполняет универсальное согласование. Такое разделение предотвращает утечку временных материалов авторизации в имя диска и позволяет избежать недопустимых символов имени файла, вносимых во всю строку запроса.
Последний сегмент пути: предположение по умолчанию — как браузер читает имя файла из URL и где строки запроса его путают.
Кандидат пути — это последний сегмент после разделения косой чертой, декодированный из процентного кодирования. Параметры запроса не включены, поскольку URL API хранит их отдельно. Таким образом, `/episodes/launch.mp3?token=...` дает `launch.mp3`, а конечная косая черта не имеет конечного сегмента и требует другого источника.
Это правило пути не определяет, является ли расширение честным. Подписанный маршрут доставки может скрыть человеческий титул в параметре, и эта реализация не будет анализировать произвольные ключи запроса для имен. Это ограничение позволяет избежать ошибочного принятия компонента подписи, значения кампании или идентификатора записи за имя файла. Когда существуют обе формы, интернационализированная форма может более четко сохранять имена, отличные от ASCII, в то время как резервная форма обрабатывает более простые реализации сервера.
Content-Disposition: предложение сервера — как заголовок может переопределить имя URL и почему некоторые CDN его устанавливают, а другие нет.
Content-Disposition может содержать простое предложение `filename=` или закодированную форму UTF-8 `filename*=`. ToolAcre дает приоритет закодированной звездообразной форме и пытается выполнить процентное декодирование; если декодирование не удается, оно переходит в простую форму, а затем в логику пути, а не приводит к сбою завершенной передачи.
Заголовок — это всего лишь предложение обслуживающего хоста. Код приложения не проверяет метаданные мультимедиа для их проверки, а вводящий в заблуждение сервер может предоставить вводящее в заблуждение имя. Прежде чем открывать файл, просмотрите необычные символы и расширения, особенно если исходный хост незнаком. URL-адреса объектов являются временными ссылками браузера, а не удаленными адресами, и их использование не приводит к повторной загрузке или запросу HTTP для тела мультимедиа.
Атрибут загрузки: что может установить инструмент — как загрузчик на стороне браузера может выбрать имя для сохраняемого BLOB-объекта.
После того как большой двоичный объект готов, пользовательский интерфейс передает как большой двоичный объект, так и выбранное имя файла в общую утилиту загрузки. Эта утилита запускает сохранение в браузере с помощью объекта URL и имени загрузки. Заголовок сервера больше не используется при последнем щелчке мыши, поскольку его предложение уже было решено.
Этот механизм не переименовывает существующий файл на диске и не выбирает папку. Настройки браузера по-прежнему определяют, появится ли диалоговое окно и как будут обрабатываться повторяющиеся имена. ToolAcre предоставляет одного кандидата; браузер и посетитель остаются ответственными за конечный результат работы файловой системы. Пользователи не должны «исправлять» несоответствия путем переименования; проверьте фактический контейнер и кодеки, прежде чем решить, нуждаются ли метаданные или контент в исправлении.
Расширения и типы MIME: обеспечение их единообразия — почему файл с именем .mp4, который на самом деле является WebM, сбивает игроков с толку
Имя `.mp4` в сочетании с `video/webm` может сбить с толку программное обеспечение, маршрутизирующее по расширению, даже если способный игрок может проверить байты. ToolAcre сохраняет путь или имя заголовка, а не переписывает его расширение в соответствии с Content-Type. Он также сохраняет значение сервера MIME в большом двоичном объекте.
Если заголовок и сегмент пути отсутствуют, резервный вариант распознает Content-Type, содержащий 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`. В примере показан приоритет, а не проверка. Проверка Content-Type и открытие сохраненного результата в доверенном программном обеспечении остаются отдельными проверками после выбора имени. Каталог может дополнительно записывать контрольную сумму после сохранения, но хеширование находится за пределами этого загрузчика и не должно подразумеваться отображаемым количеством байт.
Что сюда не входит — переименование после загрузки, пакетное именование или чтение метаданных внутри файла для присвоения ему имени.
Загрузчик не нумерует файлы в пакетном режиме, не считывает теги заголовков из медиаконтейнера, не очищает каталог архива и не исправляет вводящее в заблуждение расширение после сохранения. Он также не может обещать, что каждый вариант грамматики Content-Disposition будет соответствовать его целевым регулярным выражениям.
Позднее переименование является задачей операционной системы. Если архивное именование имеет значение, запишите источник URL, тип ответа, количество байтов и утвержденное описательное имя в своем собственном каталоге. Не рассматривайте удобный заголовок как источник происхождения или расширение имени файла как криптографический идентификатор. Неверное процентное кодирование пути — еще одна проблема качества хоста; текущий запасной вариант не претендует на то, чтобы привести каждое имя, предоставленное сервером, в правила каждой операционной системы.
Вывод: имя является результатом согласования между URL, заголовком и инструментом — что нужно проверить в имени и расширении сохраненного файла после использования Direct Media Downloader
Реализованный приоритет конкретен: допустимое имя файла со звездочкой UTF-8, простое имя файла, декодированный конечный сегмент пути, затем `download.webm`, `download.mp4` или `download.bin`. Строки запроса могут авторизовать доставку, не становясь частью сохраненного имени. Это объясняет многие сюрпризы «загрузки» и «индексирования».
После использования Direct Media Downloader сравните имя, расширение, тип контента, ожидаемый источник и фактическую возможность воспроизведения. Эти наблюдения отвечают на разные вопросы. Чистое имя файла улучшает обработку, но только байты хоста и принимающее приложение определяют, что на самом деле содержит файл. Выбор имени файла повышает удобство использования, в то время как происхождение по-прежнему определяется авторизованным источником, записанным запросом и независимой проверкой завершенных байтов.