유니코드논의/파일명인코딩 : GyparkWiki

"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를 해보면 다음과 같이 확인할 수 있습니다.

Upload:putty_euckr.png
(LANG=ko_KR.EUCKR (서버기본값), PuTTY 문자셋 설정 CP949)

Upload:putty_utf-8.png
(LANG=ko_KR.UTF-8, PuTTY 문자셋 설정 UTF-8)

결국 서버의 파일 시스템의 설정 같은 건 고려할 필요 없이 파일명은 그저 문자코드 그대로 정해지나 보네요. 이제서야 유니코드논의에 조희대님이 적어주셨던 답글을 제대로 체감했습니다 ^^;

아래 두 개는 CheckURL 옵션이 off로 설정된 디렉토리에 있습니다.

아래 두 개는 CheckURL 옵션이 on으로 설정된 디렉토리에 있습니다.

테스트는 IE에서 위 4개의 링크를 각각 클릭했을 때와, 주소 표시줄에 직접 복사해서 엔터를 쳐서 불러올 때 동일한 결과를 냈습니다 (다만, 지금 보는 이 페이지가 EUC-KR 인코딩된 출력이라서, 링크를 클릭했을 경우에는 무조건 EUC-KR로 전송되고 있는 것이 아닌가 싶기도 합니다만... 결과가 동일한 걸 보니 그도 아닌 듯):

_	___________ IE옵션 켬 ___________	___________ IE옵션 끔 ___________	비고
CheckURL off	(1) e이유씨 (X) u유티에프8 (O)	(2) e이유씨 (O) u유티에프8 (X)	_
CheckURL on	(3) e이유씨 (O) u유티에프8 (O)	(4) e이유씨 (O) u유티에프8 (X*)	X* : URL을 "http://gypark.pe.kr/checkurl_on/u"로 취급하여 404

결과의 첫번째 줄 (1)과 (2)를 보면, IE의 옵션이 켜졌을 때는 UTF-8 파일명만 제대로 보이고, 꺼졌을 때는 반대로 EUC-KR 파일명만 제대로 보입니다. 지난 몇 년 간 서버는 주로 기존의 EUC-KR 인코딩을 써서 파일을 저장했을 터라, "그림이 X박스로 나와요" "파일 다운로드가 안 돼요" 등의 질문에 대한 답은 "URL을... 옵션을 끄세요"였던 거죠.

이 문제를 해결하는 방법 중 하나가 아파치 웹 서버에 별도 모듈로 들어가는 mod_url인데, .htacess 파일에 다음과 같이 넣으면 동작합니다.

이 경우, 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에만 기대기도 힘든 상황인 듯. 관련 링크는 창을 닫아버려서 다시 찾기 귀찮은고로 생략)

위 테스트에서는, "웹 페이지에서 4개의 링크를 각각 클리하는 경우와, 주소 표시줄에 4개의 주소를 각각 입력한 경우 결과가 동일"하다고 했습니다. 혹시나 싶어서 4개의 링크를 담고 있는 별도의 웹페이지(http://gypark.pe.kr/encoding/euckr.html)를 만들어서 해봐도 그렇습니다.

그런데, "내용이 UTF-8로 인코딩된 웹페이지에 있는 링크를 클릭하는 경우"는 뭔가 좀 다릅니다. http://gypark.pe.kr/encoding/utf8.html 에서 4개의 링크를 각각 클릭해보면:

_	___________ IE옵션 켬 ___________	___________ IE옵션 끔 ___________	비고
CheckURL off	(1) e이유씨 (X) u유티에프8 (O)	(2) e이유씨 (X) u유티에프8 (O)	(2)의 결과가 위와 다르다. (1)과 같은 결과
CheckURL on	(3) e이유씨 (O) u유티에프8 (O)	(4) e이유씨 (O) u유티에프8 (O)	(4)의 결과가 위와 다르다. (3)과 같은 결과

즉, IE의 옵션을 꺼도, 켰을 때와 동일한 결과가 나오고 있습니다.

2. wiki.pl? 뒤에 붙는 인자의 경우는??

IE의 출력인코딩을 UTF-8로 바꾸면 새로고침을 해서 출력이 나오는데...

어째서 "유니코드논의/파일명인코딩"이라고 나오지 않고 "??니코드??의/??일명인코딩"이라고 나오는 걸까요???? "유","논","파"라는 글자 자체의 문제는 아닙니다. 링크를 살짝 바꿔서 "파일명파인코딩"으로 바꿔보면 중간의 파는 또 제대로 나오거든요. (대신 이번에는 또 다른 글자가 깨짐)

뭐 좋습니다, 어쨌거나 앞의 테스트로 미루어 보건데 이번에도 링크의 URL이 UTF-8로 넘어갔기 때문이라고 치고...

이번에는 html 파일이 EUC-KR로 인코딩되어 있는 것이니, 그 안의 링크는 IE의 옵션에 따라 되다가 말았다가 해야 하지 않겠습니까? 그런데, IE의 옵션에 관계없이 항상 됩니다. 항상 UTF-8로 보낸다는 옵션이 켜져 있을 때도 됩니다.

이 때의 "된다/안 된다"는 앞의 텍스트 파일 불러오기와는 상황이 달라서, wiki.pl은 무조건 실행이 됩니다. 따라서 "웹서버의 반응을 보고 IE가 인코딩을 바꿔서 요청을 다시 한다"는 가설은 세울 수 없습니다. mod_url이 관여하는지는 확인을 하지 못했지만, 따로 CheckURL 옵션을 켜 주지도 않았으니 안 하리라고 생각됩니다. (사실 그 부분은 자신이 없음. 게다가 mod_url이 동작할 때 로그를 남기게 하려면 재컴파일해야 하는 것 같아서 손을 못 댑니다) 그렇다면 결국 애초에 요청을 보낼 때부터 2)와 3)은 무조건 EUC-KR 형태로 보냈다는 이야기?? 그럼 텍스트 파일의 경우와 왜 다르게 동작하는 걸까요? 혹시 URL에 "?"가 포함된 경우는 반대로 무조건 EUC-KR로 보내도록 되어 있음?

3. Firefox 에서 해보니...

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는

이러면 이 유즈모드ext 버전을 아무리 UTF-8 기반으로 바꿔도 소용없습니다. 어쨌거나 IE에서는 제대로 못 봅니다. EUC-KR 기반일 때는 "UTF-8인 웹페이지에서 클릭했을때만" 문제가 되지만, UTF-8 기반이 되면, 페이지 주소 형식이 "wiki.pl?페이지이름"인 이상은 제대로 보지 못할 겁니다.

어째서 OddMuse나 위키페디아를 들여다볼때는 이 문제를 몰랐나 했더니만,

http://ko.wikipedia.org/wiki/위키 <- 이 주소를 IE의 주소 표시줄의 복사하거나, 그냥 이 페이지에서 클릭해보세요. IE옵션이 "켜져 있을 때만" 제대로 될 겁니다. (거의 모든 국내 웹 게시판이나 사이트 등에서 "옵션을 끄세요"라고 권하는데 말이죠1) <- 현재는 이 gyparkwiki가 UTF-8로 운영되고 있기 때문에, 저 링크를 클릭하면 무조건 UTF-8로 요청이 날아가서 제대로 페이지가 보입니다

4. 간단한 스크립트를 사용하여 다시 테스트

#!/usr/bin/perl
use CGI;
use Encode;

$q = new CGI;

print $q->header(-type=>"text/html; charset=EUC-KR");
print <<EOF;
<HTML >
<HEAD>
<TITLE>간단한 스크립트</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=euc-kr">
</HEAD>

<BODY>
EOF

$id = $q->param('keywords');

print "<p>GET으로 넘어온 원래 인자: [$id]<br>\n";

$newid = Encode::encode('EUC-KR', Encode::decode('UTF-8', $id));

print "<p>이 인자가 UTF-8 인코딩되어 있다고 가정하고 EUC-KR 로 변환한 스트링: [$newid]<br>\n";

print <<EOF;
</BODY>
</HTML >
EOF

두 브라우저에서 링크를 클릭하는 순간에 apache의 access 로그:

5. 이왕 웹서버 로그를 들여다 본김에

"안녕하세요"라는 문자열에 대해서 IE가 어떻게 요청을 하는지 아파치 로그를 보겠습니다.

[KLDP BBS]에 물어보니, 버그 맞답니다 -_-;;;; 아 정말 이것 때문에 만 이틀을 삽질을...

6. 결론은...

1) 어째 페이지 제목은 "파일명인코딩"인데 내용은 IE의 URL전달 버그에 관한 얘기가 됐다.

2) IE가 바뀔 리 없으니 위키 쪽에서 "?"가 아니라 "/"를 쓰도록 바꿔야겠다. 근데 반나절 해보니까 난관이 많아 보임.

3) 일단 firefox 등에서 UTF-8로 주소를 보내는 경우만이라도 처리할 수 있도록 해 볼까나.

7. 부록: Firefox 에서 파일명에 한글이 들어간 URL에 관해 테스트

다만, Firefox는 멀티바이트 문자를 주소창에 넣고 엔터를 치는 순간 %-인코딩을 해버린다. 아마 인코딩을 한 후 요청을 보내는 것 같음. 그렇지만 실험에는 상관없을 듯. (인코딩하지 않게 하는 건 network.standard-url.escape-utf8 옵션)

_	network.standard-url.encode-utf8 = true	network.standard-url.encode-utf8 = false (기본값)	비고
CheckURL off	(1) e이유씨 (X) u유티에프8 (O)	(2) e이유씨 (O) u유티에프8 (X)	_
CheckURL on	(3) e이유씨 (O) u유티에프8 (O)	(4) e이유씨 (O) u유티에프8 (X)	_

_	network.standard-url.encode-utf8 = true	network.standard-url.encode-utf8 = false (기본값)	비고
CheckURL off	(1) e이유씨 (X) u유티에프8 (O)	(2) e이유씨 (O) u유티에프8 (X)	_
CheckURL on	(3) e이유씨 (O) u유티에프8 (O)	(4) e이유씨 (O) u유티에프8 (X)	_

3) UTF-8인코딩된 페이지에서 링크를 클릭하는 경우

_	network.standard-url.encode-utf8 = true	network.standard-url.encode-utf8 = false (기본값)	비고
CheckURL off	(1) e이유씨 (X) u유티에프8 (O)	(2) e이유씨 (X) u유티에프8 (O)	_
CheckURL on	(3) e이유씨 (O) u유티에프8 (O)	(4) e이유씨 (O) u유티에프8 (O)	_

8. 기타 & 의견란

IE는 자바스크립트를 사용하여 URL을 새 창으로 띄울 때도 문제를 일으킨다. UTF-8시퀀스에 맞춰 %-인코딩된 URL을 띄울 때 이상하게 변한한다. 티스토리의받은트랙백링크출력문제 참조.

-- Raymundo 2007-3-8 9:56 pm

홈페이지의 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로 보내지기 때문에 괜찮죠.
-- Raymundo 2007-5-26 8:33 pm

각주:
1. 몇 년 전 얘기이지만 요즘도 그 여파는 남아 있는 걸로 압니다. 당장 검색 엔진에서 저 옵션 이름을 넣어보면 네이버 지식인 같은 데서는 끄라는 얘기밖에 안 나옵니다. 그것은 단지 미봉책이며 옳지 않다라는 주장은 개발자들 사이에서나 볼 수 있죠.

유니코드논의/파일명인코딩

1. 파일명이 euc-kr과 utf-8로 인코딩된 두 개의 웹페이지 파일이 다음 조건에 대해 각각 어떻게 동작하는가 봅시다.