Video e sottotitoli · Downloader di miniature di YouTube e visualizzatore di metadati
Come un browser salva un'immagine multiorigine: recupero, URL BLOB e download
· Come funziona
youtube javascript cor
Salvare un'immagine da un altro dominio è più difficile di un collegamento con un attributo di download. Questo post spiega perché l'attributo viene ignorato per gli URL di origine incrociata, come lo risolvono gli URL di recupero e BLOB e cosa c'entra CORS.
L'attributo download ha aperto l'immagine invece di salvarla: il problema multiorigine
Un'ancora puntata su un'origine diversa potrebbe navigare verso un'immagine invece di rispettare il nome file desiderato. Un downloader affidabile necessita di byte leggibili secondo le regole multiorigine del browser, non semplicemente di un attributo di download su un URL remoto. Il test visibile è semplice: il salvataggio di un JPEG verificato dovrebbe creare il nome file ToolAcre senza aggiungere un'altra richiesta i.ytimg.com.
ToolAcre recupera già ciascun candidato JPEG per determinare se è reale. Mantenere il BLOB riuscito significa che il download successivo può usare gli stessi byte invece di inviare una seconda richiesta di rete. Questo riutilizzo mantiene il file salvato identico all'immagine le cui dimensioni e stato del segnaposto sono stati controllati pochi istanti prima.
Perché i browser ignorano i download per altre origini: una decisione sulla sicurezza e le sue conseguenze
I browser limitano i download multiorigine perché una pagina non dovrebbe rinominare e salvare silenziosamente risorse remote arbitrarie. Il comportamento dipende dalla risposta remota e dalla relazione di origine, quindi un collegamento semplice non è un salvataggio di file universale API. L'attributo `download` da solo non può garantire che un'immagine YouTube remota venga salvata con il nome locale richiesto.
La progettazione più sicura è esplicita: richiedere un'immagine pubblica divulgata, verificare la risposta e costruire un oggetto gestito dal browser URL solo per i dati che la pagina può leggere. Se CORS blocca l'accesso, JavaScript non ha alcun BLOB da convalidare o salvare, anche se la navigazione diretta verso l'indirizzo dell'immagine potrebbe comunque visualizzarla in una scheda.
Il percorso fetch-and-Blob: recupero dei byte dell'immagine, avvolgimento in un BLOB e creazione di un BLOB della stessa origine: URL
Per JPEG, sondaThumbnail esegue un CORS GET anonimo, converte una risposta corretta in un BLOB e decodifica le dimensioni. Nel risultato viene mantenuto un BLOB utilizzabile, mentre i segnaposto vengono eliminati in modo che non possano essere mascherati da download. Il pulsante di download rappresenta quindi byte verificati in memoria, non la sicurezza dedotta da un nome file o HTTP 200 solo.
Un oggetto URL può quindi rappresentare il BLOB in memoria per un'azione di salvataggio locale. Ciò non rende locale il recupero originale; Google ha fornito i byte direttamente al browser dopo il recupero. L'indirizzo `blob:` è un handle temporaneo del browser per il corpo della risposta, non un mirror ospitato da ToolAcre o un diritto appena concesso sull'immagine di origine.
CORS consente download di JPEG fetch-and-Blob; WebP rimane solo collegamento
La struttura implicava che CORS fosse un gate generico, ma il comportamento fornito è specifico del formato. Il download di JPEG fetch-and-Blob funziona; il percorso /vi_webp/ viene fornito senza l'intestazione multiorigine richiesta, quindi ToolAcre fornisce WebP solo come collegamento. Un revisore dovrebbe testare le due famiglie di percorsi separatamente invece di generalizzare le intestazioni di risposta JPEG a ogni formato di miniatura.
Questa limitazione non viene risolta modificando JavaScript o riprovando tramite ToolAcre, perché non esiste alcun proxy ToolAcre. Un blocco, una connessione offline o un proxy aziendale possono anche arrestare entrambe le risorse remote. L'accesso WebP solo collegamento riflette accuratamente ciò che il server remoto consente alla pagina di fare: puntare al file, ma non leggere i suoi byte per il riconfezionamento.
Assegnare un nome al file salvato: perché un downloader dovrebbe nominarlo in base all'ID video e alle dimensioni in modo che i file rimangano identificabili
I nomi JPEG scaricati utilizzano youtube-VIDEO_ID-VARIANT.jpg. Sia l'identificatore che la variante provengono da alfabeti convalidati, impedendo ai separatori di percorso o ai caratteri di controllo arbitrari di inserire il nome file suggerito. Il salvataggio di `maxresdefault` e `hq2` da una ricerca dovrebbe quindi produrre nomi distinti e prevedibili che possono essere associati alle righe dei risultati.
Un nome file descrittivo preserva la provenienza quando diverse dimensioni si trovano in una cartella. Evita inoltre di fingere che il titolo dei metadati sia un nome di filesystem sicuro, poiché i titoli possono contenere segni di punteggiatura e possono cambiare in modo indipendente. L'ID immutabile identifica il riferimento al video, mentre il suffisso variante spiega quale candidato immagine pubblicata ha fornito i byte.
Esempio pratico: salvataggio di due dimensioni di miniatura per un video: la sequenza delle richieste e i file che ne risultano
Recupera un video pubblico e scegli due varianti JPEG disponibili. Ciascuno è stato richiesto una volta durante il sondaggio, decodificato per dimostrare le dimensioni e conservato come Blob; facendo clic su Salva si dovrebbe riutilizzare il risultato e produrre due file dal nome chiaro. Con DevTools aperto, l'assenza di una seconda richiesta di immagine conferma che il salvataggio proviene dalla risposta conservata anziché da un nuovo download remoto.
Se un candidato restituisce HTTP 200 come segnaposto 120×90, lo strumento lo contrassegna come mancante e non memorizza alcun BLOB scaricabile. Allo stesso modo viene segnalato un 404, un altro errore o una risposta non decodificabile anziché salvata. La disabilitazione dell'azione di salvataggio per queste righe impedisce a un segnaposto generico o a un payload di errore di entrare in una cartella di risorse con un nome di variante convincente.
Ciò che questo non copre: download in batch di molti video e host che bloccano le letture multiorigine
Non esiste una modalità batch per molti video e nessun bypass per gli host che vietano la lettura multiorigine. Il prodotto gestisce un video alla volta e si limita ai due servizi Google indicati. Ogni BLOB conservato appartiene al set di risultati corrente, quindi non deve essere trattato come una cache durevole per i video successivi o le versioni future della stessa miniatura.
Inoltre, non recupera video o audio e i record privati, cancellati o soggetti a limiti di età rimangono non disponibili. Un meccanismo pubblico di salvataggio dei file non può espandere i diritti di accesso o produrre una miniatura assente. La creazione del BLOB inizia solo dopo l'arrivo dei byte di immagine leggibili, quindi non offre alcun percorso per aggirare una risposta negata o una variante non pubblicata.
JPEG recupera, riutilizza e scarica i BLOB, mantenendo WebP come collegamento
Prima del recupero, l'analisi URL è locale. Successivamente, ogni sonda JPEG e la richiesta canonica oEmbed escono direttamente dal browser con credenziali omesse, nessun referrer, no-store e reindirizzamenti seguiti; Google vede l'intestazione Origin. Data i download importanti in modo indipendente, poiché né l'oggetto URL né il percorso di origine prevedibile conservano una revisione precedente della miniatura.
Il risultato è deliberatamente asimmetrico: i byte JPEG verificati possono diventare download BLOB, mentre cinque URL poster WebP rimangono collegamenti esterni perché le loro risposte non dispongono dell'autorizzazione CORS. L'interfaccia dovrebbe preservare quel confine onesto. Gli utenti possono aprire o copiare un indirizzo WebP, ma ToolAcre non può promettere un file WebP locale rinominato dai byte che il browser ne impedisce la lettura.