"e이유씨.txt"는 파일명이 euc-kr로 인코딩되어 저장되어 있고, "u유티에프8.txt"은 utf-8로 인코딩되어 저장되어 있습니다. 파일의 내용도 마찬가지로 서로 다른 인코딩으로 저장되어 있어서, 두 파일 중 한 쪽이 잘 보인다면 다른 한쪽의 내용은 깨져서 나올 것입니다만, 그건 브라우저의 보기->인코딩 메뉴에 가셔서 "한국어"와 "유니코드(UTF-8)"을 바꿔보시면 잘 나올 겁니다. 여기서 눈여겨 볼 것은 내용이 아니라 "파일 자체를 찾을 수 있는지, 아니면 404 Not Found 에러가 나는지" 여부입니다.
참고로, 두 파일은 다음과 같이 생성하였습니다.
서버의 기본 세팅이 euc-kr 이라서, "e이유씨.txt"는 ViEditor로 평범하게 작성하였고, "u유피에프8.txt"는 LANG 환경 변수의 값을 "ko_KR.utf-8"로 바꾸고, PuTTY의 연결 설정에서 창->변환->수신한 데이터를 이 문자셋으로 가정->"UTF-8"로 세팅한 후, 역시 vi로 작성하였습니다. 이 때 내용도 utf-8로 인코딩하기 위해서 :set fileencoding=utf-8로 하였지만 이건 여기서 중요한 문제는 아님.
두 개의 PuTTY에서 ls를 해보면 다음과 같이 확인할 수 있습니다.
(LANG=ko_KR.EUCKR (서버기본값), PuTTY 문자셋 설정 CP949)
(LANG=ko_KR.UTF-8, PuTTY 문자셋 설정 UTF-8)
결국 서버의 파일 시스템의 설정 같은 건 고려할 필요 없이 파일명은 그저 문자코드 그대로 정해지나 보네요. 이제서야 유니코드논의에 조희대님이 적어주셨던 답글을 제대로 체감했습니다 ^^;
테스트는 IE에서 위 4개의 링크를 각각 클릭했을 때와, 주소 표시줄에 직접 복사해서 엔터를 쳐서 불러올 때 동일한 결과를 냈습니다 (다만, 지금 보는 이 페이지가 EUC-KR 인코딩된 출력이라서, 링크를 클릭했을 경우에는 무조건 EUC-KR로 전송되고 있는 것이 아닌가 싶기도 합니다만... 결과가 동일한 걸 보니 그도 아닌 듯):
결과의 첫번째 줄 (1)과 (2)를 보면, IE의 옵션이 켜졌을 때는 UTF-8 파일명만 제대로 보이고, 꺼졌을 때는 반대로 EUC-KR 파일명만 제대로 보입니다. 지난 몇 년 간 서버는 주로 기존의 EUC-KR 인코딩을 써서 파일을 저장했을 터라, "그림이 X박스로 나와요" "파일 다운로드가 안 돼요" 등의 질문에 대한 답은 "URL을... 옵션을 끄세요"였던 거죠.
이 문제를 해결하는 방법 중 하나가 아파치 웹 서버에 별도 모듈로 들어가는 mod_url인데, .htacess 파일에 다음과 같이 넣으면 동작합니다.
<IfModule mod_url.c>
CheckURL on</IfModule>
이 경우, URL을 넘겨 받았는데 그 URL에 해당하는 파일이 없을 경우, URL이 UTF-8로 인코딩된 것이라고 간주하고, EUC-KR로 인코딩해서 처리한다고 합니다. 따라서 위 결과표의 (3)의 경우는 두 파일 다 정상적으로 볼 수 있습니다.
문제는 (4)에서 UTF-8 파일명의 경우인데, URL은 EUC-KR로 날아오는데 파일이 UTF-8로 저장된 경우, 이번에는 반대로 변환해주어야 하는데 그러지를 못하고 제대로 처리되지 않습니다. 이 문제에 관해 언급한 [KLDP 글타래]에 보면 mod_url 설정에 추가로 ServerEncoding, ClientEncoding 두가지 옵션을 주어서 역변환도 지원하도록 했다고는 하는데, 이 홈페이지가 있는 서버에서는 저 두 옵션을 인식하지 못하더군요. (저 얘기가 몇 년 전에 나온 건데도 그보다 이전 버전의 mod_url을 사용하는 모양입니다 -_-;)
(여담으로, IE7.0에서는 IE와 mod_url이 서로 묘하게 반응하는 바람에 또 문제가 되는 듯 하고, 태터툴즈 개발자 포럼 쪽 보면 이번에는 CheckURL을 off로 해야 태터툴즈의 작성한 블로그 포스트 링크에 한글이 포함되어 있을 때 제대로 된다는 얘기가 있더군요... 이래저래 mod_url에만 기대기도 힘든 상황인 듯. 관련 링크는 창을 닫아버려서 다시 찾기 귀찮은고로 생략)
UTF-8 인코딩된 페이지에서 링크를 클릭하는 경우는 또 다르다!
위 테스트에서는, "웹 페이지에서 4개의 링크를 각각 클리하는 경우와, 주소 표시줄에 4개의 주소를 각각 입력한 경우 결과가 동일"하다고 했습니다. 혹시나 싶어서 4개의 링크를 담고 있는 별도의 웹페이지(http://gypark.pe.kr/encoding/euckr.html)를 만들어서 해봐도 그렇습니다.
그런데, "내용이 UTF-8로 인코딩된 웹페이지에 있는 링크를 클릭하는 경우"는 뭔가 좀 다릅니다. http://gypark.pe.kr/encoding/utf8.html 에서 4개의 링크를 각각 클릭해보면:
웹페이지가 UTF-8이 아닐 때는, 그 안의 링크는 IE의 옵션에 따라서 UTF-8로 보내거나, 웹페이지의 인코딩과 같은 형식으로 보냄 - 웹페이지의 인코딩과 같은 형식일지 무조건 한글 윈도우즈에서는 EUC-KR일지 모르겠지만, 아무래도 전자가 맞겠죠. EUC-JP로 인코딩된 페이지의 링크를 EUC-KR로 보낸다는 것은 이상하니까
주소 표시줄에 입력한 경우는, IE의 옵션에 따라서 UTF-8로 보내거나, 다른 인코딩(아마도 한글 윈도우즈라면 EUC-KR?)으로 보냄
정도로 생각하면 되지 않을까 합니다... 이걸 명확히 얘기하는 문서의 주소를 아시는 분은 알려 주시면 감사하겠습니다.
(이 걸 진짜 이해하지 못하겠습니다)
지금 보는 이 페이지를 IE로 불러와 봅시다.
1) http://gypark.pe.kr/encoding/utf8.html 페이지 하단의 "아래는 CGI의 GET인자 테스트"의 링크를 클릭하는 경우
아래와 같이 나옵니다. 이 때 IE의 출력 인코딩은 EUC-KR.
IE의 출력인코딩을 UTF-8로 바꾸면 새로고침을 해서 출력이 나오는데...
어째서 "유니코드논의/파일명인코딩"이라고 나오지 않고 "??니코드??의/??일명인코딩"이라고 나오는 걸까요???? "유","논","파"라는 글자 자체의 문제는 아닙니다. 링크를 살짝 바꿔서 "파일명파인코딩"으로 바꿔보면 중간의 파는 또 제대로 나오거든요. (대신 이번에는 또 다른 글자가 깨짐)
뭐 좋습니다, 어쨌거나 앞의 테스트로 미루어 보건데 이번에도 링크의 URL이 UTF-8로 넘어갔기 때문이라고 치고...
2) http://gypark.pe.kr/encoding/euckr.html 페이지 하단의 링크를 클릭하는 경우
이번에는 html 파일이 EUC-KR로 인코딩되어 있는 것이니, 그 안의 링크는 IE의 옵션에 따라 되다가 말았다가 해야 하지 않겠습니까? 그런데, IE의 옵션에 관계없이 항상 됩니다. 항상 UTF-8로 보낸다는 옵션이 켜져 있을 때도 됩니다.
-_-;;; 어째서 되는 거야?
3) IE 주소 표시줄에 직접 "http://gypark.pe.kr/cgi-bin/wiki/wiki.pl?유니코드논의/파일명인코딩"을 입력하는 경우
마찬가지로, IE옵션이 켜져 있어도 잘 됩니다.
이 때의 "된다/안 된다"는 앞의 텍스트 파일 불러오기와는 상황이 달라서, wiki.pl은 무조건 실행이 됩니다. 따라서 "웹서버의 반응을 보고 IE가 인코딩을 바꿔서 요청을 다시 한다"는 가설은 세울 수 없습니다. mod_url이 관여하는지는 확인을 하지 못했지만, 따로 CheckURL 옵션을 켜 주지도 않았으니 안 하리라고 생각됩니다. (사실 그 부분은 자신이 없음. 게다가 mod_url이 동작할 때 로그를 남기게 하려면 재컴파일해야 하는 것 같아서 손을 못 댑니다) 그렇다면 결국 애초에 요청을 보낼 때부터 2)와 3)은 무조건 EUC-KR 형태로 보냈다는 이야기?? 그럼 텍스트 파일의 경우와 왜 다르게 동작하는 걸까요? 혹시 URL에 "?"가 포함된 경우는 반대로 무조건 EUC-KR로 보내도록 되어 있음?
firefox에서도 나름의 설정이 있겠지만, 기본적으로는 "웹페이지(A라고 합시다)에서 링크를 클릭하는 경우는 A의 인코딩과 동일한 인코딩을 거쳐 URL을 보낸다"로 동작하는 것 같습니다. txt파일 불러오기를 가지고 테스트해보니 그렇네요. 주소 입력창에 직접 입력하는 경우는.... 확인하지 못했습니다. (리눅스에 X윈도우에 한글 입력기가 없어서 -_-;;)
그리고 위키의 한글 페이지 얘기인데... 정확히 예상했던 것처럼 동작했습니다.
즉, EUC-KR로 인코딩된 http://gypark.pe.kr/encoding/euckr.html 에서 위키페이지 링크를 클릭하면 제대로 뜨고, UTF-8로 인코딩된 http://gypark.pe.kr/encoding/utf8.html 에서 링크를 클릭하니 잘못된 페이지 이름이라고 나옵니다. 이 때 오류화면을 출력 인코딩을 UTF-8로 바꿔서 다시 불러와 보니 정확히 페이지 이름이 원래의 "유니코드논의/파일명인코딩"으로 나옵니다. (IE에서는 중간중간에 "??"로 깨졌었지요) 이 때 위키 쪽에서 id부분을 EUC-KR 인코딩으로 바꿔줘서 처리하게 했더니 정확히 해당 페이지를 출력하는 것을 확인했습니다.
여기까지 테스트한 결론은,
URL에 "?"가 들어가서 CGI 스크립트에 파라메터를 GET 메쏘드로 넘기는 경우에, IE는
UTF-8이 아닌 웹페이지 내에서 그 URL 링크를 클릭하면 => "URL을 UTF-8로 보냄" 옵션에 관계없이 EUC-KR로 보낸다. (-_-;)
주소 표시줄에 직접 입력해도 => 역시 옵션에 관계없이 EUC-KR로 보낸다. (-_-;;;;)
UTF-8인 웹페이지 내에서 그 URL 링크를 클릭하면 => 그때만 UTF-8로 보낸다... 근데, 그나마도 제대로 못 보내고 뭔가 문제가 있게 보낸다. (-_-;;;;;;;)
OTL
이러면 이 유즈모드ext 버전을 아무리 UTF-8 기반으로 바꿔도 소용없습니다. 어쨌거나 IE에서는 제대로 못 봅니다. EUC-KR 기반일 때는 "UTF-8인 웹페이지에서 클릭했을때만" 문제가 되지만, UTF-8 기반이 되면, 페이지 주소 형식이 "wiki.pl?페이지이름"인 이상은 제대로 보지 못할 겁니다.
어째서 OddMuse나 위키페디아를 들여다볼때는 이 문제를 몰랐나 했더니만,
두 곳 다 페이지 URL에 물음표가 아닌 슬래쉬로 스크립트 이름과 페이지 이름을 구분하고 있으며
위키페디아의 경우는 내부에서 링크를 걸 때는 %-인코딩한 형태로 제공을 하고 있고
저는 저대로 IE의 UTF-8로 보냄 옵션을 켠 채로 살아왔기 때문에
절묘하게 저런 문제를 마주치지 못하고 살아왔던 것입니다.
http://ko.wikipedia.org/wiki/위키 <- 이 주소를 IE의 주소 표시줄의 복사하거나, 그냥 이 페이지에서 클릭해보세요. IE옵션이 "켜져 있을 때만" 제대로 될 겁니다. (거의 모든 국내 웹 게시판이나 사이트 등에서 "옵션을 끄세요"라고 권하는데 말이죠1) <- 현재는 이 gyparkwiki가 UTF-8로 운영되고 있기 때문에, 저 링크를 클릭하면 무조건 UTF-8로 요청이 날아가서 제대로 페이지가 보입니다
1) 어째 페이지 제목은 "파일명인코딩"인데 내용은 IE의 URL전달 버그에 관한 얘기가 됐다.
2) IE가 바뀔 리 없으니 위키 쪽에서 "?"가 아니라 "/"를 쓰도록 바꿔야겠다. 근데 반나절 해보니까 난관이 많아 보임.
3) 일단 firefox 등에서 UTF-8로 주소를 보내는 경우만이라도 처리할 수 있도록 해 볼까나.
본문 첫 섹션에 했던 테스트를 Firefox 로도 해보자.
다만, Firefox는 멀티바이트 문자를 주소창에 넣고 엔터를 치는 순간 %-인코딩을 해버린다. 아마 인코딩을 한 후 요청을 보내는 것 같음. 그렇지만 실험에는 상관없을 듯. (인코딩하지 않게 하는 건 network.standard-url.escape-utf8 옵션)
1) 주소 입력창에 직접 입력할 때
홈페이지의 encoding을 utf-8로 바꾸려고 보니, 여러가지가 걸리네요. 정리해 놓으신 자료 잘 보고 있습니다. 이참에 wikiX를 다른걸로 바꿀까 하는 생각도 있고 한데 결국은 한글 페이지명이 문제가 되네요.
http://ko.wikipedia.org/wiki/위키 <- 이 주소를 IE의 주소 표시줄의 복사하거나, 그냥 이 페이지에서 클릭해보세요. IE옵션이 "켜져 있을 때만" 제대로 될 겁니다. (거의 모든 국내 웹 게시판이나 사이트 등에서 "옵션을 끄세요"라고 권하는데 말이죠) -> 저는 꺼져있을 때도 제대로 되길래 이상하네 생각을 했더니만, 이 site가 encoding이 바뀌기 전에는 안되었다는 말이었군요.
-- jmjeong 2007-5-26 7:18 pm
아 네 맞습니다. gyparkwiki가 euc-kr을 쓰는 상태에서 작성한 페이지이다보니... 지금은 utf-8이니까 저 링크를 클릭하면 옵션에 관계없이 utf-8로 보내지기 때문에 괜찮죠.
http://ko.wikipedia.org/wiki/위키 <- 이 주소를 IE의 주소 표시줄의 복사하거나, 그냥 이 페이지에서 클릭해보세요. IE옵션이 "켜져 있을 때만" 제대로 될 겁니다. (거의 모든 국내 웹 게시판이나 사이트 등에서 "옵션을 끄세요"라고 권하는데 말이죠) -> 저는 꺼져있을 때도 제대로 되길래 이상하네 생각을 했더니만, 이 site가 encoding이 바뀌기 전에는 안되었다는 말이었군요.