ビデオと字幕 · YouTube サムネイル ダウンローダーとメタデータ ビューアー
ブラウザーがクロスオリジン画像を保存する方法: フェッチ、Blob URL、ダウンロード
· 仕組み
YouTube JavaScript コル
別のドメインから画像を保存することは、ダウンロード属性を持つリンクよりも困難です。この投稿では、クロスオリジン URL で属性が無視される理由、フェッチ URL と BLOB URL がこの属性をどのように解決するか、CORS がそれとどのような関係があるのかについて説明します。
ダウンロード属性により、画像が保存されずに開かれました — クロスオリジン キャッチ
別の原点を指すアンカーは、目的のファイル名を尊重せずに画像に移動する場合があります。信頼できるダウンローダーには、リモート URL のダウンロード属性だけでなく、ブラウザーのクロスオリジン ルールに基づいて読み取り可能なバイトが必要です。表示されるテストは簡単です。検証済みの JPEG を保存すると、別の i.ytimg.com リクエストを追加せずに ToolAcre ファイル名が作成されます。
ToolAcre は、各 JPEG 候補をすでにフェッチして、それが本物かどうかを判断します。成功した BLOB を保持するということは、後のダウンロードで 2 番目のネットワーク要求を発行する代わりに、それらの同じバイトを使用できることを意味します。この再利用により、保存されたファイルは、直前に寸法とプレースホルダーのステータスが検査された画像と同一に保たれます。
ブラウザーが他のオリジンのダウンロードを無視する理由 — セキュリティ上の決定とその結果
ページは任意のリモート リソースを黙って名前変更して保存すべきではないため、ブラウザーはクロスオリジン ダウンロードを制限します。動作はリモート応答と発信元の関係に依存するため、単純なリンクは汎用的なファイル保存 API ではありません。 `download` 属性だけでは、リモート YouTube 画像が要求されたローカル名で保存されることを保証できません。
より安全な設計は明示的です。公開されたパブリック イメージを要求し、応答を確認し、ページで読み取りが許可されたデータのみに対してブラウザー管理のオブジェクト URL を構築します。 CORS がアクセスをブロックした場合、画像アドレスに直接移動するとタブに画像が表示される場合でも、JavaScript には検証または保存する BLOB がありません。
フェッチと Blob ルート — 画像バイトをフェッチし、それらを Blob でラップし、同じオリジン BLOB を作成します。 URL
JPEG の場合、probeThumbnail は匿名の CORS GET を実行し、成功した応答を Blob に変換し、ディメンションをデコードします。使用可能な BLOB は結果に保持されますが、プレースホルダーは破棄されるため、ダウンロードとして偽装することはできません。したがって、ダウンロード ボタンは、ファイル名または HTTP 200 のみから推測される信頼性ではなく、メモリ内の検証済みバイトを表します。
オブジェクト URL は、ローカル保存アクションのメモリ内 BLOB を表すことができます。これは、元のフェッチをローカルにするわけではありません。 Google は、フェッチ後にバイトをブラウザに直接提供しました。 `blob:` アドレスは、その応答本文の一時的なブラウザ ハンドルであり、ToolAcre によってホストされるミラーや、ソース イメージに対して新たに付与された権利ではありません。
CORS では、JPEG のフェッチアンド BLOB ダウンロードが可能です。 WebP はリンクのみのままです
概要では、CORS が 1 つの汎用ゲートであることを暗示していましたが、出荷時の動作は形式固有です。 JPEG フェッチアンドブロブのダウンロードは機能します。 /vi_webp/ パスは必要なクロスオリジン ヘッダーなしで提供されるため、ToolAcre は WebP をリンクとしてのみ提供します。レビュー担当者は、JPEG 応答ヘッダーをすべてのサムネイル形式に一般化するのではなく、2 つのパス ファミリを個別にテストする必要があります。
ToolAcre プロキシが存在しないため、JavaScript を変更したり、ToolAcre を再試行したりしても、この制限は修復されません。ブロッカー、オフライン接続、または企業プロキシによって、いずれかのリモート リソースが停止される場合もあります。リンクのみの WebP アクセスは、リモート サーバーがページに許可していることを正確に反映します。つまり、ファイルをポイントしますが、再パッケージ化のためのバイトの読み取りは行いません。
保存されたファイルの名前付け — ファイルを識別できるように、ダウンローダーがビデオ ID とサイズで名前を付ける必要がある理由
ダウンロードされた JPEG 名には youtube-VIDEO_ID-VARIANT.jpg が使用されます。識別子とバリアントは両方とも検証されたアルファベットに由来しており、パス区切り文字や任意の制御文字が推奨されるファイル名に入力されるのを防ぎます。したがって、1 つの検索から `maxresdefault` と `hq2` を保存すると、結果の行と照合できる、個別の予測可能な名前が生成されるはずです。
複数のサイズが 1 つのフォルダー内に存在する場合、わかりやすいファイル名を使用すると、出所が保存されます。また、タイトルには句読点が含まれたり、独立して変更される可能性があるため、メタデータのタイトルが安全なファイルシステム名であるかのように装うことも避けられます。不変 ID はビデオ参照を識別し、バリアント接尾辞はどの公開された画像候補がバイトを供給したかを説明します。
実用的な例: 1 つのビデオに対して 2 つのサムネイル サイズを保存 - 一連のリクエストと結果のファイル
公開ビデオを 1 つ取得し、利用可能な JPEG バリアントを 2 つ選択します。それぞれはプローブ中に 1 回リクエストされ、ディメンションを証明するためにデコードされ、Blob として保持されます。 「保存」をクリックすると、その結果が再利用され、明確に名前が付けられた 2 つのファイルが生成されます。 DevTools が開いている場合、2 番目のイメージ要求がないことにより、保存が新しいリモート ダウンロードではなく、保持された応答から行われたことが確認されます。
1 つの候補が HTTP 200 を 120×90 プレースホルダーとして返す場合、ツールはそれを欠落としてマークし、ダウンロード可能な BLOB を保存しません。 404、その他のエラー、またはデコードできない応答も同様に、保存されずに報告されます。これらの行の保存アクションを無効にすると、汎用のプレースホルダーやエラー ペイロードが説得力のあるバリアント名でアセット フォルダーに入ることがなくなります。
これでカバーされないもの — 多数のビデオにわたるバッチ ダウンロード、およびクロスオリジン読み取りをブロックするホスト
多くのビデオにまたがるバッチ モードはなく、クロスオリジン読み取りを禁止するホストのバイパスもありません。この製品は一度に 1 つのビデオを処理し、公開されている 2 つの Google サービスに制限されます。保持された各 BLOB は現在の結果セットに属しているため、後のビデオや同じサムネイルの将来のバージョンのための永続的なキャッシュとして扱うべきではありません。
また、ビデオやオーディオは取得されず、プライベート、削除された、または年齢制限のあるレコードは利用できないままになります。パブリック ファイル保存メカニズムでは、アクセス権を拡張したり、存在しないサムネイルを作成したりすることはできません。 BLOB の作成は、読み取り可能な画像バイトが到着した後にのみ開始されるため、拒否された応答や未公開のバリアントを回避するルートは提供されません。
JPEG のフェッチ、BLOB の再利用、およびダウンロード (WebP はリンクとして保持されます)
フェッチ前の URL 解析はローカルです。その後、各 JPEG プローブと正規の oEmbed リクエストは、認証情報が省略され、リファラー、ストアなしでブラウザから直接送信され、リダイレクトが続きます。 Google は Origin ヘッダーを認識します。オブジェクト URL も予測可能なソース パスも以前のサムネイル リビジョンを保持しないため、重要なダウンロードの日付は独立して保存されます。
結果は意図的に非対称になっています。検証済みの JPEG バイトは BLOB ダウンロードになる可能性がありますが、5 つの WebP ポスター URL は応答に CORS 権限がないため外部リンクのままです。インターフェイスはその正直な境界を維持する必要があります。ユーザーは WebP アドレスを開いたりコピーしたりできますが、ToolAcre はブラウザーが読み取りを禁止しているバイトから名前を変更したローカル WebP ファイルを約束することはできません。