Vídeo y subtítulos · Descargador de miniaturas y visor de metadatos de YouTube
Cómo guarda un navegador una imagen de origen cruzado: buscar, URL de Blob y descargar
· Cómo funciona
youtube javascript cors
Guardar una imagen de otro dominio es más difícil que un enlace con un atributo de descarga. Esta publicación explica por qué el atributo se ignora para las URL de origen cruzado, cómo las URL de recuperación y Blob lo resuelven y qué tiene que ver CORS con eso.
El atributo de descarga abrió la imagen en lugar de guardarla: la captura de origen cruzado
Un ancla que apunta a un origen diferente puede navegar a una imagen en lugar de respetar el nombre de archivo deseado. Un descargador confiable necesita bytes legibles según las reglas de origen cruzado del navegador, no simplemente un atributo de descarga en una URL remota. La prueba visible es sencilla: guardar un JPEG verificado debería crear el nombre de archivo ToolAcre sin agregar otra solicitud i.ytimg.com.
ToolAcre ya busca cada candidato JPEG para determinar si es real. Mantener el Blob exitoso significa que la descarga posterior puede usar esos mismos bytes en lugar de emitir una segunda solicitud de red. Esa reutilización mantiene el archivo guardado idéntico a la imagen cuyas dimensiones y estado del marcador de posición se inspeccionaron momentos antes.
Por qué los navegadores ignoran las descargas de otros orígenes: una decisión de seguridad y sus consecuencias
Los navegadores restringen las descargas entre orígenes porque una página no debe cambiar el nombre ni guardar silenciosamente recursos remotos arbitrarios. El comportamiento depende de la respuesta remota y la relación de origen, por lo que un enlace simple no es una API universal para guardar archivos. El atributo `download` por sí solo no puede garantizar que una imagen remota de YouTube se guarde con el nombre local solicitado.
El diseño más seguro es explícito: solicitar una imagen pública divulgada, verificar la respuesta y construir una URL de objeto administrada por el navegador solo para los datos que la página tenía permitido leer. Si CORS bloquea el acceso, JavaScript no tiene ningún Blob para validar o guardar, aunque navegar directamente a la dirección de la imagen aún puede mostrarla en una pestaña.
La ruta de búsqueda y blob: buscar los bytes de la imagen, envolverlos en un Blob y crear un blob del mismo origen: URL
Para JPEG, probeThumbnail realiza un CORS GET anónimo, convierte una respuesta exitosa en un Blob y decodifica dimensiones. Se conserva un Blob utilizable en el resultado, mientras que los marcadores de posición se descartan para que no puedan hacerse pasar por descargas. Por lo tanto, el botón de descarga representa bytes verificados en la memoria, no la confianza inferida de un nombre de archivo o HTTP 200 únicamente.
Una URL de objeto puede representar ese Blob en memoria para una acción de guardado local. Esto no hace que la recuperación original sea local; Google proporcionó los bytes directamente al navegador después de Fetch. La dirección `blob:` es un identificador temporal del navegador para ese cuerpo de respuesta, no un espejo alojado por ToolAcre ni un derecho recién otorgado a la imagen de origen.
CORS permite JPEG descargas de búsqueda y blob; WebP sigue siendo solo enlace
El esquema implicaba que CORS era una puerta genérica, pero el comportamiento enviado es específico del formato. La descarga de JPEG funciona con Fetch-and-Blob; la ruta /vi_webp/ se sirve sin el encabezado de origen cruzado requerido, por lo que ToolAcre proporciona WebP solo como enlace. Un revisor debería probar las dos familias de rutas por separado en lugar de generalizar los encabezados de respuesta JPEG a cada formato de miniatura.
Esa limitación no se repara cambiando JavaScript o reintentando a través de ToolAcre, porque no existe ningún proxy de ToolAcre. Un bloqueador, una conexión fuera de línea o un proxy corporativo también pueden detener cualquiera de los recursos remotos. El acceso de solo enlace WebP refleja con precisión lo que el servidor remoto permite que haga la página: apuntar al archivo, pero no leer sus bytes para volver a empaquetarlo.
Nombrar el archivo guardado: por qué un descargador debería nombrarlo por ID de video y tamaño para que los archivos sigan siendo identificables
Los nombres JPEG descargados usan youtube-VIDEO_ID-VARIANT.jpg. Tanto el identificador como la variante provienen de alfabetos validados, lo que evita que los separadores de ruta o los caracteres de control arbitrarios ingresen al nombre de archivo sugerido. Por lo tanto, guardar `maxresdefault` y `hq2` de una búsqueda debería producir nombres distintos y predecibles que puedan compararse con sus filas de resultados.
Un nombre de archivo descriptivo conserva la procedencia cuando varios tamaños se encuentran en una carpeta. También evita pretender que el título de los metadatos es un nombre de sistema de archivos seguro, ya que los títulos pueden contener puntuación y cambiar de forma independiente. El ID inmutable identifica la referencia del vídeo, mientras que el sufijo variante explica qué imagen candidata publicada proporcionó los bytes.
Ejemplo resuelto: guardar dos tamaños de miniatura para un video: la secuencia de solicitudes y los archivos resultantes
Obtenga un video público y elija dos variantes JPEG disponibles. Cada uno fue solicitado una vez durante el sondeo, decodificado para probar las dimensiones y retenido como un Blob; Al hacer clic en Guardar se debería reutilizar ese resultado y producir dos archivos con nombres claros. Con DevTools abierto, la ausencia de una segunda solicitud de imagen confirma que el guardado provino de la respuesta retenida en lugar de una nueva descarga remota.
Si un candidato devuelve HTTP 200 como marcador de posición 120×90, la herramienta marca que falta y no almacena ningún Blob descargable. Un 404, otro error o una respuesta no decodificable también se informa en lugar de guardarse. Deshabilitar la acción de guardar para estas filas evita que un marcador de posición genérico o una carga útil de error ingrese a una carpeta de activos con un nombre de variante convincente.
Lo que esto no cubre: descargas por lotes en muchos videos y hosts que bloquean lecturas entre orígenes.
No hay modo por lotes en muchos videos ni omisión para hosts que prohíben la lectura entre orígenes. El producto procesa un vídeo a la vez y se limita a los dos servicios de Google mencionados. Cada Blob retenido pertenece al conjunto de resultados actual, por lo que no debe tratarse como un caché duradero para vídeos posteriores o versiones futuras de la misma miniatura.
Tampoco recupera vídeo ni audio, y los registros privados, eliminados o con restricción de edad siguen sin estar disponibles. Un mecanismo público para guardar archivos no puede ampliar los derechos de acceso ni crear una miniatura ausente. La creación de blobs comienza solo después de que llegan los bytes de imagen legibles, por lo que no ofrece ninguna ruta para evitar una respuesta denegada o una variante no publicada.
JPEG búsqueda, reutilización y descarga de blobs, con WebP mantenido como vínculo
Antes de Fetch, el análisis de URL es local. Luego, cada sonda JPEG y la solicitud canónica de oEmbed van directamente desde el navegador con credenciales omitidas, sin referencia, sin almacenamiento y con redireccionamientos seguidos; Google ve el encabezado de Origin. Fecha las descargas importantes de forma independiente, porque ni la URL del objeto ni la ruta de origen predecible conservan una revisión en miniatura anterior.
El resultado es deliberadamente asimétrico: JPEG bytes verificados pueden convertirse en descargas de Blob, mientras que cinco URL de carteles WebP siguen siendo enlaces externos porque sus respuestas carecen del permiso CORS. La interfaz debe preservar ese límite honesto. Los usuarios pueden abrir o copiar una dirección WebP, pero ToolAcre no puede prometer un archivo WebP local renombrado a partir de bytes que el navegador le prohíbe leer.