34 번째 수정본 소스 보기 : 유니코드논의/파일명인코딩

내용출력
로그인[l]
수정할 수 없습니다: 유니코드논의/파일명인코딩 는 읽기 전용 페이지입니다.
== # 파일명이 euc-kr과 utf-8로 인코딩된 두 개의 웹페이지 파일이 다음 조건에 대해 각각 어떻게 동작하는가 봅시다. ==
(이하의 내용에서 "IE"는 "Internet Explorer 6.0.2900.2180.xpsp_sp2_gdr.050301-1519"입니다)

* IE의 옵션 "URL을 항상 UTF-8로 보냄"의 on/off 여부
* 서버의 .htaccess 파일에서 "CheckURL" 옵션의 on/off 여부

"e이유씨.txt"는 '''파일명이''' euc-kr로 인코딩되어 저장되어 있고, "u유티에프8.txt"은 utf-8로 인코딩되어 저장되어 있습니다. 파일의 내용도 마찬가지로 서로 다른 인코딩으로 저장되어 있어서, 두 파일 중 한 쪽이 잘 보인다면 다른 한쪽의 내용은 깨져서 나올 것입니다만, 그건 브라우저의 보기->인코딩 메뉴에 가셔서 "한국어"와 "유니코드(UTF-8)"을 바꿔보시면 잘 나올 겁니다. 여기서 눈여겨 볼 것은 내용이 아니라 "파일 자체를 찾을 수 있는지, 아니면 404 Not Found 에러가 나는지" 여부입니다.

<div class="quote">
'''참고로, 두 파일은 다음과 같이 생성하였습니다.'''
서버의 기본 세팅이 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)

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

아래 두 개는 CheckURL 옵션이 off로 설정된 디렉토리에 있습니다.
* http://gypark.pe.kr/checkurl_off/e이유씨.txt
* http://gypark.pe.kr/checkurl_off/u유티에프8.txt

아래 두 개는 CheckURL 옵션이 on으로 설정된 디렉토리에 있습니다.
* http://gypark.pe.kr/checkurl_on/e이유씨.txt
* http://gypark.pe.kr/checkurl_on/u유티에프8.txt

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

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

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

이 문제를 해결하는 방법 중 하나가 아파치 웹 서버에 별도 모듈로 들어가는 mod_url인데, .htacess 파일에 다음과 같이 넣으면 동작합니다.
{{{#!vim apache
<IfModule mod_url.c>
CheckURL on
</IfModule>
}}}

이 경우, URL을 넘겨 받았는데 그 URL에 해당하는 파일이 없을 경우, URL이 UTF-8로 인코딩된 것이라고 간주하고, EUC-KR로 인코딩해서 처리한다고 합니다. 따라서 위 결과표의 (3)의 경우는 두 파일 다 정상적으로 볼 수 있습니다.

문제는 (4)에서 UTF-8 파일명의 경우인데, URL은 EUC-KR로 날아오는데 파일이 UTF-8로 저장된 경우, 이번에는 반대로 변환해주어야 하는데 그러지를 못하고 제대로 처리되지 않습니다. 이 문제에 관해 언급한 [http://kldp.org/node/37849 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개의 링크를 각각 클릭해보면:

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

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

그러면, 
* '''웹페이지가 UTF-8로 인코딩되어 있을 때는, 그 안의 링크는 무조건 UTF-8로 보냄'''
* '''웹페이지가 UTF-8이 아닐 때는, 그 안의 링크는 IE의 옵션에 따라서 UTF-8로 보내거나, 웹페이지의 인코딩과 같은 형식으로 보냄''' - 웹페이지의 인코딩과 같은 형식일지 무조건 한글 윈도우즈에서는 EUC-KR일지 모르겠지만, 아무래도 전자가 맞겠죠. EUC-JP로 인코딩된 페이지의 링크를 EUC-KR로 보낸다는 것은 이상하니까
* '''주소 표시줄에 입력한 경우는, IE의 옵션에 따라서 UTF-8로 보내거나, 다른 인코딩(아마도 한글 윈도우즈라면 EUC-KR?)으로 보냄'''
정도로 생각하면 되지 않을까 합니다... 이걸 명확히 얘기하는 문서의 주소를 아시는 분은 알려 주시면 감사하겠습니다.

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

(이 걸 진짜 이해하지 못하겠습니다)

지금 보는 이 페이지를 IE로 불러와 봅시다.

'''1) http://gypark.pe.kr/encoding/utf8.html 페이지 하단의 "아래는 CGI의 GET인자 테스트"의 링크를 클릭하는 경우'''

아래와 같이 나옵니다. 이 때 IE의 출력 인코딩은 EUC-KR.

Upload:ie_case_1.png 

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

Upload:ie_case_2.png 

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

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

'''2) http://gypark.pe.kr/encoding/euckr.html 페이지 하단의 링크를 클릭하는 경우'''

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

<font color=red size=+4>-_-;;; 어째서 되는 거야?</font>

'''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 에서 해보니... ==

firefox에서도 나름의 설정이 있겠지만, 기본적으로는 "웹페이지(A라고 합시다)에서 링크를 클릭하는 경우는 A의 인코딩과 동일한 인코딩을 거쳐 URL을 보낸다"로 동작하는 것 같습니다. txt파일 불러오기를 가지고 테스트해보니 그렇네요. 주소 입력창에 직접 입력하는 경우는.... 확인하지 못했습니다. (리눅스에 X윈도우에 한글 입력기가 없어서 -_-;;)

<font color="red">
그리고 위키의 한글 페이지 얘기인데... '''정확히 예상했던 것처럼 동작'''했습니다.

즉, EUC-KR로 인코딩된 http://gypark.pe.kr/encoding/euckr.html 에서 위키페이지 링크를 클릭하면 제대로 뜨고, UTF-8로 인코딩된 http://gypark.pe.kr/encoding/utf8.html 에서 링크를 클릭하니 잘못된 페이지 이름이라고 나옵니다. 이 때 오류화면을 출력 인코딩을 UTF-8로 바꿔서 다시 불러와 보니 정확히 페이지 이름이 원래의 "유니코드논의/파일명인코딩"으로 나옵니다. (IE에서는 중간중간에 "??"로 깨졌었지요) 이 때 위키 쪽에서 id부분을 EUC-KR 인코딩으로 바꿔줘서 처리하게 했더니 정확히 해당 페이지를 출력하는 것을 확인했습니다.
</font>

여기까지 테스트한 결론은,

URL에 "?"가 들어가서 CGI 스크립트에 파라메터를 GET 메쏘드로 넘기는 경우에, IE는
* UTF-8이 아닌 웹페이지 내에서 그 URL 링크를 클릭하면 => "URL을 UTF-8로 보냄" 옵션에 관계없이 EUC-KR로 보낸다. (-_-;)
* 주소 표시줄에 직접 입력해도 => 역시 옵션에 관계없이 EUC-KR로 보낸다. (-_-;;;;)
* UTF-8인 웹페이지 내에서 그 URL 링크를 클릭하면 => 그때만 UTF-8로 보낸다... 근데, 그나마도 제대로 못 보내고 뭔가 문제가 있게 보낸다. (-_-;;;;;;;)

<font color=red size=+4>OTL</font>

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

어째서 OddMuse나 위키페디아를 들여다볼때는 이 문제를 몰랐나 했더니만, 
* 두 곳 다 페이지 URL에 물음표가 아닌 슬래쉬로 스크립트 이름과 페이지 이름을 구분하고 있으며
* 위키페디아의 경우는 내부에서 링크를 걸 때는 %-인코딩한 형태로 제공을 하고 있고
* 저는 저대로 IE의 UTF-8로 보냄 옵션을 켠 채로 살아왔기 때문에
절묘하게 저런 문제를 마주치지 못하고 살아왔던 것입니다. 

http://ko.wikipedia.org/wiki/위키 <- 이 주소를 IE의 주소 표시줄의 복사하거나, 그냥 이 페이지에서 클릭해보세요. IE옵션이 "켜져 있을 때만" 제대로 될 겁니다. (거의 모든 국내 웹 게시판이나 사이트 등에서 "옵션을 끄세요"라고 권하는데 말이죠<footnote(몇 년 전 얘기이지만 요즘도 그 여파는 남아 있는 걸로 압니다. 당장 검색 엔진에서 저 옵션 이름을 넣어보면 네이버 지식인 같은 데서는 끄라는 얘기밖에 안 나옵니다. 그것은 단지 미봉책이며 옳지 않다라는 주장은 개발자들 사이에서나 볼 수 있죠.)>) <color(red,<- 현재는 이 gyparkwiki가 UTF-8로 운영되고 있기 때문에, 저 링크를 클릭하면 무조건 UTF-8로 요청이 날아가서 제대로 페이지가 보입니다)>

== # 간단한 스크립트를 사용하여 다시 테스트 ==

http://gypark.pe.kr/encoding/u.html 페이지(UTF-8로 인코딩되어 있음)에 있는 링크를 클릭해서 http://gypark.pe.kr/cgi-bin/simple.pl?안녕하세요 스크립트를 불러오는 경우.

<memo(simple.pl 스크립트의 내용)>
{{{#!vim perl
#!/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
}}}
</memo>

Upload:mozilla_case.png \\
(Mozilla의 경우. 제대로 "안녕하세요"가 나옴)

Upload:ie_case_3.png \\
(IE의 경우, 역시 깨져 나옴)

두 브라우저에서 링크를 클릭하는 순간에 apache의 access 로그:
{{{
/cgi-bin/simple.pl??\x88\xeb\x85Wx95?\x98\xec\x84\xb8?             <-- IE
/cgi-bin/simple.pl?%EC%95%88%EB%85%95%ED%95%98%EC%84%B8%EC%9A%94   <-- Mozilla
}}}

돌아가시겠다...

== # 이왕 웹서버 로그를 들여다 본김에 ==

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

* 파일에 한글이 있는 경우 - http://gypark.pe.kr/encoding/안녕하세요.txt (이 파일은 서버에 파일명이 UTF-8로 저장되어 있기 때문에, IE옵션 끄신 분들은 404 에러 나올 겁니다.)
* CGI GET 파라메터에 한글이 있는 경우 - http://gypark.pe.kr/cgi-bin/simple.pl?안녕하세요 

{{{
http://gypark.pe.kr/encoding/안녕하세요.txt 

1) IE의 "URL을 UTF-8로 보내기" 옵션 켜고, 주소 표시줄에 입력
"GET /encoding/%EC%95%88%EB%85%95%ED%95%98%EC%84%B8%EC%9A%94.txt HTTP/1.1" 304 -    <-- UTF-8로 보냈다

2) IE 옵션 끄고, 주소 표시줄에 입력
"GET /encoding/\xbe\xc8\xb3\xe7\xc7\xcf\xbc\xbc\xbf\xe4.txt HTTP/1.1" 404 229       <-- EUC-KR로 보냈다
     <- 404 에러나는 건 당연한데, 이건 또 왜 %인코딩이 아니라 \x로 시작하는 코드가... -_-?

3) IE 옵션 켜고, EUC-KR 인코딩된 페이지에서 링크 클릭
"GET /encoding/%EC%95%88%EB%85%95%ED%95%98%EC%84%B8%EC%9A%94.txt HTTP/1.1" 304 -    <-- UTF-8로 보냈다

4) IE 옵션 끄고, EUC-KR 인코딩된 페이지에서 링크 클릭
"GET /encoding/\xbe\xc8\xb3\xe7\xc7\xcf\xbc\xbc\xbf\xe4.txt HTTP/1.1" 404 229       <-- EUC-KR로 보냈다

5) IE 옵션 켜고, UTF-8 인코딩된 페이지에서 링크 클릭
"GET /encoding/%EC%95%88%EB%85%95%ED%95%98%EC%84%B8%EC%9A%94.txt HTTP/1.1" 304 -    <-- UTF-8로 보냈다

6) IE 옵션 끄고, UTF-8 인코딩된 페이지에서 링크 클릭
"GET /encoding/%EC%95%88%EB%85%95%ED%95%98%EC%84%B8%EC%9A%94.txt HTTP/1.1" 304 -    <-- UTF-8로 보냈다!!!
     <- 고로, UTF-8 인코딩된 페이지의 링크는, IE 옵션에 관계없이 UTF-8로 보냄을 알 수 있다.


http://gypark.pe.kr/cgi-bin/simple.pl?안녕하세요 

1) IE의 "URL을 UTF-8로 보내기" 옵션 켜고, 주소 표시줄에 입력
"GET /cgi-bin/simple.pl?\xbe\xc8\xb3\xe7\xc7\xcf\xbc\xbc\xbf\xe4 HTTP/1.1" 200 292          <-- EUC-KR로 보냈다 -_-;

2) IE 옵션 끄고, 주소 표시줄에 입력
"GET /cgi-bin/simple.pl?\xbe\xc8\xb3\xe7\xc7\xcf\xbc\xbc\xbf\xe4 HTTP/1.1" 200 292          <-- EUC-KR로 보냈다

3) IE 옵션 켜고, EUC-KR 인코딩된 페이지에서 링크 클릭
"GET /cgi-bin/simple.pl?\xbe\xc8\xb3\xe7\xc7\xcf\xbc\xbc\xbf\xe4 HTTP/1.1" 200 292          <-- EUC-KR로 보냈다 -_-;

4) IE 옵션 끄고, EUC-KR 인코딩된 페이지에서 링크 클릭
"GET /cgi-bin/simple.pl?\xbe\xc8\xb3\xe7\xc7\xcf\xbc\xbc\xbf\xe4 HTTP/1.1" 200 292          <-- EUC-KR로 보냈다

5) IE 옵션 켜고, UTF-8 인코딩된 페이지에서 링크 클릭
"GET /cgi-bin/simple.pl??\x88\xeb\x85\x95?\x98\xec\x84\xb8? HTTP/1.1" 200 294               <-- UTF-8로 보냈고, 깨졌다 -_-;;;;

6) IE 옵션 끄고, UTF-8 인코딩된 페이지에서 링크 클릭
"GET /cgi-bin/simple.pl??\x88\xeb\x85\x95?\x98\xec\x84\xb8? HTTP/1.1" 200 294               <-- UTF-8로 보냈고, 깨졌다 -_-;;;;
     <-- 이게 바로 태터툴즈(UTF-8로 출력된다)에서 유즈모드로 링크를 건 것을 클릭했을때 문제가 되는 경우
         아무리 유즈모드 쪽에서 UTF-8 지원을 하려고 해도, 요청 자체가 깨져서 오면 처리할 수 없다.
}}}

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

같은 애기를 하고 있는 글들:
* [http://alogblog.com/alog/archives/2006/02/06_ms_ie_6_and_7_beta_2_encoding_bugs_in_urls_query_part/ MS IE 6 and 7 beta 2 encoding bugs in URL's query part] 현재 서버 에러가 난다. [http://72.14.235.104/search?q=cache:4sTXI326mHgJ:alogblog.com/alog/archives/2006/02/06_ms_ie_6_and_7_beta_2_encoding_bugs_in_urls_query_part/+internet+explorer+utf-8+url+%EB%B2%84%EA%B7%B8&hl=ko&ct=clnk&cd=1&gl=kr&inlang=ko 구글 캐쉬]

== # 결론은... ==

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

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

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

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

본문 첫 섹션에 했던 테스트를 Firefox 로도 해보자.

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

1) 주소 입력창에 직접 입력할 때

|| _ || network.standard-url.encode-utf8 = true || network.standard-url.encode-utf8 = false (기본값) || 비고 ||
|| CheckURL off || (1)<br>e이유씨 (X)<br>u유티에프8 (O) || (2)<br>e이유씨 (O)<br>u유티에프8 (X) || _ ||
|| CheckURL on || (3)<br>e이유씨 (O)<br>u유티에프8 (O) || (4)<br>e이유씨 (O)<br>u유티에프8 (X) || _ ||
: 이건 IE의 경우와 동일한 결과

2) EUC-KR인코딩된 페이지에서 링크를 클릭하는 경우

|| _ || network.standard-url.encode-utf8 = true || network.standard-url.encode-utf8 = false (기본값) || 비고 ||
|| CheckURL off || (1)<br>e이유씨 (X)<br>u유티에프8 (O) || (2)<br>e이유씨 (O)<br>u유티에프8 (X) || _ ||
|| CheckURL on || (3)<br>e이유씨 (O)<br>u유티에프8 (O) || (4)<br>e이유씨 (O)<br>u유티에프8 (X) || _ ||
: 1)하고도 같고, IE와도 동일

3) UTF-8인코딩된 페이지에서 링크를 클릭하는 경우
|| _ || network.standard-url.encode-utf8 = true || network.standard-url.encode-utf8 = false (기본값) || 비고 ||
|| CheckURL off || (1)<br>e이유씨 (X)<br>u유티에프8 (O) || (2)<br>e이유씨 (X)<br>u유티에프8 (O) || _ ||
|| CheckURL on || (3)<br>e이유씨 (O)<br>u유티에프8 (O) || (4)<br>e이유씨 (O)<br>u유티에프8 (O) || _ ||
: 흐음, IE와 마찬가지로, 이 경우는 옵션 설정에 관계없이 UTF-8로 보내는군요.


== # 기타 & 의견란 ==
<div class="comments">

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

홈페이지의 encoding을 utf-8로 바꾸려고 보니, 여러가지가 걸리네요. 정리해 놓으신 자료 잘 보고 있습니다. 이참에 wikiX를 다른걸로 바꿀까 하는 생각도 있고 한데 결국은 한글 페이지명이 문제가 되네요.  \\
 \\
http://ko.wikipedia.org/wiki/위키 <- 이 주소를 IE의 주소 표시줄의 복사하거나, 그냥 이 페이지에서 클릭해보세요. IE옵션이 "켜져 있을 때만" 제대로 될 겁니다. (거의 모든 국내 웹 게시판이나 사이트 등에서 "옵션을 끄세요"라고 권하는데 말이죠) -> 저는 꺼져있을 때도 제대로 되길래 이상하네 생각을 했더니만, 이 site가 encoding이 바뀌기 전에는 안되었다는 말이었군요. <mysign(jmjeong,2007-5-26 7:18 pm)>

: 아 네 맞습니다. gyparkwiki가 euc-kr을 쓰는 상태에서 작성한 페이지이다보니...  지금은 utf-8이니까 저 링크를 클릭하면 옵션에 관계없이 utf-8로 보내지기 때문에 괜찮죠. <mysign([[Raymundo]],2007-5-26 8:33 pm)>
<longcomments(100)>
----

</div>
----
[[기타분류]]
유니코드논의/파일명인코딩 페이지로 돌아가기 | 다른 수정본 보기