비디오 및 자막 · YouTube 썸네일 다운로더 및 메타데이터 뷰어
브라우저가 원본 간 이미지를 저장하는 방법: 가져오기, Blob URL 및 다운로드
· 작동 방식
유튜브 자바스크립트 코르
다른 도메인의 이미지를 저장하는 것은 다운로드 속성이 있는 링크보다 어렵습니다. 이 게시물에서는 교차 출처 URL에 대해 속성이 무시되는 이유, 가져오기 및 Blob URL이 이를 해결하는 방법, CORS가 이와 관련된 작업에 대해 설명합니다.
다운로드 속성은 이미지를 저장하는 대신 이미지를 열었습니다 — 교차 출처 캐치
다른 원점을 가리키는 앵커는 원하는 파일 이름을 따르는 대신 이미지로 이동할 수 있습니다. 신뢰할 수 있는 다운로더에는 단순히 원격 URL의 다운로드 속성뿐만 아니라 브라우저 교차 출처 규칙에 따라 읽을 수 있는 바이트가 필요합니다. 눈에 보이는 테스트는 간단합니다. 확인된 JPEG을 저장하면 다른 i.ytimg.com 요청을 추가하지 않고도 ToolAcre 파일 이름이 생성됩니다.
ToolAcre는 이미 각 JPEG 후보를 가져와서 그것이 실제인지 확인합니다. 성공적인 Blob을 유지한다는 것은 나중에 다운로드할 때 두 번째 네트워크 요청을 발행하는 대신 동일한 바이트를 사용할 수 있음을 의미합니다. 이러한 재사용을 통해 저장된 파일은 크기 및 자리 표시자 상태가 조금 전에 검사된 이미지와 동일하게 유지됩니다.
브라우저가 다른 출처의 다운로드를 무시하는 이유 — 보안 결정 및 그 결과
브라우저는 페이지가 자동으로 이름을 바꾸고 임의의 원격 리소스를 저장해서는 안 되기 때문에 교차 출처 다운로드를 제한합니다. 동작은 원격 응답 및 원본 관계에 따라 달라지므로 단순 링크는 범용 파일 저장 API가 아닙니다. `download` 속성만으로는 원격 YouTube 이미지가 요청된 로컬 이름으로 저장된다고 보장할 수 없습니다.
더 안전한 설계는 명시적입니다. 공개된 공개 이미지를 요청하고, 응답을 확인하고, 페이지에서 읽을 수 있는 데이터에 대해서만 브라우저 관리 개체 URL을 구성합니다. CORS가 액세스를 차단하는 경우 JavaScript에는 유효성을 검사하거나 저장할 Blob이 없습니다. 이미지 주소로 직접 이동하면 여전히 탭에 표시될 수 있습니다.
가져오기 및 Blob 경로 — 이미지 바이트를 가져와 이를 Blob에 래핑하고 동일한 출처 blob 생성: URL
JPEG의 경우,probeThumbnail은 익명 CORS GET을 수행하고 성공적인 응답을 Blob으로 변환하고 차원을 디코딩합니다. 사용 가능한 Blob은 결과에 유지되는 반면 자리 표시자는 다운로드로 가장할 수 없도록 삭제됩니다. 따라서 다운로드 버튼은 파일 이름이나 HTTP 200 단독으로 추론된 신뢰도가 아니라 메모리에서 확인된 바이트를 나타냅니다.
그러면 개체 URL은 로컬 저장 작업에 대한 해당 메모리 내 Blob을 나타낼 수 있습니다. 이는 원본 가져오기를 로컬로 만들지 않습니다. Google은 Fetch 후에 브라우저에 직접 바이트를 제공했습니다. `blob:` 주소는 해당 응답 본문에 대한 임시 브라우저 핸들이며, ToolAcre에서 호스팅하는 미러나 소스 이미지에 대해 새로 부여된 권한이 아닙니다.
CORS는 JPEG 가져오기 및 Blob 다운로드를 허용합니다. WebP은 링크 전용으로 유지됩니다.
CORS를 암시하는 개요는 하나의 일반적인 게이트였지만 배송된 동작은 형식에 따라 다릅니다. JPEG 가져오기 및 Blob 다운로드가 작동합니다. /vi_webp/ 경로는 필수 교차 원본 헤더 없이 제공되므로 ToolAcre는 WebP를 링크로만 제공합니다. 검토자는 JPEG 응답 헤더를 모든 축소판 형식으로 일반화하는 대신 두 경로 계열을 별도로 테스트해야 합니다.
ToolAcre 프록시가 없기 때문에 JavaScript를 변경하거나 ToolAcre를 통해 다시 시도해도 해당 제한이 복구되지 않습니다. 차단기, 오프라인 연결 또는 회사 프록시도 원격 리소스를 중지할 수 있습니다. 링크 전용 WebP 액세스는 원격 서버가 페이지에 허용하는 작업, 즉 파일을 가리키지만 재패키징을 위해 해당 바이트를 읽지 않는 작업을 정확하게 반영합니다.
저장된 파일 이름 지정 — 파일을 식별할 수 있도록 다운로더가 비디오 ID와 크기로 이름을 지정해야 하는 이유
다운로드된 JPEG 이름은 youtube-VIDEO_ID-VARIANT.jpg를 사용합니다. 식별자와 변형은 모두 검증된 알파벳에서 나오므로 경로 구분 기호나 임의의 제어 문자가 제안된 파일 이름을 입력하는 것을 방지합니다. 따라서 한 번의 조회에서 `maxresdefault` 및 `hq2`를 저장하면 결과 행과 다시 일치시킬 수 있는 고유하고 예측 가능한 이름이 생성됩니다.
설명이 포함된 파일 이름은 여러 크기가 하나의 폴더에 있을 때 출처를 유지합니다. 또한 제목에 구두점이 포함될 수 있고 독립적으로 변경될 수 있으므로 메타데이터 제목이 안전한 파일 시스템 이름인 척하는 것을 방지합니다. 변경할 수 없는 ID는 비디오 참조를 식별하는 반면 변형 접미사는 게시된 이미지 후보가 바이트를 제공했는지 설명합니다.
작업 예: 하나의 비디오에 대해 두 가지 축소판 크기 저장 — 요청 순서 및 결과 파일
공개 동영상 1개를 가져오고 사용 가능한 JPEG 변형 2개를 선택합니다. 각각은 프로빙 중에 한 번 요청되었으며 크기를 증명하기 위해 디코딩되었으며 Blob으로 유지되었습니다. 저장을 클릭하면 해당 결과를 재사용하고 이름이 명확하게 지정된 두 개의 파일이 생성됩니다. DevTools가 열린 상태에서 두 번째 이미지 요청이 없으면 저장이 새로운 원격 다운로드가 아닌 보관된 응답에서 이루어졌음을 확인합니다.
한 후보가 HTTP 200를 120×90 자리 표시자로 반환하는 경우 도구는 해당 항목이 누락된 것으로 표시하고 다운로드 가능한 Blob을 저장하지 않습니다. 404, 기타 오류 또는 디코딩할 수 없는 응답도 마찬가지로 저장되지 않고 보고됩니다. 이러한 행에 대한 저장 작업을 비활성화하면 일반 자리 표시자 또는 오류 페이로드가 설득력 있는 변형 이름으로 자산 폴더에 입력되는 것을 방지할 수 있습니다.
여기서 다루지 않는 내용 — 여러 비디오에 대한 일괄 다운로드 및 원본 간 읽기를 차단하는 호스트
많은 비디오에는 일괄 모드가 없으며 원본 간 읽기를 금지하는 호스트에 대한 우회가 없습니다. 제품은 한 번에 하나의 비디오를 처리하며 공개된 두 개의 Google 서비스로 제한됩니다. 유지된 각 Blob은 현재 결과 세트에 속하므로 이후 비디오나 동일한 축소판의 향후 버전에 대한 내구성 있는 캐시로 처리되어서는 안 됩니다.
또한 비디오 또는 오디오를 검색하지 않으며 비공개, 삭제 또는 연령 제한 기록은 사용할 수 없습니다. 공개 파일 저장 메커니즘은 액세스 권한을 확장하거나 존재하지 않는 썸네일을 제작할 수 없습니다. Blob 생성은 읽을 수 있는 이미지 바이트가 도착한 후에만 시작되므로 거부된 응답이나 게시되지 않은 변형에 대한 경로를 제공하지 않습니다.
JPEG 가져오기, Blob 재사용 및 다운로드 - WebP이 링크로 유지됨
가져오기 전에는 URL 구문 분석이 로컬입니다. 그 후 각 JPEG 프로브와 표준 oEmbed 요청은 자격 증명이 생략되고 리퍼러도 없고 저장도 없고 리디렉션을 따라가는 브라우저에서 바로 이동합니다. Google은 Origin 헤더를 확인합니다. 개체 URL이나 예측 가능한 소스 경로가 이전 썸네일 개정을 유지하지 않기 때문에 중요한 날짜는 독립적으로 다운로드됩니다.
결과는 의도적으로 비대칭입니다. 확인된 JPEG 바이트는 Blob 다운로드가 될 수 있지만 5개의 WebP 포스터 URL은 응답에 CORS 권한이 없기 때문에 외부 링크로 남아 있습니다. 인터페이스는 정직한 경계를 유지해야 합니다. 사용자는 WebP 주소를 열거나 복사할 수 있지만 ToolAcre는 브라우저가 읽지 못하도록 금지한 바이트에서 이름이 변경된 로컬 WebP 파일을 약속할 수 없습니다.