Mozilla 한국 커뮤니티

firefox에서 띄어쓰기 파일 다운로드 하면 띄어쓰기 앞에까지만 파일명으로 들어갑니다.

<a href="띄어 쓰기.pdf">파일다운로드</a>
이 경우는 잘 작동합니다.

하지만
a href의 방법이 아닌 다른 방법을 사용한 경우에는 다운로드시
띄어쓰기가 있는 파일은 다운로드된 파일이름이 띄어쓰기 앞에 까지만 먹습니다.
예: 다음까페에서의 파일명이 띄어쓰기인 파일 다운로드시

아마도 ""(따옴표)가 안돼서 그렇지않나 나름대로 추측은 해보지만
IE의 경우 제대로 파일명이 띄어쓰기 다 되서 나오는데요.

고칠 수는 없는건가요?

이것도 다음까페 등이 표준을 안 지켜서 그런건가요.?

파일 이름에 '빈칸'을 쓰는 것이 문제의 불씨가 아닌가요?

<인터넷 익스플로러>가 저지른 많은 범죄 가운데 하나라는

_(또는 -)을 써서 '빈칸'을 없애는 것이 좋을 듯합니다.

파스텔그림 wrote:firefox에서 띄어쓰기 파일 다운로드 하면 띄어쓰기 앞에까지만 파일명으로 들어갑니다.



이것도 다음까페 등이 표준을 안 지켜서 그런건가요.?

예, 제가 그 부분을 프로그램했는데, 너무나 명백한 표준 위반이라서 절대 봐 줄 수 없습니다. 다음 측에는 이미 오래 전에 얘기했지만, 고칠 생각을 안 하고 있군요.

파일 이름에 공백을 쓰는 것이 표준 위반이 아니라, 공백이 들어간 파일 이름을 다음의 서버에서 클라이언트에 '통지'하는 방법 상에 표준 위반이 있습니다.

그냥 생각하기에는 파일이름에 '빈칸'이 있더라도 정상적으로
다운로드나 업로드 되는게 좀 더 이치에 맞는다고 생각하는데요.

빈칸 있는 파일은 업로드나 다운로드 할때 제한을 둔다면 왠지 개방성에 문제가 생길듯 하고...

표준이 바뀌었음하는 바램이네요.

빈칸있는 파일도 '-'나 '_'로 빈칸을 메우지 않고
그냥 빈칸 그대로 업로드/다운로드 할 수 있도록...

다음*의 표준 위반이군요.

저는 이때까지 파일 이름을 띄어 쓴 것은 문제가 있는 줄 알고 밑줄(_) 또는 옆줄(-)을 넣었는데... 음냐...



흑흑...

파스텔그림 wrote:그냥 생각하기에는 파일이름에 '빈칸'이 있더라도 정상적으로
다운로드나 업로드 되는게 좀 더 이치에 맞는다고 생각하는데요.

맑은 돌님은 제 말을 잘 이해하셨는데, 파스텔 그림님은 오해하신 듯. 파일 이름에 공백을 쓰는 게 표준 위반이 아니라, 그런 이름을 다음에서 처리하는 방식에 문제가 있다는 얘기입니다. 제대로 표준을 지키는 웹 사이트에서는 아무 문제도 없습니다. 또, 다음에서도 다운로드가 안 되는 게 아니라 파일 이름만 잘리는 것이니까 굳이 표준 위반을 봐 주기 위해 코드를 지저분하게 만들 필요가 없다고 결론을 내렸답니다.

이 경우 다음에서 할 일은 지극히 간단합니다. 파일 다운로드할 때 내보내는 Content-Disposition 헤더에서 현재

filename=foo bar.pdf

하는 것을

filename="foo bar.pdf" (따옴표로 둘러 싸기)

혹은

filename=foo%20bar.pdf

와 같이 하면 됩니다.

올린 사람이나, 서버 측이 잘못한 건 사실이지만, 이런 건 파폭에서 기본적으로 처리할 수 있는 문제 아닌가? 자바스크립트로도 해결할 수 있을 듯 한데...

흠. 자세히 보니... 코드와의 구별도 쉽지 않고, 그리 간단한 문제는 아니군요.

그 부분에서 지켜야 할 표준은 RFC 2231일입니다. RFC 2231은 줄도 여러 개가 될 수도 있고, 지정할 수 있는 parameter도 언어와 문자 인코딩 등 여러 개입니다. MS IE는 이런 것을 하나도 지원하지 않습니다.

Content-Disposition: attachment; filename*0*ko*euc-kr*=%B0%A1.....
filename*1*de*iso-8859-1*=foo%B1bar%20%C1......

(위에 적은 보기는 정확히 RFC 2031을 따른 것은 아닙니다. 지금 대충 생각나는 대로 적은 것입니다.)

게다가 RFC 2231대신 RFC 2047을 잘못 쓰는 경우도 많으므로 그것도 처리해 주어야 합니다.

이런 것도 다 처리해 주지 않고, 가장 기본적인 표준만 따른다고 해도 이와 같은 너무나 심각한 표준 위반은 봐 줄 여지가 전혀 없습니다. quote되지 않은 공백은 MIME 헤더에서 parameter와 parameter를 가르는 delimeter입니다. 따라서, 공백을 quote하지 않고 그 뒤에 온 것이 계속 이어진 파일 이름인지 새로 시작하는 다른 parameter인지 구별할 방법이 없습니다. 물론, 몇 가지 꽁수를 쓸 수 있지만, 그럴 필요는 못 느낍니다.

빛알갱이 wrote:다음 측에는 이미 오래 전에 얘기했지만, 고칠 생각을 안 하고 있군요.

방금 메일, 카페, 플래닛, 공용 게시판 개발 PL들에게 메일로 알려 주었습니다. 해결되면 다시 알려드리겠습니다. 따옴표를 안 넣은 것은 개발자 실수 같습니다.

http://www.scourt.go.kr/dcboard/DcNewsV ... seqnum=518

여기서 다운로드를 하려고 하면 공백 이전까지만 나오고 있습니다.

그리고 추가 문제가 있는데, 저렇게 잘린 거라도 한글이 제대로 나오면 좋겠는데 실은 '노'마저도 두 바이트의 확장 아스키 문자로 파일이름에 들어갑니다. 어떤 식으로 하면 고칠 수 있는지 알고 싶습니다. 해결책이 있으면 저런 현상이 보이는 기관에 연락해서 바꾸는 건 시간만 있으면 되니까요.

sakura님의 도움으로 확인했습니다. 헤더의 filename에 들어가는 문자열과 charset을 UTF-8와 EUC-KR로 했을 때,

윈도우의 FireFox에서는 다 되고, IE에서는 UTF-8일 경우 깨집니다. IE는 W2K에서 한 건데, 윈도우 API가 UTF-8를 제대로 처리하지 못해서라는 얘기도 있었다고 들었습니다.

리눅스 FireFox는 UTF-8 로케일 환경에서 UTF-8 파일명은 인식하고, EUC-KR은 깨집니다.

브라우저와 시스템을 판별해 따로 뿌려주는 것 말고 (표준에 맞는) 어떤 헤더를 어떤 식으로 찍어주면 되는 방법은 없을까요?

kz wrote: 브라우저와 시스템을 판별해 따로 뿌려주는 것 말고 (표준에 맞는) 어떤 헤더를 어떤 식으로 찍어주면 되는 방법은 없을까요?

리눅스용 firefox와 Windows용 firefox가 다르게 동작할 리는 절대 없습니다. 혹시 다른 버전을 쓰신 것 아닌가요? 표준에 맞는 방법은 RFC 2231을 따르는 것입니다만 - 사실 HTTP에서 Content-Disposition은 표준 헤더가 아니라서 HTTP에서 따로 규정해 놓지 않았습니다. 그렇다면 C-D를 규정한 MIME 규정인 RFC 2231을 따를 수 밖에 없습니다.- MS IE 등이 인식하지 못 하므로, 차선책으로 RFC 2047을 쓰는 수 밖에 없습니다. RFC 2047을 보시고, 그에 따라 인코딩하십시오. 그러면, 대다수의 브라우저가 제대로 인식합니다.

http://www.mic.go.kr/user.tdf?a=user.bo ... P_02_02_01

정보통신부인데, 불여우에서 헤더를 잡아보면 charset 정보가 없습니다. 이게 리눅스의 불여우와 오페라에서 한글이 잘 나옵니다. 익스플로러에는 당연히 잘 나오겠죠.

charset이 없을 때 오히려 잘 나오는 것이 조금 놀랍습니다.

kz wrote:http://www.scourt.go.kr/dcboard/DcNewsV ... seqnum=518

여기서 다운로드를 하려고 하면 공백 이전까지만 나오고 있습니다.

그리고 추가 문제가 있는데, 저렇게 잘린 거라도 한글이 제대로 나오면 좋겠는데 실은 '노'마저도 두 바이트의 확장 아스키 문자로 파일이름에 들어갑니다. 어떤 식으로 하면 고칠 수 있는지 알고 싶습니다. 해결책이 있으면 저런 현상이 보이는 기관에 연락해서 바꾸는 건 시간만 있으면 되니까요.

아래 링크에서 내용을 참고하세요.

다운로드시 공백이 있는 파일명 잘림 현상

그리고 TruncFix 라는 확장기능을 설치하면 http://www.scourt.go.kr의 짤림 문제는 해결될 것입니다.

kz wrote:http://www.mic.go.kr/user.tdf?a=user.bo ... P_02_02_01

정보통신부인데, 불여우에서 헤더를 잡아보면 charset 정보가 없습니다. 이게 리눅스의 불여우와 오페라에서 한글이 잘 나옵니다. 익스플로러에는 당연히 잘 나오겠죠.

charset이 없을 때 오히려 잘 나오는 것이 조금 놀랍습니다.

거기 있는 PDF 파일 다운로드를 얘기하나요? 현재 FF가 C-D 헤더를 해석하는 방법은 앞선 글에서 설명했다시피 RFC 2231, RFC 2047, UTF-8 (raw), 다운로드 링크가 걸린 문서의 인코딩(raw) 순입니다. 정통부 사이트에서 C-D에 charset이 없을 때 잘 보이는 것은 앞의 3가지 방법이 모두 실패하니까 4번째 방법을 시도해서 제대로 보인 것입니다.

현재 MS IE는 - 제가 앞선 글에서 쓴 바와 달리 - RFC 2231을 제대로 해석하지 못 함은 물론이고, RFC 2047과 UTF-8 (raw)도 제대로 해석하지 못 합니다. 오직 4번째 방법만을 쓰고 있습니다. 반면에 Opera는 RFC 2231과 UTF-8(raw)만을 제대로 해석합니다.

이렇게 브라우저마다 다른 행태를 보이는 것에는 HTTP 표준 작성자가 이 부분에 대해 명확한 규정을 하지 않은 잘못도 있습니다. 하지만, MS IE처럼 링크가 걸린 페이지의 문자 인코딩에만 의존하는 것은 (원래 링크를 걸어 놓은 페이지와 관계 없이) 그 파일만을 따로 다운로드하도록 URL을 줄 경우에는 문제가 생깁니다.

소프트원트 wrote:다운로드시 공백이 있는 파일명 잘림 현상

그리고 TruncFix 라는 확장기능을 설치하면 http://www.scourt.go.kr의 짤림 문제는 해결될 것입니다.

네 TruncFix라는 걸 깔고 나니 파일이름이 끝까지 잡히긴 합니다. 고맙습니다. 근데 인코딩에 따른 깨짐은 해결이 안됩니다.

제가 하고 싶은 건 이런 문제에 대한 universal한 해결책을 찾아서 각 사이트 관리자에게 '이렇게 하면 아무데나 잘 되니까 고쳐주세요'라고 친절하게 강요하는 거거든요. 따라서 어떤 확장을 설치하면 (개인 컴에서는) 된다는 식이 아니라 어떤 헤더를 어떻게 출력하면 된다는 답이 필요합니다.

RFC 번호를 말씀하시면서 '이걸 적용하면 된다'는 말씀은 참 좋은 말씀인 거 같기는 한데 정확히 결과물의 모습이 어때야 한다는 건지 잘 모르겠습니다. -_-;;

kz wrote:http://www.mic.go.kr/user.tdf?a=user.bo ... P_02_02_01

정보통신부인데, 불여우에서 헤더를 잡아보면 charset 정보가 없습니다. 이게 리눅스의 불여우와 오페라에서 한글이 잘 나옵니다. 익스플로러에는 당연히 잘 나오겠죠.

charset이 없을 때 오히려 잘 나오는 것이 조금 놀랍습니다.

대법원이나 정통부 모두 C-D 헤더 필드의 filename parameter에 아무런 charset 정보를 포함하고 있지 않습니다. 따라서, 둘은 그 점에서 아무런 차이도 없습니다. 둘 사이의 차이는 URL에 있습니다. 대법원 사이트는 URL의 끝 부분이 파일 이름으로 해설될 수 있는 문자열이 들어 있어서 그 부분으로부터 ff가 파일 이름을 추출하는 과정에서 문제가 생기고 있습니다. 그런데, 그 부분에 버그가 있어서 현재 locale encoding을 참조해서 그 부분을 해석하는 인코딩을 결정하는 듯 합니다. 이에 따라 위에서 적으신 Linux의 locale에 따른 차이가 생긴 것입니다. 제가 차이가 없을 것이라고 한 까닭은 C-D만을 참조할 것이라고 생각했기 때문입니다. [1] (C-D 해석 코드는 제가 썼습니다.) 따라서, 제가 단언한 것은 잘못입니다. C-D를 참조하기에 앞서 그 부분을 참조하는 것은 문제 (최소한 논란의 여지)가 있습니다. 오른쪽 클릭해서 Save As를 할 때에 그렇게 하는 것은 이미 알려진 버그이지만, 바로 다운로드를 할 때에는 그렇게 하지 않는 것으로 알고 있었는데, 잘못 알고 있었군요.



[1]
http://jshin.net/moztest/download.html
에 있는 모든 경우를 firefox는 잘 처리합니다.

kz wrote: 제가 하고 싶은 건 이런 문제에 대한 universal한 해결책을 찾아서 각 사이트 관리자에게 '이렇게 하면 아무데나 잘 되니까 고쳐주세요'라고 친절하게 강요하는 거거든요. 따라서 어떤 확장을 설치하면 (개인 컴에서는) 된다는 식이 아니라 어떤 헤더를 어떻게 출력하면 된다는 답이 필요합니다.

최근에 김정균님이 jsboard에 그런 기능을 집어 넣었습니다. http://jshin.net/moztest/download.html에 있는 보기를 각 브라우저 별로 시험해 보면 브라우저들 사이의 차이를 아실 수 있습니다. HTTP 표준 저자가 이런 문제에 대한 충분한 고려를 하지 않은 게 이런 혼란의 원인을 제공했다고 볼 수 있네요.

JSboard의 관련 버그는 여기에 있습니다.

http://tinyurl.com/mp9jq

RFC 번호를 말씀하시면서 '이걸 적용하면 된다'는 말씀은 참 좋은 말씀인 거 같기는 한데 정확히 결과물의 모습이 어때야 한다는 건지 잘 모르겠습니다. -_-;;

제가 그 긴 RFC를 여기서 다 일일이 설명할 수는 없지 않겠습니까?

내가 아는 길을 남도 안다고 생각하면 오산입니다.
내가 아는 길을 설명할 때, 내가 아는 지표를 기준으로 설명하면 대부분 못 알아 듣습니다,
그 이유는, 내가 아는 지표를 상대방은 잘 모르거든요,,,
예를 들면, 파폭설치 고객센타에 가면, 이런 글이 있습니다.

"firefox not installed" 메시지가 나타나거나 다른 버전의 Firefox가 실행될 경우
반드시
bash$ ~/firefox/firefox
명령으로 Firefox를 실행시켜야 합니다.
bash$ firefox
명령으로 실행시키면 패키지 관리 시스템이 설치한 Firefox 버전이 실행되거나,
프로그램이 설치되어 있지 않다는 메시지를 보여 줄 것입니다.
Did this article solve a problem you had with Firefox?

자, 여기서 검토해 보지요
문제가 잇으니 여기까지 온 것이고, 이글을 보고 있는데요
위와 같이 실행해야 한다고 하는것 까지는 좋은데요,
" 명령으로 실행시키면 패키지 관리 시스템이 설치한 Firefox 버전이 실행되거나,
프로그램이 설치되어 있지 않다는 메시지를 보여 줄 것입니다. "

도대체 이게 무슨 말입니까? 업글이 안되고, 이전 버전의 파폭이 실행되니 문제가 잇는데,
그렇게 될거라면, 누굴 놀리시나요? 그리고 어쩌라구요?
Did this article solve a problem you had with Firefox?
문제가 해결에 도움이 됫는냐 묻는데요, 물론 응답은 0점입니다.
개발 사이트의 공식 고객지원 매니저의 생각과 결과가 이정도 라면
앞으로 리눅스, 파폭의 앞길이 정말로 걱정됩니다.