파일 입출력시 유니코드 불완전 지원 버그

[-ㅁ-;]

타국어 윈도우에서 한국어 파일 이름으로 저장된 파일을 제대로 다루지 못합니다. file:/// 로도 마찬가지이고, 첨부파일을 다운로드 받을 때에도 대화상자에는 제대로 보이지만 저장할 때는 ______.txt 와 같이 저장됩니다.

간단히 재현하는 예로

일본어 윈도우에서, 파이어폭스 2로 (저는 영문판을 씁니다)

http://bbs.moneta.co.kr/nbbs/bbs.normal.lst.screen

이 사이트의 글 아무거나 첨부파일을 다운로드 받으려고 해보면 됩니다. 파일 이름이 한국어가 많아서.. IE에서는 아무 문제없이 다운로드가 되는데 파이어폭스에서는 다운로드 받는 도중에는 한국어 파일명이 잘 처리되다가 다운로드 완료 후에 갑자기 _____.ppt 등으로 바뀌어버리던데요.

[CN]

타국어 윈도우에서 한국어 파일 이름으로 저장된 파일을 제대로 다루지 못합니다. file:/// 로도 마찬가지이고, 첨부파일을 다운로드 받을 때에도 대화상자에는 제대로 보이지만 저장할 때는 ______.txt 와 같이 저장됩니다.

간단히 재현하는 예로

일본어 윈도우에서, 파이어폭스 2로 (저는 영문판을 씁니다)

http://bbs.moneta.co.kr/nbbs/bbs.normal.lst.screen

이 사이트의 글 아무거나 첨부파일을 다운로드 받으려고 해보면 됩니다. 파일 이름이 한국어가 많아서.. IE에서는 아무 문제없이 다운로드가 되는데 파이어폭스에서는 다운로드 받는 도중에는 한국어 파일명이 잘 처리되다가 다운로드 완료 후에 갑자기 _____.ppt 등으로 바뀌어버리던데요.

저는 한국어 윈도우에서도 파일명은 자주 깨어집니다. 아마도 국내의 대부분의 사이트가 utf-8를 사용하지 않아서 그런 것으로 예상됩니다. 다른 분들의 생각은 어떠세요?

[우가가]

그건 버그이면서 버그랄 수 없는, 여러 당사자간의 합작품입니다.
웹서버 개발측, 브라우저 개발측, 등등..

file attachment에 대한 이렇다할 표준안이 없다는 게 진짜 이유죠.

서버측에서 미리 다운로드할 파일명을 인코드해 주지 않으면
IE도 FF와 같이 파일명이 깨집니다. (단 깨지는 모양은 같지 않습니다)

반대로 인코드를 해 주면 (여기서의 인코드는 %BD%FC%B0... 이런 식으로
변환하는 걸 말합니다) FF가 그 문자열을 그대로 받아들이더군요..

위와 같은 인코드를 하지 않을 경우 서버가 내려주는 파일명은 바이트 단위의
스트림으로 전달되는데, 이를 IE나 FF는 으레 해당 로케일(OS나 사용자의)에
맞는 스트림으로 간주하고 이를 해석합니다.

해석 중에 문자가 깨지는 경우도 있고, IE7 등은 (---.gif) 같이 일정한 문자열로 깨버리기도 합니다.

국내의 많은 웹어플 개발자들은 두가지 방법들 중 하나를 씁니다.
1. 다운로드할 파일명을 %BD%FD%... 식으로 인코드해서 보냄
(IE에서 정상동작)
2. 다운로드할 파일명을 확장완성형(CP949)으로 바이트 단위로 인코드해서 보냄
(우리나라 대부분의 브라우저에서 정상동작.. 다만
외국 로케일을 가진 OS 상의 브라우저에서는 오동작합니다)

특이한 케이스로, 오페라는 내려오는 바이트 스트림을 자기 인코딩 설정으로 해석합니다. 이게 제일 훌륭한 대안이긴 한데(어느 로케일 설정에서도 정상작동).. 시중의 웹어플들은 이걸 반영하고 있지 않죠..


계속 강조하지만, 이 문제에 대한 어느 한 진영에서 제시할 수 있는 해결책은 거의 없습니다.

이에 대한 적절한 표준안이 나오는 것만 기다릴 밖에요..

[-ㅁ-;]

아뇨, 파일 입출력시 인코딩을 처리하는 부분 자체에 버그가 있지 않나 싶습니다.

file:/// 을 통해서 파일시스템을 액세스하는 경우에도 타 언어권 파일의 경우 제대로 다뤄지지 않는데다가, 분명히 다운로드 창에서까지는 멀쩡히 보이던 파일 이름이 (UTF-8 Escape 인코딩으로) 저장되고 나면 _____.pdf가 되어 있는 것은 이상하지 않나요?