C-D 헤더의 filename param 문제
Posted: 2004 02 07 20:05 14
많은 써버 프로그램에서 Content-Disposition (http 헤더)에 파일 이름을 표시할 때 표준 위반을 하고 있습니다. 두 가지 잘못을 저지르는 경우가 많습니다.
첫째 문제는 공백 문자가 들어감에도 불구하고, 따옴표로 묶지 않는 것입니다.
Content-Disposition: attachment; filename=this is a picture.png
위처럼 하면 안 되고, 아래처럼 해야 합니다.
Content-Disposition: attachment; filename="this is a picture.png"
두번째 문제는 ASCII 범위 밖의 글자를 내보낼 때입니다. 이 문제는 HTML 4.x 표준 저자들도 관련 IETF RFC를 제대로 검토하지 않는 바람에 RFC 2047 방식을 따르라고 했는데, RFC 2231 방식을 따라야 합니다. 하지만, 현재 RFC 2047 방식이 하도 널리 쓰이고 있어서 HTTP 헤더에서는 그냥 RFC 2047 방식을 허용해야 할 지도 모릅니다. (더구나, MS IE가 RFC 2231을 지원하지 않기 때문에 현실적으로 RFC 2047을 써야 합니다. )
하지만, 어떤 경우에도 그냥 8bit 글자를 내보내는 일은 피해야 합니다.
Content-Disposition: attachment; filename=그림.png
라고 하면 안 됩니다.
다음이 RFC 2231에 따른 방식입니다. 길이가 길지 않다면 RFC 2231이 RFC 2047보다 더 간단합니다.
Content-Disposition: attachment; filename*="UTF-8''%EA%B7%B8%EB%A6%BC.png"
Content-Disposition: attachment; filename*="EUC-KR''%B1%D7%B8%B2.png"
다음은 RFC 2047 방식입니다.
Content-Disposition: attachment; filename="=?EUC-KR?Q?=B1=D7=B8=B2.png?="
Content-Disposition: attachment; filename="=?UTF-8?B?6re466a8LnBu?="
http가 8bit-clean임에도 불구하고 위에 적은 것처럼 7bit로 바꿔 주어야 하는 이뉴는 filename에 쓰인 character encdoing/MIME charset이 무엇인지 알려 주기 위해서입니다. 물론, 모질라는 character encoding이 명시적으로 표시되지 않은 경우에도 다운로드하는 파일에 대한 링크가 걸린 페이지의 character encoding이 C-D 헤더에도 쓰였다고 가정하고 파일 이름을 알아내려는 노력을 합니다. 하지만, 어떤 경우에는 그것도 틀린 경우가 있습니다. 예를 들어, Shift_JIS 웹 페이지에서 EUC-JP를 쓰는 곳으로 링크를 걸어 놓았다면 그 방식은 원하는 결과를 주지 않지요.
요약하면, filename은 따옴표로 묶어야 합니다. 또, ASCII 범위 밖의 글자가 있을 때에는 character encoding을 표시해 줄 수 있는 RFC 2047/2231 방식으로 변환해야 합니다.
참, http가 아닌 RFC 2822 (인터넷 메일) 메시지를 작성할 경우에는 Content-Disposition 헤더에 <em>꼭</em> RFC 2231 방식을 써야 합니다. 웹 메일 인터페이스 등을 만들 때 참고하십시오.
http://www.faqs.org/rfcs/rfc2231.html
http://www.fsqs.org/rfcs/rfc2047.html
http://www.faqs.rog/rfcs/rfc2822.html
첫째 문제는 공백 문자가 들어감에도 불구하고, 따옴표로 묶지 않는 것입니다.
Content-Disposition: attachment; filename=this is a picture.png
위처럼 하면 안 되고, 아래처럼 해야 합니다.
Content-Disposition: attachment; filename="this is a picture.png"
두번째 문제는 ASCII 범위 밖의 글자를 내보낼 때입니다. 이 문제는 HTML 4.x 표준 저자들도 관련 IETF RFC를 제대로 검토하지 않는 바람에 RFC 2047 방식을 따르라고 했는데, RFC 2231 방식을 따라야 합니다. 하지만, 현재 RFC 2047 방식이 하도 널리 쓰이고 있어서 HTTP 헤더에서는 그냥 RFC 2047 방식을 허용해야 할 지도 모릅니다. (더구나, MS IE가 RFC 2231을 지원하지 않기 때문에 현실적으로 RFC 2047을 써야 합니다. )
하지만, 어떤 경우에도 그냥 8bit 글자를 내보내는 일은 피해야 합니다.
Content-Disposition: attachment; filename=그림.png
라고 하면 안 됩니다.
다음이 RFC 2231에 따른 방식입니다. 길이가 길지 않다면 RFC 2231이 RFC 2047보다 더 간단합니다.
Content-Disposition: attachment; filename*="UTF-8''%EA%B7%B8%EB%A6%BC.png"
Content-Disposition: attachment; filename*="EUC-KR''%B1%D7%B8%B2.png"
다음은 RFC 2047 방식입니다.
Content-Disposition: attachment; filename="=?EUC-KR?Q?=B1=D7=B8=B2.png?="
Content-Disposition: attachment; filename="=?UTF-8?B?6re466a8LnBu?="
http가 8bit-clean임에도 불구하고 위에 적은 것처럼 7bit로 바꿔 주어야 하는 이뉴는 filename에 쓰인 character encdoing/MIME charset이 무엇인지 알려 주기 위해서입니다. 물론, 모질라는 character encoding이 명시적으로 표시되지 않은 경우에도 다운로드하는 파일에 대한 링크가 걸린 페이지의 character encoding이 C-D 헤더에도 쓰였다고 가정하고 파일 이름을 알아내려는 노력을 합니다. 하지만, 어떤 경우에는 그것도 틀린 경우가 있습니다. 예를 들어, Shift_JIS 웹 페이지에서 EUC-JP를 쓰는 곳으로 링크를 걸어 놓았다면 그 방식은 원하는 결과를 주지 않지요.
요약하면, filename은 따옴표로 묶어야 합니다. 또, ASCII 범위 밖의 글자가 있을 때에는 character encoding을 표시해 줄 수 있는 RFC 2047/2231 방식으로 변환해야 합니다.
참, http가 아닌 RFC 2822 (인터넷 메일) 메시지를 작성할 경우에는 Content-Disposition 헤더에 <em>꼭</em> RFC 2231 방식을 써야 합니다. 웹 메일 인터페이스 등을 만들 때 참고하십시오.
http://www.faqs.org/rfcs/rfc2231.html
http://www.fsqs.org/rfcs/rfc2047.html
http://www.faqs.rog/rfcs/rfc2822.html