JavaScript를 사용하여 서버에 .png 파일을 다운로드하고 다른 파일 확장자를 가진 새 파일(.pdf)을 만듭니다.

Question

내 웹사이트의 코드가 매우 복잡하고 형편없는 백엔드에 저장되어 있습니다. 안타깝게도 콘텐츠 헤더를 매우 엄격하게 잠그므로 .pdf로 끝나는 모든 파일 링크는 UI 다운로드 프롬프트를 통해서만 액세스할 수 있으며 브라우저 보기PDF 파일. 현재 내 생각은 파일을 서버에 업로드하고 이름을 file.pdf.png로 바꿀 수 있을 것 같습니다. (이는 서버 콘텐츠 헤더 조건을 충족하여 .png 파일 형식처럼 보이도록 허용하는 것 같습니다. 브라우저는 파일을 다운로드합니다. 메모리). 그런 다음 파일을 다운로드 가능하게 하여(메모리 내) JavaScript로 새 파일을 생성하고 싶습니다. 다른 곳에서 제안된 한 가지 접근 방식은 손상된 .png 파일의 콘텐츠를 base64로 인코딩한 다음, 디코딩된 base64 콘텐츠를 기반으로 JavaScript로 새 파일을 생성하고 해당 파일에 .pdf PDF 파일로 작동하고 메모리에 저장되므로 사용자가 장치에 아무것도 다운로드할 필요가 없습니다. 최종 목표는 사용자의 백엔드에서 메모리에 있는 파일을 검색하고 브라우저에 내장된 PDF 뷰어를 사용하여 표시하는 것입니다.

//서버에는 파일을 업로드할 수 있는 옵션이 있습니다. //업로드한 파일이 실제로 PDF 파일이지만 끝에 .png 확장자가 추가되었다고 가정하면, //따라서 이러한 파일에 대한 링크는 https://the-website.com/file.pdf.png

//이제 사용자가 UI 다운로드 팝업과 상호작용할 필요가 없도록 백그라운드에서 이 파일을 검색하고 메모리에 저장할 수 있어야 합니다.

//그런 다음 어떤 방법으로든 파일 콘텐츠(file.pdf.png)를 추출하고 의사 파일 확장자를 가진 파일을 기반으로 유효한 PDF 파일을 만들어야 합니다. 결과 파일은 file.pdf여야 합니다. . 이 파일은 또는

Answer 1

파일 확장자는 사실 이것과 크게 관련이 없습니다... Content-Type헤더는 그렇습니다.

귀하의 설명에 따르면 PDF 파일을 가져올 때 서버가 응답에 올바른 유형을 사용하지 않고 대신 application/octet-stream 또는 다른 유형으로 보내는 것 같습니다. (이것은 일반적인 유형이며 브라우저는 기본적으로 다운로드합니다.)

이 문제를 해결하는 방법에는 여러 가지가 있습니다. 한 가지 방법은 ServiceWorker를 사용하여 필요에 따라 Content-Type 헤더를 재정의하는 것입니다. 그러나 이것이 항상 작동하는 것은 아닙니다. 브라우저는 페이지를 강제로 다시 로드하거나 개인정보 보호 모드가 활성화된 경우 서비스 워커를 비활성화하는 경우가 많습니다.

당신이 제안한 것에 더 가까운 또 다른 접근 방식은 JavaScript로 PDF를 메모리에 저장하는 것입니다. Fetch API를 사용하여 이 작업을 수행한 다음 Blob URL을 만들고 브라우저에서 다운로드하도록 할 수 있습니다. 아직 테스트되지 않았지만 대략적으로 다음과 같습니다.

으아악

특히 큰 문서에는 작동하지 않을 수 있습니다. 작은 문서도 문제 없습니다.

또한 모든 브라우저가 PDF를 표시할 수 있는 것은 아니며 모든 시스템이 브라우저가 자체적으로 PDF를 표시할 수 있도록 구성되어 있지도 않습니다.