Видео и субтитры · Загрузчик миниатюр YouTube и средство просмотра метаданных
Как браузер сохраняет изображение из разных источников: получение, URL-адреса Blob и загрузка
· Как это работает
ютуб javascript корс
Сохранить изображение с другого домена сложнее, чем ссылку с атрибутом скачивания. В этом посте объясняется, почему атрибут игнорируется для URL-адресов с перекрестным происхождением, как решают эту проблему URL-адреса fetch и Blob и какое отношение к этому имеет CORS.
Атрибут загрузки открывал изображение вместо того, чтобы сохранять его — ошибка перекрестного происхождения.
Якорь, указывающий на другое начало координат, может перейти к изображению вместо сохранения желаемого имени файла. Надежному загрузчику нужны читаемые байты в соответствии с правилами перекрестного происхождения браузера, а не просто атрибут загрузки на удаленном URL. Видимый тест прост: сохранение проверенного JPEG должно создать имя файла ToolAcre без добавления другого запроса i.ytimg.com.
ToolAcre уже выбирает каждого кандидата JPEG, чтобы определить, настоящий ли он. Сохранение успешного BLOB-объекта означает, что последующая загрузка может использовать те же байты вместо выдачи второго сетевого запроса. В результате повторного использования сохраненный файл остается идентичным изображению, размеры и статус заполнителя которого были проверены несколькими моментами ранее.
Почему браузеры игнорируют загрузку из других источников — решение безопасности и его последствия
Браузеры ограничивают загрузку из разных источников, поскольку страница не должна автоматически переименовываться и сохранять произвольные удаленные ресурсы. Поведение зависит от отношения удаленного ответа и источника, поэтому простая ссылка не является универсальным средством сохранения файла API. Атрибут `download` сам по себе не может гарантировать, что удаленное изображение YouTube будет сохранено под запрошенным локальным именем.
Более безопасная конструкция очевидна: запросите раскрытое общедоступное изображение, проверьте ответ и создайте управляемый браузером объект URL только для данных, которые странице разрешено читать. Если CORS блокирует доступ, JavaScript не имеет большого двоичного объекта для проверки или сохранения, хотя переход непосредственно к адресу изображения может по-прежнему отображать его на вкладке.
Маршрут выборки и Blob — получение байтов изображения, их упаковка в Blob и создание объекта Blob того же происхождения: URL
Для JPEG testThumbnail выполняет анонимный CORS GET, преобразует успешный ответ в Blob и декодирует измерения. В результате сохраняется пригодный для использования Blob, а заполнители отбрасываются, поэтому они не могут маскироваться под загрузки. Таким образом, кнопка загрузки представляет собой проверенные байты в памяти, а не достоверность, вытекающую из имени файла или только HTTP 200.
Затем объект URL может представлять этот BLOB-объект в памяти для локального действия сохранения. Это не делает исходную выборку локальной; Google предоставил байты непосредственно в браузер после Fetch. Адрес `blob:` — это временный дескриптор браузера для этого тела ответа, а не зеркало, размещенное на ToolAcre, или недавно предоставленное право на исходное изображение.
CORS позволяет загружать JPEG методом выборки и Blob; WebP остается только ссылкой
В схеме подразумевалось, что CORS представляет собой один общий шлюз, но поведение при поставке зависит от формата. JPEG загрузка с возможностью выборки и Blob работает; путь /vi_webp/ обслуживается без обязательного заголовка перекрестного происхождения, поэтому ToolAcre предоставляет WebP только как ссылку. Рецензент должен протестировать два семейства путей отдельно, а не обобщать заголовки ответов JPEG для каждого формата миниатюр.
Это ограничение не устраняется путем изменения JavaScript или повторной попытки через ToolAcre, поскольку прокси-сервер ToolAcre не существует. Блокировщик, автономное соединение или корпоративный прокси-сервер также могут остановить любой удаленный ресурс. Доступ только по ссылкам WebP точно отражает то, что удаленный сервер разрешает делать странице: указывать на файл, но не читать его байты для переупаковки.
Присвоение имени сохраненному файлу — почему загрузчик должен назвать его по идентификатору видео и размеру, чтобы файлы оставались идентифицируемыми
Загруженные имена JPEG используют youtube-VIDEO_ID-VARIANT.jpg. И идентификатор, и вариант взяты из проверенных алфавитов, что предотвращает ввод разделителей путей или произвольных управляющих символов в предлагаемое имя файла. Таким образом, сохранение `maxresdefault` и `hq2` из одного поиска должно привести к созданию отдельных, предсказуемых имен, которые можно будет сопоставить со строками результатов.
Описательное имя файла сохраняет происхождение, когда несколько размеров находятся в одной папке. Это также позволяет избежать предположения, что заголовок метаданных является безопасным именем файловой системы, поскольку заголовки могут содержать знаки препинания и могут изменяться независимо. Неизменяемый идентификатор идентифицирует ссылку на видео, а суффикс варианта объясняет, какой опубликованный кандидат-изображение предоставил байты.
Рабочий пример: сохранение двух размеров миниатюр для одного видео — последовательность запросов и файлы в результате
Загрузите одно общедоступное видео и выберите два доступных варианта JPEG. Каждый из них запрашивался один раз во время зондирования, декодировался для подтверждения размеров и сохранялся как Blob; нажатие кнопки «Сохранить» должно повторно использовать этот результат и создать два файла с четкими именами. При открытых DevTools отсутствие второго запроса изображения подтверждает, что сохранение произошло из сохраненного ответа, а не из новой удаленной загрузки.
Если один кандидат возвращает HTTP 200 в качестве заполнителя 120×90, инструмент помечает его как отсутствующий и не сохраняет загружаемый BLOB-объект. 404, другая ошибка или нерасшифрованный ответ также сообщается, а не сохраняется. Отключение действия сохранения для этих строк предотвращает попадание общего заполнителя или полезных данных ошибок в папку ресурсов под убедительным названием варианта.
Чего это не касается — пакетные загрузки многих видео и хосты, блокирующие чтение из разных источников.
Для многих видео нет пакетного режима и нет обхода хостов, запрещающих чтение из перекрестного источника. Продукт обрабатывает одно видео за раз и ограничивается двумя раскрытыми сервисами Google. Каждый сохраненный BLOB-объект принадлежит текущему набору результатов, поэтому его не следует рассматривать как надежный кэш для последующих видео или будущих версий того же эскиза.
Он также не извлекает видео или аудио, а личные, удаленные записи или записи с возрастными ограничениями остаются недоступными. Публичный механизм сохранения файлов не может расширить права доступа или создать отсутствующую миниатюру. Создание больших двоичных объектов начинается только после прибытия читаемых байтов изображения, поэтому оно не предлагает обходного пути в случае отказа в ответе или неопубликованного варианта.
JPEG извлечение, повторное использование и загрузка Blob — при этом WebP сохраняется в виде ссылки
До Fetch анализ URL является локальным. После этого каждый зонд JPEG и канонический запрос oEmbed отправляются прямо из браузера без учетных данных, без реферера, без хранилища и последующих перенаправлений; Google видит заголовок Origin. Дата важной загрузки загружается независимо, поскольку ни объект URL, ни предсказуемый исходный путь не сохраняют более раннюю версию эскиза.
Результат намеренно асимметричен: проверенные JPEG байты могут стать загрузками Blob, а пять URL-адресов плакатов WebP остаются внешними ссылками, поскольку их ответы не имеют разрешения CORS. Интерфейс должен сохранять эту честную границу. Пользователи могут открыть или скопировать адрес WebP, но ToolAcre не может обещать переименованный локальный файл WebP из байтов, которые браузер запрещает ему читать.