MS IE는 raw octet을 보내는 경우에만 이해하는데, 이때 인코딩은 링크가 걸린 페이지의 인코딩과 일치해야 합니다.

Firefox는 RFC 2231을 맨 먼저 시도하고, RFC 2047, UTF-8 (raw octet), 링크가 걸린 페이지의 인코딩 (raw octet)을 차례로 시도합니다. (뒤의 두 경우 순서가 약간 헛갈리는군요)

따라서, 이 세 브라우저의 공통 분모는 페이지에서 EUC-KR을 쓰는 경우 없습니다. 하지만, UTF-8을 쓴다면 (썩 만족스럽지 못 하지만) UTF-8로 raw octet을 보내는 공통 분모를 찾을 수 있습니다. 즉, UTF-8을 쓰는 게 더 좋은 또다른 이유가 여기에 있습니다.

참, 사파리 역시 이 경우에는 잘 동작할 것입니다. 전에 시험해 보았는데, 지금 기억이 안 나네요.

http://jshin.net/moztest/download.html (시험용 페이지)

http://kldp.net/tracker/?func=detail&atid=350148&aid=301258&group_id=148

(JSboard에 있던 이 문제를 처리하기 위한 논의 과정)

iabf.or.kr은 .NET을 쓰는군요. 써버측 프로그래머와 관리자도 문제이고 도구 개발자도 문제입니다. 하지만, 그들만을 탓하기도 힘듭니다. C-Disposition을 HTTP의 일부가 아니라 쓰는 경우도 있다 정도로만 해 놓고, 거기에 들어갈 param의 인코딩 방법에 대해 제대로 규정하지 않은 HTTP spec에도 책임이 있습니다. (메일에서 쓸 경우에 대해서는 RFC 2231에서 잘 규정하고 있지만요.)

개편 전에 on-line/off-line으로 두어 번 얘기했는데, 아쉽게도 아직 안 고쳐진 게 있네요.
(개편된 사이트에서는 글을 올릴 수 있는 곳을 못 찾겠네요….)

자료실에 있는 파일을 다운로드하려고 하면 PDF이든 HWP이든 application/octet-stream을 C-T로 내보내는군요. 공백이 들어가는 C-D의 filename 값도 따옴표로 감싸지 않은 탓에 firefox로 다운로드하려고 하면 파일 이름이 첫 공백에서 잘리는군요. 게다가 아무 필요가 없는 C-T-E 헤더 필드를 내보내고 있고요.

RFC 2231은 MS IE가 이해하지 못 하니 그것을 쓰라고는 못 하겠고요. Opera는 링크를 건 문서의 인코딩에 관계 없이 C-D의 filename 값으로 UTF-8만을 인식하니까 browser detection을 하지 않는 한 모든 브라우저를 만족시키기 힘들긴 합니다. 단, EUC-KR을 쓰지 않고, UTF-8을 썼다면 이런 문제가 없었겠지요.

웹 서버 관리자 및 서버측 프로그래머의 HTTP, MIME 등 관련 표준에 대한 인식 제고가 절실합니다.

다만 해외 관련 포럼처럼 사이트 자체를 블로그 + 포럼 형식으로 만들었다면, 좀 더 좋았을 것 같아요. 아직.. 국내/외 의식 차이가 너무 큰 문제가 있네요.