a 태그 이미지 다운로드

이 글은 2020년 7월 25일에 작성한 글 입니다.

이후에 동작에 문제가 발생하면 코멘트 부탁 드립니다.

최근 하는 일에서 a 태그의 download 속성이 서버로 올라가면 안먹힌다는걸 알았습니다.

정확하게는 서버에 올라가서 라는 이유가 아니라 CDN 서버에서 이미지를 가져와서 쓰는데, 마크업 작업할땐 그런걸 대부분 염두해 두지 않고 작업을 해왔었습니다.

제가 겪고있는 이런 환경에선 QA 테스트, 라이브 등에 작업물을 올릴 때 문제가 발생하죠.

이해를 돕기 위해 첨부파일을 하나 업로드 하겠습니다.

첨부 파일을 다운로드 받으신 후 테스트 환경은 로컬 서버를 돌려서 확인하셔야 합니다.

1_imgDown.zip

상대 경로와 절대 경로 를 눌러보시면 그 차이가 명확해 집니다.

상대 경로에 있는 이미지는 컴퓨터에 저장이 되는 한편 절대 경로에 있는 이미지는 현재 있는 페이지에서 벗어남과 동시에 이미지가 보이게 됩니다.

가장 눈에 띄는 차이는 경로의 차이였습니다.

<!-- 상대경로 -->
<a href="img/sample.jpg" download>이미지 다운로드</a>
 
<!-- 절대경로 -->
<a href="http://abcd.efg/img/sample.jpg" download>이미지 다운로드</a>

일반적인 형태의 마크업 페이지 라면 상대경로에 HTML5 속성인 download 속성만 걸어줘도 다운로드가 됩니다.

하지만 이렇게 이미지 서버가 별도로 존재한다면 위에 첨부해 드린 첨부파일에 있는 절대경로 이미지 다운로드와 같이 동작하게 됩니다.

보통 이런 부문은 웹개발자 분들을 통해서 개발을 요청 드렸어야 했는데 이번엔

저의 얕은 경험으로 인해 촉박한 일정에 웹개발자 분께 부담을 드리는 상황이 온거 같아서 마크업 단에서 해결을 보고 싶었습니다.

아래로 작성하는 내용은 라이브 되기 전 로컬의 상황에서 테스트 했습니다.

2020년 7월 27일 이후로 이미지 다운로드가 과연 제대로 되는지 이 게시물을 통해 작성하겠습니다.

우선 제가 a 태그의 download 속성을 정확히 이해하고 사용하고 있는지 알아보기 위해 w3c 사이트를 통해 알아봤습니다.

w3c_a태그_download_속성_바로가기

- 이 속성은 href 속성이 설정된 경우에만 사용된다.

- 속성의 값은 다운로드한 파일의 이름이 될 것이다. 허용되는 값에는 제한이 없으며 브라우저가 올바른 파일 확장자를 자동으로 감지하여 파일(.img, .pdf, .txt, .html 등)에 추가한다.

- 값을 생략하면 원래 파일 이름이 사용된다.

일단 상대경로, 절대경로에 대한 내용이 없었습니다.

그래서 다른 구글링 하던 도중 자바스크립트로 파일 다운로드를 구현하는 블로그를 발견했어요.

자바스크립트_AJAX로_.....바로가기

해당 스크립트를 사용해서 테스트 해봤는데 일반적인 데스크탑 PC 에서 이미지 다운로드가 잘 되었습니다.

또한 맥에서도 잘 됩니다.

근데 요게 모바일로 보게 된다면 뭔가 동작이 안되었습니다 ㅠ

아직 서버에 올리기 전이라서 확신이 안되는데 제가 테스트 해본 환경은 node live server 정도 입니다. 그냥 로컬 서버 돌린거죠.

아이폰 - 크롬브라우저

아이폰 - 사파리 브라우저

그래서 구글링을 하다가 이런 글을 발견했습니다.

https://okky.kr/article/431216

(이 링크는 클릭하시면 글이 안나오고 복사해서 주소창에 붙혀 넣어야지 나오네요)

http://danml.com/download.html

이런 플러그인이 있는데 이 여기에 나온 플러그인을 사용하면 일단 아이폰 에서는 원하는 문제가 해결이 됩니다.

하지만...

갤럭시 의 삼성 브라우저...

제가 이걸 간과하고 있었습니다.

삼성 브라우저는 우선 설정상 자동 다운로드가 막혀 있기 떄문에 풀어줘야 다운로드가 됩니다.

1.

2.

3.

4.

5.

갤럭시 S8 삼성 브라우저 기준으로 자동 다운로드 해제를 하는 방법 입니다.

유저 입장에서 위에 처럼 5단계를 걸쳐 자동 다운로드를 풀어 준다면 다운로드가 가능 할꺼예요.

근데 사실 유저입장에서 뭔가 다운로드가 안된다면

에? 이거 다운로드 안되는데요? 다운로드 되게 해주세요.

라고 이야기가 나올 수 있습니다.

이 삼성 브라우저의 정책이 그런거였다면 개발하는 사람 입장에서 어찌 할 방도가 없죠.

그래서 그냥 새탭으로 라도 이미지 정도는 표시해 주려고 합니다.

이게 그냥 최선인거 같습니다..

아래의 이 코드를 쓰면 어떤 환경에서 어떤 브라우저를 사용하는지 테스트를 할 수 있습니다.

//디바이스 종류(Mobile, PC, Tablet)
function deviceKind() {
  //모바일 Device종류(윈도우 폰은 앞으로 나오지 않기 때문에 빼도 무방하나 아직 쓰는 사람이 존재하기에..)
  var mobileFlag = /Mobile|iP(hone|od)|Windows (CE|Phone)|Minimo|Opera M(obi|ini)|BlackBerry|Nokia/;
 
  //모바일일경우
  if (navigator.userAgent.match(mobileFlag) && !navigator.userAgent.match(/iPad/)) {
    return "Mobile";
  }
 
  //모바일 Device와 Android가 포함이 안되어 있을 경우
  else if (navigator.userAgent.match(/iPad|Android/)) {
    return "Tablet";
  }
 
  //그 외의 경우 모두 테블릿
  else {
    return "PC(Mobile, Tablet 외)";
  }
}
 
//브라우저 종류
function BrowserKind() {
  var browser = navigator.userAgent.toLowerCase();
 
if (browser.indexOf("samsungbrowser") != -1) {
  return "Samsung Browser";
}
 
  else if (browser.indexOf("chrome") != -1) {
    return "Chrome";
  }
 
  else if (browser.indexOf("opera") != -1) {
    return "Opera";
  }
 
  else if (browser.indexOf("firefox") != -1) {
    return "Firefox";
  }
 
  else if (browser.indexOf("safari") != -1) {
    return "Safari";
  }
 
  else {
    return "Internet Explorer 등";
  }
}
 
alert(navigator.userAgent + "\r\n접속 Device : " + deviceKind() + "\r\n브라우저명 : " + BrowserKind());

그래서 제가 테스트 해본 코드를 첨부 파일로 첨부하겠습니다.

환경은 로컬 서버에서 테스트 했으며 테스트일자는 2020년 07월 25일 입니다.

테스트 디바이스는 아이폰X, 갤럭시S8, 맥북, win10

테스트 브라우저는

아이폰 - 사파리, 크롬

갤럭시S8 - 삼성브라우저, 크롬

맥북 - 사파리, 크롬

win10 - IE11, 크롬

2_imgDown.zip

------

2020년 7월 27 일 입니다..

음 역시나 문제가 발생 하네요.. 결국엔 다운로드 기능을 뺐습니다만... 원인이 뭔지 알았습니다.

크로스도메인 이슈 CORS  라고 불리는 것 때문이였네요.

집에서 테스트 할때와는 또다른 문제입니다.

에러코드인 내용은 다음과 같습니다.

XMLHttpRequest cannot load http://mydomain:8000/register. 
No 'Access-Control-Allow-Origin' header is present on the requested resource. 
Origin 'null' is therefore not allowed access. 

몇개 설명이 아주 쉽고 친절한 블로그가 있어서 읽어봤습니다.

https://ddulgi.tistory.com/9

https://infotake.tistory.com/88

https://blog.naver.com/magnking/220936346495

세 블로그 모두 기본적으로 헤더에 특정 host의 접근 요청을 풀어주는 방식이 있습니다.

프론트앤드개발자, 또는 마크업 직군은 기본적으로 서버관련 직군의 협조가 필요한 상황이 발생됩니다.

그만큼 작업에 있어서 일정산정을 해 놔야 하죠.

저는 일단 이런 이슈를 처음 겪어봐서 헤더 요청이 승인이 되더라도 제가 짠 코드가 동작이 될지 확신이 안섰던 상황도 있습니다.

저 블로그 내용 중

http://www.ajax-cross-origin.com/

이런 플러그인도 있었는데 이 또한 문제가 없을지 확신이 안섰던 것도 있구요.

웹브라우저가 보안 이유로 동일출처정책 두어 다른 도메인의 서버에 요청하는 것을 보안문제로 간주하고 이를 차단한다는 것도 알았고...

정신 없는 하루였는데 또 배운게 있네요.