Mozilla 한국 커뮤니티

일단 아래 주소를 한번 보세요.

http://elentir.cafe24.com/ 별로 볼거 없는 제 계정입니다.

여기에 한글이름으로 된 파일 두 개를 올려놓았습니다. 파일이름은 [번역]Tiddly-설명서(미완).doc 와 [번역]Tiddly-설명서(미완).txt 이고 확장자만 doc txt 일 뿐 둘다 똑같은 텍스트파일입니다

인덱스 페이지는 볼거 없고 utf8.html 파일은 UTF-8 로 euckr.html 파일은 EUC-KR 로 인코딩해서 저장했을 뿐 똑같습니다.

IE에서

1. 옵션에서 "URL을 항상 UTF-8로 보냄" 옵션 해제

1.1 euckr.html - doc 파일은 워드(패드) 문서로 txt 파일은 브라우저로 정상적으로 보임. URL 파일이름 모두 한글로 나옴.
[번역]Tiddly-설명서(미완).doc
http://elentir.cafe24.com/[번역]Tiddly-설명서(미완).txt

1.2 utf8.html - URL 한글로 보이지만 페이지에러.


2. 옵션에서 "URL을 항상 UTF-8로 보냄" 옵션 체크.

2.1 euc-kr.html - URL 한글. 페이지 에러

2.2 utf8.html - URL 한글. 페이지 에러


FF에서

1. 디폴트 상태.
network.standard-url.escape-utf8 = true
network.standard-url.encode-utf8 = false

1.1 euckr.html - doc 파일은 워드(패드) 문서로 txt 파일은 브라우저로 정상적으로 보임. 그러나 URL 과 파일 이름이 인코드된 상태로 나타남.

%5B%B9%F8%BF%AA%5DTiddly-%BC%B3%B8%ED%BC%AD(%B9%CC%BF%CF).doc %5B%B9%F8%BF%AA%5DTiddly-%BC%B3%B8%ED%BC%AD(%B9%CC%BF%CF).txt

1.2 utf8.html - URL 인코드상태. 페이지 에러.


2. network.standard-url.escape-utf8 = false
network.standard-url.encode-utf8 = false

2.1 euckr.html - 1.1과 같음.

2.2 utf8.html
2.2.1 [번역]Tiddly-설명서(미완).doc - 워드로 정상적으로 보임. 파일이름 정상.
2.2.2 [번역]Tiddly-설명서(미완).txt - [, ] 두 문자가 %5B, %5D 로 인코드되어서 나옴. 페이지 에러.
%5B번역%5DTiddly-설명서(미완).txt


3. network.standard-url.escape-utf8 = true
network.standard-url.encode-utf8 = true

3.1 euckr.html - URL 인코드상태. 페이지 에러.
3.2 utf8.html - URL 인코드상태. 페이지 에러.


4. network.standard-url.escape-utf8 = false
network.standard-url.encode-utf8 = true

4.1 euckr.html - URL 인코드상태. 페이지 에러.
4.2 utf8.html - URL 인코드상태. 페이지 에러.


결과 1.
FF에서 결과적으로 가장 만족한 경우는 2.2.1 인 경우이지만 doc 문서와 txt 문서를 같이 다루는 경우에는 소용이 없음. 그리고 결정적으로 ScrapBook 확장으로 스크랩했을 경우에는 읽어들일 수 없음.

결과 2.
1.1 과 2.1일 경우 파일 대부분의 경우에는 파일이름이 인코드 된다는 것 이외에는 별 문제가 없음. 파일을 저장할 경우에는 원래 정상적인 한글 이름으로 저장할 수 있음. 그러나 ScrapBook 확장으로 캡쳐할 경우 인코드된 파일명 URL 에서 % 문자가 모두 @ 로 치환되는 현상이 발생하며 이 경우엔 파일 저장을 할 때에도 원래 한글이름이 아닌 @ 문자로 치환된 인코드 파일명이 나타나게 되어 원래 한글이름을 알 수 없게 됨.

결과 3. <가장 치명적인 결과>
IE 의 경우에는 페이지 에러인 경우에도 파일을 "새이름으로 저장"하면 저장이 가능함. 그러나 FF인 경우에는 페이지 에러인 경우 "새이름으로 저장"하면 저장이 되는 듯 하지만 내용은 모두 에러코드로 가득 찬 dummy file 이 생성됨. (T_T)TL
위 삽질에 대한 속시원한 설명을 부탁드립니다. 그리고 해결책도 아울러 부탁드립니다.

FF를 계속 써야되나 말아야되나 심각하게 고민 중입니다.

웹 서버가 IRI를 지원하지 않는다면, 피할 수 없는 문제입니다. 현재 로컬 파일 시스템에서는 EUC-KR을 쓰고 있는 것 같군요. 그렇다면, 웹 서버가 IRI(UTF-8만 쓰게 되어 있습니다)를 보낼 때 웹 서버가 이를 '감지'하고 로컬 파일 시스템에 해당하는 파일을 찾도록 자동으로 해 주어야 하는데, 그렇게 하고 있지 않습니다. Apache 2.x용으로는 그런 기능을 하는 확장 모듈이 나와 있지만 Apache 1.x용은 없습니다. 박원규님이 만든 게 있기는 한데, Apache 2.x용으로 IRI를 규정한 RFC의 저자가 쓴 것만큼 기능이 많지 않습니다.

또, utf8.html에서 링크가 걸린 인코딩이 EUC-KR인 문서가 깨저 보이는 것도 당연합니다. 그 문서의 인코딩이 EUC-KR이지만, http 헤더를 통해 EUC-KR이라고 선언하지 않았기 때문에 firefox는 링크를 건 문서의 인코딩(UTF-8)이라고 가정하고 열고 있습니다. 이에 반해 IE는 인코딩이 명시되지 않은 경우에 쓸 기본 인코딩 값(EUC-KR)이라고 가정하고 있는 듯 하군요. 장단점이 있고, 논란의 여지가 있는 문제이지만, 옳고 그름이 있는 것은 아닙니다. EUC-KR인 문서라면 http 헤더를 통해 Content-Type을 'text/plain; charset=EUC-KR'이라고 명시해 주는 게 (apache라면 매우 쉽게 그렇게 할 수 있습니다.) 표준에도 부합하고, 어느 브라우저에서나 제대로 보이도록 하는 길입니다.

빛알갱이 wrote:웹 서버가 IRI를 지원하지 않는다면, 피할 수 없는 문제입니다. 현재 로컬 파일 시스템에서는 EUC-KR을 쓰고 있는 것 같군요.

여기서 로컬 파일 시스템이란 건 위에서 cafe24.com 서버 말씀이신가요? 그럼 결국 cafe24 의 문제인가요? 그런데 왜 IE에서는 되는거죠?

빛알갱이 wrote:또, utf8.html에서 링크가 걸린 인코딩이 EUC-KR인 문서가 깨저 보이는 것도 당연합니다. 그 문서의 인코딩이 EUC-KR이지만, http 헤더를 통해 EUC-KR이라고 선언하지 않았기 때문에 firefox는 링크를 건 문서의 인코딩(UTF-Cool이 라고 가정하고 열고 있습니다. 이에 반해 IE는 인코딩이 명시되지 않은 경우에 쓸 기본 인코딩 값(EUC-KR)이라고 가정하고 있는 듯 하군요. 장단점이 있고, 논란의 여지가 있는 문제이지만, 옳고 그름이 있는 것은 아닙니다. EUC-KR인 문서라면 http 헤더를 통해 Content-Type을 'text/plain; charset=EUC-KR'이라고 명시해 주는 게 (apache라면 매우 쉽게 그렇게 할 수 있습니다.) 표준에도 부합하고, 어느 브라우저에서나 제대로 보이도록 하는 길입니다.

음... 이 부분은 제가 이해가 좀 안되는군요. 저는 문서(그러니까 doc, txt 파일)의 인코딩에 대해서는 말한 적이 없습니다. 제가 위에서 했던 삽질은 html 의 인코딩과 FF 의 위의 두 옵션에 따라 링크가 어떻게 되는가 (링크가 걸리는가 끊어지는가) 하는 것이고 제가 알고 싶은 것은 IE는 한글을 반환하는데 왜 FF 는 그걸 인코드된 문자열로 반환하는가 하는 겁니다. 그리고 IE와 같은 방식으로 할 수 있는 방법은 없는건지 궁금한 겁니다.

제가 이러는 건, 제가 늘 스크랩하는 게시판에서 첨부파일들이 모두 저런 문제에 걸려있기 때문입니다. 업무상 온라인에서 첨부파일을 그대로 클릭해서 읽어보곤 하는데 (제 컴퓨터로 저장하는 경우는 별로 없습니다.) 그럴때 파일명이 모두 인코드되어서 문서를 여러개 열어놓으면 뭐가뭔지 구별이 안될 뿐더러, 그걸 ScrapBook 으로 스크랩해버리면 그나마 인코드된 파일명도 또 변형되어버리기 때문에 나중에 검색으로 찾을 수가 없기 때문입니다. 그 파일을 찾을 때마다 FF를 실행시켜 ScrapBook을 실행시켜서 검색할 수도 없는 노릇이고요. 사실은 로컬 컴퓨터에 FF를 설치할 수가 없기 때문에 현재 궁여지책으로 PFF를 쓰고 있지만 속도도 느리고 번거롭기도 하고 그렇죠.

FF에 애정을 갖고 제 개인적으로는 기본브라우저로 쓰고 있지만 솔직히 저 문제가 해결되지 않으면 IE용 스크랩유틸을 찾아서 사용하는 수 밖에 없고 그러면 개인적으로도 IE를 사용할 수밖에 없으니 좀 답답해서 적었습니다.

el wrote:

빛알갱이 wrote:웹 서버가 IRI를 지원하지 않는다면, 피할 수 없는 문제입니다. 현재 로컬 파일 시스템에서는 EUC-KR을 쓰고 있는 것 같군요.

여기서 로컬 파일 시스템이란 건 위에서 cafe24.com 서버 말씀이신가요? 그럼 결국 cafe24 의 문제인가요? 그런데 왜 IE에서는 되는거죠?

IE에서 뭐가 되었지요? IE도 문제가 있었지 않습니까? 단지, 되는 경우와 안 되는 경우가 FF와 달랐을 뿐이지요.

음... 이 부분은 제가 이해가 좀 안되는군요. 저는 문서(그러니까 doc, txt 파일)의 인코딩에 대해서는 말한 적이 없습니다. 제가 위에서 했던 삽질은 html 의 인코딩과 FF 의 위의 두 옵션에 따라 링크가 어떻게 되는가 (링크가 걸리는가 끊어지는가) 하는 것이고 제가 알고 싶은 것은 IE는 한글을 반환하는데 왜 FF 는 그걸 인코드된 문자열로 반환하는가 하는 겁니다. 그리고 IE와 같은 방식으로 할 수 있는 방법은 없는건지 궁금한 겁니다.

본래 글을 잘 이해하기 어렵군요. 그 문제도 언급하셨지만, 제가 읽은 바로는 그 문제는 간단하게 언급하고, 파일 *내용*이 제대로 보이느냐 안 보이느냐에 대해 더 많은 부분을 할애하지 않으셨나요?

주소창에 표시할 때 IRI를 쓰느냐 안 쓰느나는 그리 간단한 문제가 아닙니다. IE의 방법이 언뜻 좋은 듯 하지만, 현재 IRI 지원 상황에 비추어 꼭 그런 것도 아니고요.

제가 중언부언 글을 써서 그런지 제가 말하고자하는 바가 제대로 전달되지 않는군요.

제가 원하는 것은

웹페이지에 올려진 한글이름의 파일을 브라우저에서 클릭했을 때 (주로 doc, xls, ppt, hwp, txt 등등) 그 파일들을 어플리케이션이 로딩하면서 원래 한글이름을 그대로 유지할 수 있느냐 하는 겁니다.

제가 제 계정에 올려놓은 파일 (예를 들어 "한글이름파일.doc " 이라면)
1. IE 에서 클릭할 때 - 워드(패드)가 실행되면서 "한글이름파일.doc" 를 읽어들인다.
2, FF 에서 클릭할 때 - 워드(패드)가 실행되면서 "%BL%AH%BL%AH%BL%AH.doc" 를 읽어 들인다.

라는 두 가지 결과에 대해서

그 이유와 해결방안을 알고 싶은 겁니다.


그리고 사무용 컴퓨터에 FF를 깔아서 사용하고픈 제 입장에서는 URI 니 IRI 니 하는 전문용어(?)가 필요한 게 아니라, 어느 메뉴 어떤 옵션에서 어떤 버튼을 누르면 되는 혹은 어떤 확장을 설치해야 하는지입니다.


그것이 절실하게 필요한 이유는 이미 썼으니 재론하지 않겠습니다.

IE 쓰세요 라는 답변은 사양합니다.