Video und Untertitel · YouTube-Thumbnail-Downloader und Metadaten-Viewer
So speichert ein Browser ein ursprungsübergreifendes Bild: Abrufen, Blob-URLs und Herunterladen
· Wie es funktioniert
YouTube Javascript kors
Das Speichern eines Bildes von einer anderen Domain ist schwieriger als das Speichern eines Links mit Download-Attribut. In diesem Beitrag wird erläutert, warum das Attribut bei Cross-Origin-URLs ignoriert wird, wie Fetch- und Blob-URLs das Problem lösen und was CORS damit zu tun hat.
Das Download-Attribut hat das Bild geöffnet, anstatt es zu speichern – der Cross-Origin-Faktor
Ein Anker, der auf einen anderen Ursprung zeigt, navigiert möglicherweise zu einem Bild, anstatt einen gewünschten Dateinamen zu berücksichtigen. Ein zuverlässiger Downloader benötigt lesbare Bytes gemäß browserübergreifenden Ursprungsregeln und nicht nur ein Download-Attribut auf einer Remote-URL. Der sichtbare Test ist unkompliziert: Durch das Speichern eines verifizierten JPEG sollte der ToolAcre-Dateiname erstellt werden, ohne dass eine weitere i.ytimg.com-Anfrage hinzugefügt werden muss.
ToolAcre ruft bereits jeden JPEG-Kandidaten ab, um festzustellen, ob er echt ist. Das Beibehalten des erfolgreichen Blobs bedeutet, dass der spätere Download dieselben Bytes verwenden kann, anstatt eine zweite Netzwerkanforderung auszugeben. Durch diese Wiederverwendung bleibt die gespeicherte Datei mit dem Bild identisch, dessen Abmessungen und Platzhalterstatus kurz zuvor überprüft wurden.
Warum Browser Downloads für andere Ursprünge ignorieren – eine Sicherheitsentscheidung und ihre Konsequenzen
Browser schränken ursprungsübergreifende Downloads ein, da eine Seite nicht stillschweigend umbenannt und beliebige Remote-Ressourcen gespeichert werden sollte. Das Verhalten hängt von der Remote-Antwort und der Ursprungsbeziehung ab, daher ist ein einfacher Link keine universelle API zum Speichern von Dateien. Das Attribut `download` allein kann nicht garantieren, dass ein entferntes YouTube-Bild unter dem angeforderten lokalen Namen gespeichert wird.
Das sicherere Design ist explizit: Fordern Sie ein offengelegtes öffentliches Bild an, überprüfen Sie die Antwort und erstellen Sie eine vom Browser verwaltete Objekt-URL nur für Daten, die die Seite lesen durfte. Wenn CORS den Zugriff blockiert, hat JavaScript keinen Blob zum Validieren oder Speichern, auch wenn das direkte Navigieren zur Bildadresse es möglicherweise immer noch in einem Tab anzeigt.
Die Fetch-and-Blob-Route – die Bildbytes werden abgerufen, in einen Blob verpackt und ein Blob mit demselben Ursprung erstellt: URL
Für JPEG führt probeThumbnail einen anonymen CORS GET durch, konvertiert eine erfolgreiche Antwort in einen Blob und dekodiert Dimensionen. Ein verwendbarer Blob bleibt im Ergebnis erhalten, während Platzhalter verworfen werden, sodass sie nicht als Downloads getarnt werden können. Die Download-Schaltfläche stellt daher verifizierte Bytes im Speicher dar und nicht das Vertrauen, das allein aus einem Dateinamen oder HTTP 200 abgeleitet wird.
Eine Objekt-URL kann dann diesen In-Memory-Blob für eine lokale Speicheraktion darstellen. Dadurch wird der ursprüngliche Abruf nicht lokal; Google lieferte die Bytes nach dem Abruf direkt an den Browser. Die Adresse `blob:` ist ein temporäres Browser-Handle für diesen Antworttext, kein von ToolAcre gehosteter Spiegel oder ein neu gewährtes Recht auf das Quellbild.
CORS ermöglicht JPEG Fetch-and-Blob-Downloads; WebP bleibt nur für Links verfügbar
Die Gliederung implizierte, dass CORS ein generisches Gate war, das gelieferte Verhalten jedoch formatspezifisch ist. JPEG Fetch-and-Blob-Download funktioniert; Der Pfad /vi_webp/ wird ohne den erforderlichen Cross-Origin-Header bereitgestellt, daher stellt ToolAcre WebP nur als Link bereit. Ein Prüfer sollte die beiden Pfadfamilien separat testen, anstatt die JPEG-Antwortheader auf jedes Miniaturbildformat zu verallgemeinern.
Diese Einschränkung kann nicht durch eine Änderung von JavaScript oder einen erneuten Versuch über ToolAcre behoben werden, da kein ToolAcre-Proxy vorhanden ist. Ein Blocker, eine Offline-Verbindung oder ein Unternehmens-Proxy können ebenfalls jede Remote-Ressource stoppen. Der Nur-Link-Zugriff WebP spiegelt genau wider, was der Remote-Server der Seite erlaubt: auf die Datei zeigen, aber ihre Bytes zum Neupacken nicht lesen.
Benennen der gespeicherten Datei – warum ein Downloader sie nach Video-ID und Größe benennen sollte, damit Dateien identifizierbar bleiben
Heruntergeladene JPEG-Namen verwenden youtube-VIDEO_ID-VARIANT.jpg. Sowohl der Bezeichner als auch die Variante stammen aus validierten Alphabeten, wodurch verhindert wird, dass Pfadtrennzeichen oder willkürliche Steuerzeichen in den vorgeschlagenen Dateinamen gelangen. Das Speichern von `maxresdefault` und `hq2` aus einer Suche sollte daher eindeutige, vorhersehbare Namen ergeben, die wieder mit ihren Ergebniszeilen abgeglichen werden können.
Ein beschreibender Dateiname bewahrt die Herkunft, wenn sich mehrere Größen in einem Ordner befinden. Außerdem wird vermieden, dass der Metadatentitel ein sicherer Dateisystemname ist, da Titel Satzzeichen enthalten und sich unabhängig voneinander ändern können. Die unveränderliche ID identifiziert die Videoreferenz, während das Variantensuffix erklärt, welcher veröffentlichte Bildkandidat die Bytes bereitgestellt hat.
Arbeitsbeispiel: Speichern von zwei Miniaturbildgrößen für ein Video – die Reihenfolge der Anfragen und die daraus resultierenden Dateien
Rufen Sie ein öffentliches Video ab und wählen Sie zwei verfügbare JPEG-Varianten aus. Jedes wurde während der Sondierung einmal angefordert, zum Beweis der Dimensionen dekodiert und als Blob aufbewahrt; Wenn Sie auf „Speichern“ klicken, sollte das Ergebnis wiederverwendet werden und zwei eindeutig benannte Dateien erstellt werden. Wenn DevTools geöffnet ist, bestätigt das Fehlen einer zweiten Bildanforderung, dass die Speicherung von der gespeicherten Antwort und nicht von einem neuen Remote-Download erfolgte.
Wenn ein Kandidat HTTP 200 als 120×90-Platzhalter zurückgibt, markiert das Tool ihn als fehlend und speichert keinen herunterladbaren Blob. Ein 404, ein anderer Fehler oder eine nicht dekodierbare Antwort wird ebenfalls gemeldet und nicht gespeichert. Durch Deaktivieren der Speicheraktion für diese Zeilen wird verhindert, dass ein generischer Platzhalter oder eine Fehlernutzlast unter einem überzeugenden Variantennamen in einen Asset-Ordner gelangt.
Was dies nicht abdeckt – Batch-Downloads über viele Videos hinweg und Hosts, die Cross-Origin-Lesevorgänge blockieren
Für viele Videos gibt es keinen Batch-Modus und keine Umgehung für Hosts, die das Cross-Origin-Lesen verbieten. Das Produkt verarbeitet jeweils ein Video und beschränkt sich auf die beiden angegebenen Google-Dienste. Jeder beibehaltene Blob gehört zum aktuellen Ergebnissatz und sollte daher nicht als dauerhafter Cache für spätere Videos oder zukünftige Versionen derselben Miniaturansicht behandelt werden.
Außerdem werden weder Video noch Audio abgerufen, und private, gelöschte oder altersbeschränkte Datensätze bleiben nicht verfügbar. Ein öffentlicher Dateispeichermechanismus kann keine Zugriffsrechte erweitern oder ein fehlendes Miniaturbild erstellen. Die Blob-Erstellung beginnt erst, nachdem lesbare Bildbytes eingegangen sind, sodass keine Möglichkeit besteht, eine abgelehnte Antwort oder eine unveröffentlichte Variante zu umgehen.
JPEG Abrufen, Blob-Wiederverwendung und Herunterladen – wobei WebP als Link beibehalten wird
Vor dem Abruf erfolgt die URL-Analyse lokal. Anschließend wird jede JPEG-Probe und die kanonische oEmbed-Anfrage direkt vom Browser gesendet, ohne Anmeldeinformationen, ohne Referrer, ohne Speicherung und mit verfolgten Weiterleitungen. Google sieht den Origin-Header. Datieren Sie wichtige Downloads unabhängig voneinander, da weder die Objekt-URL noch der vorhersehbare Quellpfad eine frühere Miniaturansicht-Revision bewahren.
Das Ergebnis ist bewusst asymmetrisch: Verifizierte JPEG Bytes können zu Blob-Downloads werden, während fünf WebP Poster-URLs externe Links bleiben, da ihre Antworten keine CORS-Berechtigung haben. Die Schnittstelle sollte diese ehrliche Grenze wahren. Benutzer können eine WebP-Adresse öffnen oder kopieren, aber ToolAcre kann keine umbenannte lokale WebP-Datei aus Bytes versprechen, deren Lesen der Browser verbietet.