Vídeo e legendas · Downloader de miniaturas do YouTube e visualizador de metadados
Como um navegador salva uma imagem de origem cruzada: busca, URLs de Blob e download
· Como funciona
YouTube javascript corpo
Salvar uma imagem de outro domínio é mais difícil do que um link com atributo de download. Esta postagem explica por que o atributo é ignorado para URLs de origem cruzada, como URLs de busca e Blob resolvem isso e o que CORS tem a ver com isso.
O atributo download abriu a imagem em vez de salvá-la – o problema de origem cruzada
Uma âncora apontada para uma origem diferente pode navegar para uma imagem em vez de respeitar o nome de arquivo desejado. Um downloader confiável precisa de bytes legíveis de acordo com as regras de origem cruzada do navegador, e não apenas de um atributo de download em um URL remoto. O teste visível é simples: salvar um JPEG verificado deve criar o nome de arquivo ToolAcre sem adicionar outra solicitação i.ytimg.com.
ToolAcre já busca cada candidato JPEG para determinar se é real. Manter o Blob bem-sucedido significa que o download posterior pode usar esses mesmos bytes em vez de emitir uma segunda solicitação de rede. Essa reutilização mantém o arquivo salvo idêntico à imagem cujas dimensões e status do espaço reservado foram inspecionados momentos antes.
Por que os navegadores ignoram o download de outras origens — uma decisão de segurança e suas consequências
Os navegadores restringem downloads de origem cruzada porque uma página não deve renomear silenciosamente e salvar recursos remotos arbitrários. O comportamento depende da resposta remota e do relacionamento de origem, portanto, um link simples não é um salvamento universal de arquivos API. O atributo `download` por si só não pode garantir que uma imagem remota do YouTube será salva com o nome local solicitado.
O design mais seguro é explícito: solicite uma imagem pública divulgada, verifique a resposta e construa um objeto gerenciado pelo navegador URL apenas para os dados que a página foi autorizada a ler. Se CORS bloquear o acesso, JavaScript não terá nenhum Blob para validar ou salvar, mesmo que navegar diretamente para o endereço da imagem ainda possa exibi-lo em uma guia.
A rota fetch-and-Blob — buscando os bytes da imagem, agrupando-os em um Blob e criando um blob de mesma origem: URL
Para JPEG, probeThumbnail executa um CORS GET anônimo, converte uma resposta bem-sucedida em um Blob e decodifica dimensões. Um Blob utilizável é retido no resultado, enquanto os espaços reservados são descartados para que não possam ser mascarados como downloads. O botão de download, portanto, representa bytes verificados na memória, não a confiança inferida de um nome de arquivo ou apenas de HTTP 200.
Um objeto URL pode então representar aquele Blob na memória para uma ação de salvamento local. Isso não torna a busca original local; O Google forneceu os bytes diretamente ao navegador após o Fetch. O endereço `blob:` é um identificador temporário do navegador para esse corpo de resposta, não um espelho hospedado por ToolAcre ou um direito recém-concedido à imagem de origem.
CORS permite downloads de JPEG fetch-and-Blob; WebP permanece apenas para link
O esboço implicava que CORS era uma porta genérica, mas o comportamento enviado é específico do formato. JPEG download fetch-and-Blob funciona; o caminho /vi_webp/ é servido sem o cabeçalho de origem cruzada necessário, portanto ToolAcre fornece WebP apenas como um link. Um revisor deve testar as duas famílias de caminhos separadamente, em vez de generalizar os cabeçalhos de resposta JPEG para cada formato de miniatura.
Essa limitação não é reparada alterando JavaScript ou tentando novamente por meio de ToolAcre, porque não existe proxy ToolAcre. Um bloqueador, uma conexão offline ou um proxy corporativo também podem interromper qualquer recurso remoto. O acesso WebP somente link reflete com precisão o que o servidor remoto permite que a página faça: apontar para o arquivo, mas não ler seus bytes para reempacotar.
Nomeando o arquivo salvo – por que um downloader deve nomeá-lo por ID e tamanho do vídeo para que os arquivos permaneçam identificáveis
Os nomes JPEG baixados usam youtube-VIDEO_ID-VARIANT.jpg. Tanto o identificador quanto a variante vêm de alfabetos validados, evitando que separadores de caminho ou caracteres de controle arbitrários entrem no nome de arquivo sugerido. Salvar `maxresdefault` e `hq2` de uma pesquisa deve, portanto, produzir nomes distintos e previsíveis que podem ser correspondidos às suas linhas de resultados.
Um nome de arquivo descritivo preserva a procedência quando vários tamanhos ficam em uma pasta. Também evita fingir que o título dos metadados é um nome de sistema de arquivos seguro, uma vez que os títulos podem conter pontuação e podem mudar de forma independente. O ID imutável identifica a referência do vídeo, enquanto o sufixo variante explica qual candidato à imagem publicada forneceu os bytes.
Exemplo resolvido: salvar dois tamanhos de miniatura para um vídeo — a sequência de solicitações e os arquivos resultantes
Obtenha um vídeo público e escolha duas variantes JPEG disponíveis. Cada um foi solicitado uma vez durante a sondagem, decodificado para provar as dimensões e retido como um Blob; clicar em salvar deve reutilizar esse resultado e produzir dois arquivos com nomes claros. Com o DevTools aberto, a ausência de uma segunda solicitação de imagem confirma que o salvamento veio da resposta retida, e não de um novo download remoto.
Se um candidato retornar HTTP 200 como um espaço reservado 120×90, a ferramenta o marcará como ausente e não armazenará nenhum Blob para download. Um 404, outro erro ou resposta não decodificável também é relatado em vez de salvo. Desabilitar a ação de salvar para essas linhas evita que um espaço reservado genérico ou carga útil de erro entre em uma pasta de ativos com um nome de variante convincente.
O que isso não cobre: downloads em lote de muitos vídeos e hosts que bloqueiam leituras de origem cruzada
Não há modo em lote em muitos vídeos e nenhum desvio para hosts que proíbem a leitura de origem cruzada. O produto processa um vídeo por vez e se restringe aos dois serviços divulgados do Google. Cada Blob retido pertence ao conjunto de resultados atual, portanto não deve ser tratado como um cache durável para vídeos posteriores ou versões futuras da mesma miniatura.
Ele também não recupera vídeo ou áudio, e registros privados, excluídos ou com restrição de idade permanecem indisponíveis. Um mecanismo público de salvamento de arquivos não pode expandir os direitos de acesso ou fabricar uma miniatura ausente. A criação do blob começa somente após a chegada de bytes de imagem legíveis, portanto, não oferece nenhuma rota em torno de uma resposta negada ou de uma variante não publicada.
JPEG busca, reutilização de Blob e download - com WebP mantido como um link
Antes de Fetch, a análise de URL é local. Posteriormente, cada investigação JPEG e a solicitação canônica do oEmbed vão direto do navegador com credenciais omitidas, sem referenciador, sem armazenamento e redirecionamentos seguidos; O Google vê o cabeçalho Origin. Data downloads importantes de forma independente, porque nem o objeto URL nem o caminho de origem previsível preservam uma revisão de miniatura anterior.
O resultado é deliberadamente assimétrico: bytes JPEG verificados podem se tornar downloads de Blob, enquanto cinco URLs postadores WebP permanecem links externos porque suas respostas não têm permissão CORS. A interface deve preservar esse limite honesto. Os usuários podem abrir ou copiar um endereço WebP, mas ToolAcre não pode prometer um arquivo WebP local renomeado a partir de bytes que o navegador proíbe de ler.