"URL을 항상 UTF-8로 보내기"에 관하여

RisaPapa의 이미지

현재 아파치에서 모든 언어의 URL을 인코딩하는 모듈을 작성하면서 이전에 한국에서 한국어 파일을 브라우저에서 읽지 못하면 "URL을 항상 UTF-8로 보내기" 에서 체크를 제거하면 된다는 글을 아주 많이 보았던 것이 생각이 납니다. 지금도 그런 말을 하는 사람이 있습니다. 이전부터 그런 글을 읽을 때마다 "그러면 안되는데...," 하고 생각하면서도 그냥 무심히 지나치곤 했습니다. 무심이라기 보다는 너무나 많은 사람들이 그런 말을 하기에 혼자서 떠들어서 무엇하나 하는 무기력감이었을 것입니다.

왜그런가는 아래의 주소로 접속을 해보시면 알 수가 있을 것입니다. 임시로 사용한 아이피라서 24시간이내에 차단될것입니다.
http://218.41.59.226/

그리고 WebDAV에서 여러 언어로 디렉토리나 파일이름이 사용가능하도록 하는 개발하면서 이러한 문제는 더욱더 실감을 하게됩니다. 서버에서는 서버인코딩이 이루어지고 클라이언트에서는 클라이어트별로 시스템과 직결된 다른 언어셋을 가지고 있기 때문에 더욱더 문제가 심각해 집니다.

기준을 정해야 되는데 현재로서는 서버쪽에서의 인코딩이 UTF-8로 이루어지고 클라이언트별로 지정을 해주는 것이 가장 쉬운 해결 방법이고 많은 개발자들에게는 정석으로 인식하고 있는 듯합니다. 경우에 따라서는 서버에서 EUC로 처리하는 방법도 있습니다. 그리고 클라이언트(User-Agent)와 언어권의 인코딩을 지정해주면 파일이름등을 그 나라의 언어로 사용할 수가 있습니다. 이방법으로 현재 일본어에서는 아무 문제가 없이 잘 작동이 되고 있습니다.

그런데 WebDAV라는 것이 HTTP의 확장 인터페이스이기 때문에 위에서의 클라이언트에서 서버에 요청하는 URL등에도 영향을 미치게됩니다. "URL을 항상 UTF-8로 보내기"라는 것이 기본으로 설정이 되어 있는 그 나름대로 의미가 있습니다. 아마 이곳에 체크가 되어 있지 않으면 위의 주소로 접속을 해서 테스트를 하면 문제가 발생할 것입니다. 다시 말해 클라이언트에서도 기준이 있어야 하는데 그것이 현재로서는 UTF-8라고 생각됩니다.

지금까지 서버쪽의 디렉토리나 파일이름의 인코딩을 UTF-8로 처리하고 있는 사이트는 별로 보지 못했습니다. 그러다보니 가장 쉽게 처리할 수가 있는 방법이 "URL을 항상 UTF-8로 보내기"에서 체크를 해제해 주세요라는 간단한 방법을 안일하게 마구 사용해 온 것이라고 생각이 됩니다. 그것도 개발자들이 그런 말을 되풀이 해 왔습니다.

저의 경우에는 시스템쪽을 많이 개발하다보니 스탠다드(기준)라는 것과 미래의 기술방향을 생각하면서 한번 개발을 하면 10년이상을 사용할 수 있도록 많이 고민하면서 개발을 합니다. 설계하고 생각하는 것이 95퍼센트를 차지할정도로 자료도 많이 참고하고 아파치와 같은 세계적으로 사용하는 것도 많고 하다보니 여러 나라의 사용자들의 생각이나 현재의 상황등을 세밀히 조사를 합니다. 개발자로서의 책임을 다하는 것 뿐이라고 생각하지만 주변을 보면 그렇지 않은 개발자가 더 많다는 생각을 하고 합니다.

이전에 톰켓의 4.1.28 버전에선가 한 개발지의 실수에 의해서 코요테 소스에서 기본 문자셋을 iso-8859-1로 정해서 다른 언어에서 문자가 께어지는 문제가 발생해서 아주 많은 항의로 인해 책임감때문에 그 개발자가 잠시 개발에서 손을 떼었던 적이 있습니다. 이러하듯이 문자셋에 관해 아무 지식이 없이 이렇게 하라는 것은 많은 사용자들에게 문제를 안겨 줄 수가 있다는 것을 항상 인식하면서 개발에 임하고 어드바이스를 해야 된다고 생각합니다.

URL을 항상 UTF-8로 보내기에 대한 개발자분들의 의견을 듣고 싶습니다.

그리고 WebDAV에서 한국어 인코딩 테스트를 하고 싶은데 아래의 주소를 네트웍에 추가해서 한글이름 파일을 작성하고 지우고 하는 테스트를 의뢰하고 싶습니다. 결과는 이곳에 보고드리겠습니다. 네트웍에 추가하기해서 아래의 주소를 입력하고 인증창에서는 아래의 사용자와 패스워드를 사용하면 됩니다.

[WebDAV]
http://218.41.59.226/test
user: user
pass: test

File attachments: 
첨부파일 크기
파일 mod_url.c8.9 KB
hardline의 이미지

익스플로어의 '웹폴더로 열기'로 로그인이 잘 안되어 이클립스의 WebDav 클라이언트 기능으로 테스트해봤습니다만 한글 일본어 다 잘되네요.

요즘 자바의 SJIS와 MS932사이에서 고생 좀 해서 기종의존문자를 넣어봤는데 잘 되네요. 한글의 EUCKR외의 '햏' 같은 MS949영역에 있는 글자를 넣어도 잘되고요.
윈도우 서버라서 그런가요?

WebDav는 Tomcat이나 Resin의 WebDav 서블릿이나, 아파치의 mod_dav세팅해서 써보기만 했지 프로토콜에 대해서 자세히 모르겠습니다만
저는 자바쪽 일을 하다 보니 가능하면 web page는 utf-8 URL에 일본어나 한국어가 들어갈 일이 있으면 URLEncoding해서 처리합니다만.
보통 유닉스 서버쪽이 euc-jp 클라이언트가 shift_jis이다 보니까 아파치쪽에서는 좀 애를 먹었습니다.

다른분들의 해법이 있으면 듣고 싶습니다.

byung82의 이미지

항상 UTF-8로 보내기로 하여도 UrlEncoding만 되어 있다면 2바이트 문자열의 표기 는 전혀 문제가 되지 않습니다.

지금 전 아파치는 아니지만 IIS6.0 ASP.NET으로 작업을 하고 있는데.

ASP.NET의 기본엔코딩이 UTF-8입니다. 이럴때 쿼리 문자열에 2바이트 문자열이 끼어 있으면 무저건 에러가 나더군요 ..

이럴 경우는 2바이트 문자열을 UrlEncoding을 해주면 문제 해결이 됩니다.

그럼 ~~;

perky의 이미지

+1입니다.

저도 어디 가서 윈도우 컴퓨터를 보면 꼭 "URL을 항상 UTF-8로 보내기"를 켜놓고 옵니다.
당연히 서버 측의 버그인데, 사용자 잘못인냥 잘못된 옵션을 강요하는 사이트들은 따끔히 혼내 줘야 합니다.

You need Python

RisaPapa의 이미지

인코딩 테스트와 대처 방법에 대해서 결과를 말씀드리겠습니다.

WebDAV에서 윈2000은 기본적으로 포함된 웹폴더기능으로 여러 언어를 동시에 사용하기가 불가능하다고 판단되었습니다. 웹폴더에서 서버에 파일을 작성할경우에는 UTF-8코드가 아닌 시스템의 코드를 그대로 보내고 있기때문입니다. 그리고 서버쪽에서는 기본 인코딩이 UTF-8로 설정된 경우에도 기본 시스템의 언어(local_charset)에 준해서 UTF-8코드로 변환하기 때문에 인코딩된 결과는 다르게 되어버립니다. WebDAV에서 윈2000의 WebDAV클라이언트명은 "Microsoft Data Access Internet Publishing Provider DAV 1.1"입니다. "Microsoft-WebDAV-MiniRedir/5.1.2600"은 XP인것 같은데 이것은 UTF-8로 문자열을 인코딩해서 서버에 송신하기 때문에 문제가 없는 것같습니다. 다시말해서 서버측에 UTF-8로 보내는 클라이언트와 서버가 윈2000인경우 그리고 서버가 리눅스라고 하더라도 인코딩을 서버측에서 UTF-8로 설정만하면 WebDAV에서 멀티랭귀지 환경을 구축할 수가 있습니다.

그렇지 않으면 서버쪽에서 한국어 일본어 중국어 등의 언어 판별 시스템이 필요하다는 결론입니다. 사실 언어 코드의 판별은 아주 까다로운 부분인데 이것에 대한 것은 이미 와세다 대학에서 국가 프로젝트로해서 개발해 상용화한 선례가 있습니다. 그 기본은 언어별로 단어사전을 미리 준비해 먼저 입력된 코드를 조사하고 그 코드가 포함된 언어별 단어 사전을 조사해 매치된 단어가 사전에 등록이 되어 있는지 체크하여 입력된 코드의 언어를 판별합니다. 이 방법이 가장 정확하게 언어를 판별할 수 있는 방법입니다. 혼자서 작성하기에는 너무나 방대한 작업량이라서 이런 것은 ICONV와 함께 공개 프로젝트로 진행하는 것이 바람직한 개발이라고 생각되어 집니다.

서버와 클라이언트가 동시에 같은 언어를 사용하는 운영시스템에서는 아무 문제가 없는데 한국어나 일본어의 운영시스템을 사용할 경우에는 언어판별 시스템이 필요하다보니 UTF-8로 문자를 변환해서 송신하는 클라이언트 개발이 필수적으로 이루어져야하고 이 기준이 디폴트로 지정이 되어야만 원할한 다국어 지원이 가능하리라고 생각됩니다. 그러면 서버쪽의 인코딩이 UTF-8로만 설정이 되어도 간단히 해결되게 됩니다. 그리고 WeBDAV에서 작성한 파일이름이나 디렉토리이름도 "URL을 항상 UTF-8로 보내기"에 체크만 되어 있다면 웹상에서 다국어의 인코딩문제는 아무 문제없이 해결이 되는 방안이라고 생각되어 집니다.

그러나 아직까지 UTF-8 역시 여러 문제점을 가지고 있고 나라별로 지정된 기본코드가 있는 상황하에서 서버에서 다국어 인코딩을 지원하는 시스템을 구성하려면 역시 언어판별시스템이 필수라는 결론입니다. 서버와 클라이어트가 같은 언어일 경우에는 간단히 해결되는 문제입다만...,

테스트해주신 분께 감사드리면 6,7월경에 오픈소스로 구성된 윈도우 서버 팩키지를 공개하고자 합니다. 이미 5년정도 틈틈히 이 개발과 패치를 개인적으로 해왔기 때문에 어느 정도 안정성에 대해서는 자신합니다.

sh.의 이미지

해당 옵션을 기본값으로 두고서 서버측에서 해결할 수 있는 방법은 어떤것이 있는지 소개해주시면 감사하겠습니다. 얼른 검색을 해보니 mod_url 을 적용하는 방법이 있는것 같은데 또 다른 방법이 있는지요?

제가 근무하는 회사에서는 50여대의 서버를 apache - php 로 운영중인데, 한글로된 이미지가 나오지 않거나 다운로드가 되지 않는다는 문의가 종종 들어옵니다. 그럴때 궁색하게 :oops: 옵션을 해제하시라는 답변을 하기도 좀 민망하구요...

offree의 이미지

apache 관련은 우선 저도 찾아 보고 있는데..

아래 관련 쓰레드 에는 명확한 답은 없네요.

http://bbs.kldp.org/viewtopic.php?t=24289&start=0&postdays=0&postorder=asc&highlight=utf-8+apache

아래 관련 글은 잘못된 정보 같기도 하구요.

http://bbs.kldp.org/viewtopic.php?t=8600&start=0&postdays=0&postorder=asc&highlight=utf-8+apache

그외 관련
(mod_url)
http://kltp.kldp.org/stories.php?story=01/01/29/5413242
http://tunelinux.pe.kr/wikix/index.php?diff=Web

(iconv)
http://www.kr.freebsd.org/ml/questions/2000/11/msg00268.shtml

libiconv 는 깔아줘야 되는 군요.

이부분에 대해서는 별로 신경을 안쓰시는 것인지..

이부분은 apache 에 관한 부분 이지만, 다른 관련 되는 것들도 이런식으로
처리를 해주어야 하나 봅니다.

ps. mod_url 관련 자료를 찾다가 이런경우도 있구나 했습니다.
관련 자료가 모두가 http://kle.kldp.org/apache/mod_url.c 이렇게 연결이 되어 있는데.. kle 이 죽었나 봅니다.

mod_url.c 에 대한 설명만 있고, 정작 mod_url.c 은 없는일이 ..

결국에는 이곳저곳 찾다가 oops.org 에서 srpm 에서 추출했네요. ^^

혹! 찾아 헤매고 계시는 분이 있을 지 모르니..

ps2. 우선 적용해서 확인해 보니, URL을 항상 UTF-8로 보냄
으로 하고 한글파일을 확인해 보니 정상작동 하네요.

ps3. 서버에 한글로 된 파일은 거의 안쓰다보니 신경을 쓰지 않았는데. 서버에서
처리를 해주는 것이 좋겠네요.

댓글 첨부 파일: 
첨부파일 크기
파일 0바이트

사용자가 바꾸어 나가자!!

= about me =
http://wiki.kldp.org/wiki.php/offree , DeVlog , google talk : offree at gmail.com

랜덤여신의 이미지

저도 얼마 전까지 IE 의 '항상 UTF-8 로 보냄' 옵션을 잘못된 것으로 생각하고 짜증을 내곤 했습니다.

그런데 요즘 UTF-8 을 배우면서 이 옵션이 정상적인 것이라는 것을 알게 되었습니다.

지금까지 괜히 IE 를 욕한 것이 미안해 지더군요. 8)

gyumee의 이미지

얼마전에 W3C의 문서를 보다가 찾았었는데요. URL을 UTF-8로 보내는 것이 표준인 것 같더라구요. 그렇다면 apache쪽이 표준을 구현하지 않은 것이 되겠죠.
mod_url을 살려서 사람들이 사용하도록 하는게 필요할 것 같네요.

offree의 이미지

관련 게시물 : "mod_url 을 살려내라!"
http://bbs.kldp.org/viewtopic.php?t=41009&highlight=mod_url

사용자가 바꾸어 나가자!!

= about me =
http://wiki.kldp.org/wiki.php/offree , DeVlog , google talk : offree at gmail.com

익명 사용자의 이미지

mod_url관련 URL이

http://kldp.net/projects/modurl

로 되었습니다. 참고 바랍니다.

참고로 소스는 cvs로 들어 가셔서 받으시길 바랍니다.

chunsj의 이미지

gyumee wrote:
얼마전에 W3C의 문서를 보다가 찾았었는데요. URL을 UTF-8로 보내는 것이 표준인 것 같더라구요. 그렇다면 apache쪽이 표준을 구현하지 않은 것이 되겠죠.
mod_url을 살려서 사람들이 사용하도록 하는게 필요할 것 같네요.

아파치도 UTF-8로 보냅니다. 원본이 EUC_KR로 되어 있을때가 문제죠. 저는 맥을 쓰는 관계로 파일이름도 UTF-8입니다. 따라서 아무 문제가 없죠. 아파치는 표준을 지키고 있습니다.

niceview의 이미지

음.. Firefox 같은 경우 about:config화면에서 network.standard-url.encode-utf8가 false로 되어있던데.. 그럼 표준에 어긋나는 것인가요? 요 옵션대로라면 IE에서 "항상 UTF-8로 보냄"이 off된 상태와 같은 것 같은데요.

iolo의 이미지

URL을 UTF8로 보내는게 표준? 그런가요?
간단하게 말씀들 하시지만, 생각보다 복잡한 문제입니다.

제가 알기로는 애초에 URL에는 인코딩은
"US-ASCII charset을 기준으로 하고, US-ASCII영역외의 문자나 특정 문자(=, /, _, & 이런것들이죠)에 대해서 흔히말하는 URL 인코딩(%인코딩)을 한다"가 표준이라고 알고 있습니다.(rfc2616)

예를들면:

http://xxxx/yyyy.cgi?param1=ABC&param2=한글

이라고 하면 저 '한글'이라는 부분을 어떻게 할것인가의 문제인 거죠.

표준에 근거하여 %인코딩을 한다면... US-ASCII영역 밖의 charset은 EUC-KR인가 UTF-8인가? 참조할 charset이 없으며 US-ASCII인데... 거기에는 '한', '글'을 표현할 방법이 없다는 겁니다. GET요청 자체가 HTTP의 Content-Type헤더보다 먼저나오고 상위 수준의 헤더니 참조할 charset이 없다는 거죠. 곤란하죠 -.-;;

그래서 그 "기본 charset"이 US-ASCII가 아니고 UTF-8이라면, '한글'이라는 부분을 UTF-8을 기준으로 %인코딩하거나, 아예 안하면 되는 거죠.

그러면 IE식의 UTF8로 보내기가 좋은 해결책이 아니냐라고 생각할 수 있지만, 몇가지 문제점이 있습니다.
첫째는, 표준에 근거한 것이 아니다. 즉, 서버에게 charset을 UTF8로 간주하라고 주장할 근거가 없다는 것입니다.
둘째는, GET요청이 아닌 경우에는 어떻게 할것인가? 즉, HTTP본문 안쪽에 들어간 POST 데이터들도 해당 되는가의 문제입니다. 이 경우에는 Content-Type헤더에 charset을 명시해줄 수 있으므로 UTF8로 해야할 이유가 별로 없다는 거죠. 실제로 IE도 UTF8로 보내기는 GET에만 적용됩니다. Content-Type에 charset을 명시하지 않고 POST로 한글 데이터를 보내면 서버쪽 응답에서 사용한 charset이 사용됩니다.

예를 들어,
Content-Type:text/html;charset=EUC-KR인 웹 페이지에
다음과 같은 내용이 있다고 해보면:

<a href="xxx.cgi?value=한글">링크</a>

<form action="xxx.cgi" method="post">
<input type="text" name="value" value="한글">
<input type="submit">
</form>

xxx.cgi가 받는 value의 값은 EUC-KR일까요? UTF-8일까요?

참고로, 메일에도 동일한 딜레마가 있었습니다.
메일 본문에 들어가는 내용은 Content-Type헤더를 근거로 하면 되지만...
헤더의 값들(Subject같은거죠)은 어떻게 할것인가라는 거죠.
그래서, 개정된 표준에는 인라인 인코딩이라는 것을 하도록 하고 있습니다.
Subject: =?euc-kr?Q?... 뭐 이런식으로 하는 거죠.
즉, 그 값 자체에 charset에 대한 정보를 추가한 겁니다.(rfc2822? rfc1521던가요?)
다만, 실생활에선 표준이 없는 웹과 마찬가지로 표준이 있는 메일에서도 헤더에 아무말 없이 EUC-KR로 된 제목들이 인라인 인코딩없이 들어 있다는 겁니다.

얘기가 횡설 수설 길어졌는데... 요약하면:
1. encoding과 charset의 혼동으로 문제를 오해하고 있는 사람들이 많다.
2. 현재로썬 뾰족한 해결책 혹은 권장할만한 방법이라는 것은 없다.
HTTP에서도 메일쪽과 비슷한 식의 접근법이 필요하다고 생각하지만, 현재로썬 IE처럼 "항상 UTF8로 보냄"이 좋은 해결책인가에 대해서는 논란의 소지가 있다.
3. HTTP에만 국한된 문제가 아니며, UTF8로 접근하려면 다른 유사한 표준에서 US-ASCII로 명시된 기본 charset을 UTF8로 변경하는 큰 틀의 접근이 필요하다.

흑ㅠ.ㅠ 오늘도 말이 꼬이네...-.-;;;

----
the smile has left your eyes...

cdpark의 이미지

niceview wrote:
음.. Firefox 같은 경우 about:config화면에서 network.standard-url.encode-utf8가 false로 되어있던데.. 그럼 표준에 어긋나는 것인가요? 요 옵션대로라면 IE에서 "항상 UTF-8로 보냄"이 off된 상태와 같은 것 같은데요.

firefox의 경우, EUC-KR로 된 페이지의 링크는 EUC-KR로, UTF-8으로 된 문서의 링크는 UTF-8으로 보냅니다. 현재로선 가장 깔끔한 해결책일 듯 싶습니다.

그리고 프로그램으로 만드는 페이지의 경우, 한글 이름으로 모두 %xx로 escape시키도록 해면 브라우저의 설정에 무관합니다. CGI나 PHP 프로그래밍을 한다면 이렇게 처리하면 됩니다.

MoinMoin 1.3.X에서 예전에 _xx 식을 %xx로 바꿨더군요. 깔끔해요. IE에서도 잘 동작하고요.

creativeidler의 이미지

iolo님 말씀이 모두 맞습니다. URL에 UTF8 인코딩을 사용하는 것은 표준이 아닙니다. 그리고 다국어 문제의 좋은 해결책인 것 같지도 않구요. 서버에서 제공하는 HTML의 인코딩이 UTF8인 것과는 다른 문제로 보아야 할 것입니다.

kils의 이미지

creativeidler wrote:
iolo님 말씀이 모두 맞습니다. URL에 UTF8 인코딩을 사용하는 것은 표준이 아닙니다. 그리고 다국어 문제의 좋은 해결책인 것 같지도 않구요. 서버에서 제공하는 HTML의 인코딩이 UTF8인 것과는 다른 문제로 보아야 할 것입니다.

저도 같은 의견입니다.
그나저나 문제를 제기하시분은 일본으로 국적을 이적하신 분이지요???

한국이름이 아니고 일본 이름을 가지셨다고...

씁쓸하네요...

블루스크린의 이미지

kils wrote:
creativeidler wrote:
iolo님 말씀이 모두 맞습니다. URL에 UTF8 인코딩을 사용하는 것은 표준이 아닙니다. 그리고 다국어 문제의 좋은 해결책인 것 같지도 않구요. 서버에서 제공하는 HTML의 인코딩이 UTF8인 것과는 다른 문제로 보아야 할 것입니다.

저도 같은 의견입니다.
그나저나 문제를 제기하시분은 일본으로 국적을 이적하신 분이지요???

한국이름이 아니고 일본 이름을 가지셨다고...

씁쓸하네요...

놀라기는 했지만 신상에대한 언급이 적절한거 같지는 않네요

-------------------------------------------------------------------------------
이 댓글(comment)의 수정 및 삭제를 위해 이 글에 답글(reply)을 쓰지 말아 주십시요.
의견이 있으시면 원 글에 댓글(comment)로 써 주세요.

niceview의 이미지

iolo wrote:

예를들면:

http://xxxx/yyyy.cgi?param1=ABC&param2=한글

이라고 하면 저 '한글'이라는 부분을 어떻게 할것인가의 문제인 거죠.

음.. get/post쪽 뿐 아니라 url자체에도 한글이 사용될경우 문제가 되는 것 같습니다. 제가 말씀드린 예제에서도 get/post가 아니라 파일 이름이 문제가 되었거든요.

iolo wrote:

요약하면:
1. encoding과 charset의 혼동으로 문제를 오해하고 있는 사람들이 많다.
2. 현재로썬 뾰족한 해결책 혹은 권장할만한 방법이라는 것은 없다.
HTTP에서도 메일쪽과 비슷한 식의 접근법이 필요하다고 생각하지만, 현재로썬 IE처럼 "항상 UTF8로 보냄"이 좋은 해결책인가에 대해서는 논란의 소지가 있다.
3. HTTP에만 국한된 문제가 아니며, UTF8로 접근하려면 다른 유사한 표준에서 US-ASCII로 명시된 기본 charset을 UTF8로 변경하는 큰 틀의 접근이 필요하다.

제가 제대로 이해하고 있는지 살펴봐주세요. ^-^
1. encoding은 url에 들어있는 한글을 인코딩(주소 입력란에 친 것이나 <img src='어쩌구저쩌구'>에서 '어쩌구저쩌구'에 대한 것 모두) 하는 문제를 칭하는 것이고, characterset은 그 인코딩의 매칭(%뭐뭐가 '한' 에 해당.. 등등)에 대한 것.

2. risapapa님이 지적하신대로 아시아권(한국 제외, 중국이나 일본)에서 웹 페이지를 보았을때 발생할 수 있는 문제점을 생각해보면 UTF8로 보내는 것도 나쁘지 않을 것 같은데요? ^-^ Firefox처럼 웹페이지 인코딩이 euc-kr이면 그 내부에서 참조하는 url도 모두 인코딩을 euc-kr로 보내는 방식이라면, 그래도 Firefox처럼 url주소창에서 조차 바로바로 encoding한 결과물을 보여주는 방식이라면 문제가 없겠지만(오오 Firefox 굿~~!) IE처럼 주소창에 보이는 것 따로 실제 넘어가는 것 따로라면 UTF8로 통일하는것이 나쁜것 같진 않아요.

3.음.. 제가 잘 이해를 못해서 그런데, 아시아권 문자가 들어가면 UTF-8로 인코딩하는 것이 범용성 있지 않을까요?

cdpark wrote:

firefox의 경우, EUC-KR로 된 페이지의 링크는 EUC-KR로, UTF-8으로 된 문서의 링크는 UTF-8으로 보냅니다. 현재로선 가장 깔끔한 해결책일 듯 싶습니다.

아아. 그래서 제가 실험한 결과가 그렇게 나왔군요. 정말 깔끔하네요 @_@ about:config에서 본 encode 설정은 아마도 페이지의 인코딩을 무시하고 무조건 utf-8로 보내는 것인가봅니다.
(엇.. 그럼 IE로 '항상 UTF-8로 보냄'을 끄면 euc-kr이면 euc-kr, utf-8이면 utf-8로 보내나요?)

그리고.. 덧붙여서..

fedora에서도 utf-8을 기본으로 사용하고, 많은분들이 utf-8로 가는 것이 궁극의 표준이라고들 하시던데, 그렇게 하시는 이유가 궁금합니다. ^-^;

niceview의 이미지

제가 올린글의 마지막 질문에 대한 자답입니다. ^-^

http://www.itinside.net/articles/011030-unicode.html

익명 사용자의 이미지

UTF-8도 문제가 없는 것은 아닙니다. 우선, UTF-8이 유니코드 인코딩의 표준은 아닙니다. 많은 경우에 UTF-16이 쓰이고 있죠. 그리고 UTF-8이라고해서 모든 문자를 다 표현할 수 있는 것은 아닙니다. 중국 문자 중 일부는 제대로 표현하지 못하고 있죠. 때문에 UTF-32가 거론되고 있습니다. 게다가 UTF-8은 UTF-16에 비해 다소 영미권에 유리한 인코딩입니다. UTF-16은 모두 똑같이 2바이트로 인코딩하지만 UTF-8은 ASCII 영역은 1바이트로, 아시아권 문자는 3바이트로 표기하죠. 효율성을 떠나서 그 발상의 불공평함이 맘에 안 듭니다.

만약 이 문제를 해결하고 싶다면 단순히 UTF-8로 보내기라든지, 브라우저, 서버를 맞추는 수준을 넘어서서 아예 RFC 표준에 유니코드를 적용하는 정도로 개혁이 이루어져야한다고 봅니다. 그래야 넷피아 같은 거 안 통하고 한글 도메인도 자유롭게 쓰고 한글 이메일 주소도 자유롭게 쓸 수 있겠죠.

iolo의 이미지

niceview wrote:
iolo wrote:

예를들면:

http://xxxx/yyyy.cgi?param1=ABC&param2=한글

이라고 하면 저 '한글'이라는 부분을 어떻게 할것인가의 문제인 거죠.

음.. get/post쪽 뿐 아니라 url자체에도 한글이 사용될경우 문제가 되는 것 같습니다. 제가 말씀드린 예제에서도 get/post가 아니라 파일 이름이 문제가 되었거든요.

말씀하신 "url자체"라는 것이 바로 GET입니다.
POST요청에서는(보통 form의 submit을 누르는 경우) Content-Type헤더에 charset을 명시해주면 되기 때문에 아무런 문제도 없습니다.
앞에서 제가 form을 예로 든 이유는 GET에서는 문제가 되고 POST에서는 문제가 되지 않음을 비교 설명한기 위한 것입니다.

웹브라우져의 위치 창에 "http://xxx/yyy.cgi?param1=한글"이라고 쳤다고 하면(GET요청을 보낸거죠), 리눅스의 경우에는 LANG값에 따라 EUC-KR이 갈수도 있고 UTF-8이 갈수도 있고 다른 무엇이 갈수도 있습니다. IE에선 '항상 UTF-8로 보내기'를 하면 UTF8로 가고, 그렇지 않으면 CP949(간단히 말하면 MS의 통합완성형)로 갑니다.

문제는 이 시점(HTTP 최초 요청)에서 서버는 클라이언트가 뭘로 보냈지 지 알 수 없다(추측할 방법도 없다)는 것입니다. IE에서 말하는 '항상 UTF-8로 보내기'옵션은 서버가 'UTF-8'로 보냈을 것이라고 가정하고 처리를 해주어야 하는 것이지, 클라이언트(IE)에서 내맘대로 한다고 되는 일이 아닙니다.

그럼에도 불구하고 IE가 이런 옵션을 만든 이유는(이건 제 개인적인 생각일 뿐입니다):
- UTF-8은 US-ASCII의 완전한 수퍼셋이므로 영어권에선 손해 볼 것이(수정해야 할 것이) 하나도 없다.
- 해결책이 없는 상태에서 오류가 발생하는데, IE의 문제로 인식이 되는 경우가 많으니. 이를 자기들 편한 방법으로 해석하고, 해결책을 제시하고, 사용자(개발자)의 문제로 떠넘기는 것입니다.

niceview wrote:

제가 제대로 이해하고 있는지 살펴봐주세요. ^-^
1. encoding은 url에 들어있는 한글을 인코딩(주소 입력란에 친 것이나 <img src='어쩌구저쩌구'>에서 '어쩌구저쩌구'에 대한 것 모두) 하는 문제를 칭하는 것이고, characterset은 그 인코딩의 매칭(%뭐뭐가 '한' 에 해당.. 등등)에 대한 것.

2. risapapa님이 지적하신대로 아시아권(한국 제외, 중국이나 일본)에서 웹 페이지를 보았을때 발생할 수 있는 문제점을 생각해보면 UTF8로 보내는 것도 나쁘지 않을 것 같은데요? ^-^ Firefox처럼 웹페이지 인코딩이 euc-kr이면 그 내부에서 참조하는 url도 모두 인코딩을 euc-kr로 보내는 방식이라면, 그래도 Firefox처럼 url주소창에서 조차 바로바로 encoding한 결과물을 보여주는 방식이라면 문제가 없겠지만(오오 Firefox 굿~~!) IE처럼 주소창에 보이는 것 따로 실제 넘어가는 것 따로라면 UTF8로 통일하는것이 나쁜것 같진 않아요.

3.음.. 제가 잘 이해를 못해서 그런데, 아시아권 문자가 들어가면 UTF-8로 인코딩하는 것이 범용성 있지 않을까요?

cdpark wrote:

firefox의 경우, EUC-KR로 된 페이지의 링크는 EUC-KR로, UTF-8으로 된 문서의 링크는 UTF-8으로 보냅니다. 현재로선 가장 깔끔한 해결책일 듯 싶습니다.

아아. 그래서 제가 실험한 결과가 그렇게 나왔군요. 정말 깔끔하네요 @_@ about:config에서 본 encode 설정은 아마도 페이지의 인코딩을 무시하고 무조건 utf-8로 보내는 것인가봅니다.
(엇.. 그럼 IE로 '항상 UTF-8로 보냄'을 끄면 euc-kr이면 euc-kr, utf-8이면 utf-8로 보내나요?)

아시권에만 해당하는 얘기가 아닙니다. US-ASCII가 아닌 모든 나라에 해당하는 문제입니다. 독일어나 불어등에서 움라우트 문자를 보낼때도 똑같은 문제가 있습니다.

cdpark님이 말씀하신 대로입니다만, 역시 문제는 최초의 요청입니다. 브라우져의 위치 창을 직접 입력하거나, 다른 사이트로의 링크와 같은 경우죠.
(실제론, 모든 GET요청은 이 경우죠.)

앞의 제 설명을 이해하셨다면, 이러한 경우전혀 해결책이 되지 않는 다는 것을 아실 것입니다.

반복이지만 다시 다른 방법으로 설명을 하면:
이렇게 한번 해보십시오.

telnet dic.yahoo.co.kr 80
GET /search/eng/search.html?p=%C7%D1%B1%DB HTTP/1.1
<-- 여기서 엔터 한번 더

뭔가 주루룩 결과가 나올 것입니다.
저기에서 입력한 C7 D1 B1 DB라는 것은 '한글'을 EUC-KR 코드로 URL인코딩한것입니다.

GET /search/eng/search.html?p=%ED%95%9C%EA%B8%80 HTTP/1.1

으로 바꿔서 해보십시오.
저기에서 입력한 ED...는 '한글'을 UTF-8로 URL인코딩한것입니다.
결과를 보시면 "그런 단어 없다"는 것입니다.

여기에서 앞의 동작은 '항상 UTF-8로 보내기'가 꺼진 상태에서 IE(혹은 ko_KR.EUC-KR환경의 리눅스에서의 파이어폭스)의 동작입니다.
뒤의 동작은 '항상 UTF-8로 보내기'가 켜진 상태에서 IE(혹은 ko_KR.UTF-8환경의 리눅스에서의 파이어폭스)의 동작이죠.
물론 웹브라우져에서 야후사전페이지를 열고 폼을 통해 입력하면 무조건 위의 결과를 만들어냅니다. cdpark님이 말씀하신대로 동작하기 때문이죠.
그러나, 이렇게 되서는 URL의 의미가 무색해져 버리죠.

문제는 이 동작이나, 이전 동작에 아무런 charset에 대한 정보가 없다는 것입니다.
예로 든 야후코리아에서는 거의 대부분의 고객이 한국 사람이고, 한글 윈도를 쓸테니 EUC-KR로 보낼 것임을 가정하고 만들었다는 거죠. 야후 코리아 뿐 아니라 수많은 사이트들이 이렇게 되어 있습니다.

IE혼자 이렇게 하자 저렇게 하자고 해서 해결될 일이 아니라는 것입니다.

niceview wrote:

그리고.. 덧붙여서..

fedora에서도 utf-8을 기본으로 사용하고, 많은분들이 utf-8로 가는 것이 궁극의 표준이라고들 하시던데, 그렇게 하시는 이유가 궁금합니다. ^-^;


저도 우분투에 utf8을 기본으로 사용하고 있습니다.
궁극까진 아닐지 몰라도 가장 현실성이 있는 대안입니다.
우리나라입장에서는 EUC-KR이 더 좋은 방법(한글 한글자에 2바이트면 되니까)이겠지만 다른나라에서 인정해줄리가 없죠.
다른 나라도 마찬가지구요. 그렇다고 현행대로 US-ASCII이면 곤란하니... 조금씩 손해보자(바이트수가 늘어나죠)는 것입니다.
"기득권자"인 US-ASCII입장에서는 달라질게 없으니(자기들 글자는 여전히 1바이트면 되고, 별도로 고칠것도 없으니까) 마다할 이유가 없는 것이죠.

유니코드가 나온지 한참되었지만, 거의 존재감없이 무시당하다가 UTF-8인코딩이 나온 이후로 그나마 탄력을 받았다고 생각됩니다.
유니코드의 기본 인코딩방법인 UTF-16에서는 "기득권자"인 US-ASCII가 손해를(자기들 글자도 2바이트)보니까요.

결국 "기득권자"를 인정하면서, 약간 우회해서 서로가 만족할 만한 타협을 모색한 것이죠.
솔직히, 궁극이라면 UTF-16(최근엔 그것도 부족해서 UTF-32)이 아닐까요?

----
the smile has left your eyes...

정태영의 이미지

http://www.w3.org/International/O-URL-and-ident

Quote:
* Guidelines for new URL Schemes, RFC 2718, proposes to base URIs on UTF-8 unless there is some compelling reason for a particular scheme to do otherwise.
* URI schemes or components already based on UTF-8:
o URN syntax : RFC 2141 (syntactically, URNs look like a URI scheme, but semantically, they are not)
o IMAP: RFC 2192 (the IMAP protocol uses a modified version of UTF-7, but its URIs use UTF-8)
o FTP ( RFC 2640 uses UTF-8, but tolerates legacy encodings)
o XPointer (W3C Working Draft)

오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...

http://mytears.org ~(~_~)~
나 한줄기 바람처럼..

chunsj의 이미지

iolo wrote:

문제는 이 시점(HTTP 최초 요청)에서 서버는 클라이언트가 뭘로 보냈지 지 알 수 없다(추측할 방법도 없다)는 것입니다. IE에서 말하는 '항상 UTF-8로 보내기'옵션은 서버가 'UTF-8'로 보냈을 것이라고 가정하고 처리를 해주어야 하는 것이지, 클라이언트(IE)에서 내맘대로 한다고 되는 일이 아닙니다.
[/quote="iolo"]

때문에 모를때는 가장 범용성을 가지는 UTF-8로 해야 한다는 것이 제 생각입니다. 어찌 달랑 한 나라에서만 되는 EUC-KR로 만들고 나는 책임없다 또는 UTF-8은 해결책인 안된다(그리고 나는 추가적인 일을 하기 싫다!)라고 말을 할 수 있겠습니까?

iolo wrote:

그럼에도 불구하고 IE가 이런 옵션을 만든 이유는(이건 제 개인적인 생각일 뿐입니다):
- UTF-8은 US-ASCII의 완전한 수퍼셋이므로 영어권에선 손해 볼 것이(수정해야 할 것이) 하나도 없다.
- 해결책이 없는 상태에서 오류가 발생하는데, IE의 문제로 인식이 되는 경우가 많으니. 이를 자기들 편한 방법으로 해석하고, 해결책을 제시하고, 사용자(개발자)의 문제로 떠넘기는 것입니다.
[/quote="iolo"]
저는 당연히 이미 기득권을 가진 ASCII의 권리는 인정할 수 밖에 없으며 가장 범용적인 동작이 가능하도록 개발자(사용자)는 수정을 해야할 의무가 있다고 생각합니다.

iolo wrote:

telnet dic.yahoo.co.kr 80
GET /search/eng/search.html?p=%C7%D1%B1%DB HTTP/1.1
<-- 여기서 엔터 한번 더

뭔가 주루룩 결과가 나올 것입니다.
저기에서 입력한 C7 D1 B1 DB라는 것은 '한글'을 EUC-KR 코드로 URL인코딩한것입니다.

GET /search/eng/search.html?p=%ED%95%9C%EA%B8%80 HTTP/1.1

으로 바꿔서 해보십시오.
저기에서 입력한 ED...는 '한글'을 UTF-8로 URL인코딩한것입니다.
결과를 보시면 "그런 단어 없다"는 것입니다.

여기에서 앞의 동작은 '항상 UTF-8로 보내기'가 꺼진 상태에서 IE(혹은 ko_KR.EUC-KR환경의 리눅스에서의 파이어폭스)의 동작입니다.
뒤의 동작은 '항상 UTF-8로 보내기'가 켜진 상태에서 IE(혹은 ko_KR.UTF-8환경의 리눅스에서의 파이어폭스)의 동작이죠.
물론 웹브라우져에서 야후사전페이지를 열고 폼을 통해 입력하면 무조건 위의 결과를 만들어냅니다. cdpark님이 말씀하신대로 동작하기 때문이죠.
그러나, 이렇게 되서는 URL의 의미가 무색해져 버리죠.

문제는 이 동작이나, 이전 동작에 아무런 charset에 대한 정보가 없다는 것입니다.
예로 든 야후코리아에서는 거의 대부분의 고객이 한국 사람이고, 한글 윈도를 쓸테니 EUC-KR로 보낼 것임을 가정하고 만들었다는 거죠. 야후 코리아 뿐 아니라 수많은 사이트들이 이렇게 되어 있습니다.
[/quote="iolo"]
저는 이점이 잘못된 것이라고 생각합니다. 물론 한국에서만 쓰니까 괜찮아 라고 하면 상관이 없을 수도 있다고 생각할 수 있겠지만, 그렇다면 그 서비스를 이용하는 모든 어플리케이션은 한국적인 상황에 특화되어야 하는 문제가 생깁니다. 그리고 그 말은 모든 다른 인코딩을 쓰는 나라별로 어플리케이션이 특화되어야 한다는 것을 말하고요. 당연히 UTF-8일때 동작을 해야 하는 것이 올바른 어플리케이션 즉 현재의 동작은 개발자의 잘못이라고 봅니다.

iolo wrote:

IE혼자 이렇게 하자 저렇게 하자고 해서 해결될 일이 아니라는 것입니다.
[/quote="iolo"]
IE혼자 이렇게/저렇게는 아닌 것으로 알고 있습니다.

iolo wrote:

저도 우분투에 utf8을 기본으로 사용하고 있습니다.
궁극까진 아닐지 몰라도 가장 현실성이 있는 대안입니다.
우리나라입장에서는 EUC-KR이 더 좋은 방법(한글 한글자에 2바이트면 되니까)이겠지만 다른나라에서 인정해줄리가 없죠.
다른 나라도 마찬가지구요. 그렇다고 현행대로 US-ASCII이면 곤란하니... 조금씩 손해보자(바이트수가 늘어나죠)는 것입니다.
"기득권자"인 US-ASCII입장에서는 달라질게 없으니(자기들 글자는 여전히 1바이트면 되고, 별도로 고칠것도 없으니까) 마다할 이유가 없는 것이죠.

유니코드가 나온지 한참되었지만, 거의 존재감없이 무시당하다가 UTF-8인코딩이 나온 이후로 그나마 탄력을 받았다고 생각됩니다.
유니코드의 기본 인코딩방법인 UTF-16에서는 "기득권자"인 US-ASCII가 손해를(자기들 글자도 2바이트)보니까요.

결국 "기득권자"를 인정하면서, 약간 우회해서 서로가 만족할 만한 타협을 모색한 것이죠.
솔직히, 궁극이라면 UTF-16(최근엔 그것도 부족해서 UTF-32)이 아닐까요?

UTF-16/32가 표시할 수 있는 것들은 UTF-8이 기술적으로 표시못할 경우가 있나요? 1,2,3,4...멀티바이트가 가능한 것으로 알고 있습니다만.... 그리고 ASCII의 기득권은 당연히 인정될 수 밖에 없습니다. 가장 기본적인 언어일 수 밖에 없고(컴퓨팅 환경에서) 가장 범용의 언어이기 때문에 말입니다.

creativeidler의 이미지

chunsj님의 주장에는 두 가지 반론이 가능합니다. 우선, 범용성을 위해서 UTF-8을 사용해야한다는 주장은 딱 UTF-8을 꼽기엔 좀 부족합니다. 국제화를 위해서라면 유니코드의 다른 인코딩들도 모두 가능하니까요. 두번째, USASCII의 기득권을 우리가 '당연히' 인정해야할 이유는 없습니다. 단지 역사의 굴레일 뿐입니다. 과거 64k 메모리 제한을 지금 누구도 당연하다고 생각하지 않듯 이것도 얼마든지 깨질 수 있는 문제라고 봅니다. 윈도우만해도 내부적으로 UTF-16을 쓰고 있습니다. 물론 UTF-8이 자연스럽게 유니코드로 넘어갈 수 있는 좋은 방법인 것은 사실입니다만, 그 불공평함에 불쾌감이 남는 것은 어쩔 수가 없겠죠.

그러나, RFC에서 URL의 새로운 표준으로 UTF-8 인코딩을 사용하기로 정했다면 범용성이 아니라 표준이라는 점에서 UTF-8이 설득력을 가질 수 있겠습니다. 이건 저도 모르고 있었네요. 그렇다면 아마도 IE도 새 URL 표준이 등장하고 나서 이것을 구현하기 위해 등장한 것이겠군요.

그렇다면 서버측에서는 문제가 한층 더 복잡해지는군요. UTF-8로 보냄을 체크한 경우와 아닌 경우를 모두 처리할 수 있어야할테니까요. 사실 모두 UTF-8로 보냄을 체크하고 그것만 처리하면 속편하겠지만 그건 오히려 개발자만의 바램일 뿐입니다. 사용자가 뭘 어떻게 체크해놓든지 다 처리를 해내야하는 것이 현실이죠.

iolo의 이미지

인용이 너무 길어져서 생략합니다.

저도 동의합니다. 개발자의 입장에서, 뭔지 모를 때는 UTF-8이라고 간주할 수 있었으면 좋겠습니다. 다만, 그건 우리 생각(한국 사람이고, 개발자인..)이라는 겁니다. 말씀하신대로 저들(US-ASCII면 충분한 기득권자들)의 입장에선 뭔지 모를때는 US-ASCII라고 간주하겠다고 표준을 만들었습니다. 적어도 아직은 그렇습니다. 조금씩 나아지긴 하겠지만, 현재로썬 그렇게 안된다고 해서 잘못되었다고 할 만한 근거는 없다는 것일 뿐입니다.

위에 정태영 님이 링크걸어 주신 RFC들이 기존 RFC들이 좀 더 자리를 잡는 다면 이 토론에 대한 답이 될것 같네요. 시간이 필요한 일인것 같습니다.

그리고 UTF8에 대한 말씀은, 제 글을 쭉 보셨으면 아시겠지만 저도 오래전부터 UTF8환경을 사용해왔고, UTF8을 옹호하는 입장입니다. 다만 위에 손님으로 글을 쓰신 분이 "불공평"에 대해서 얘기하셨기에... "기득권"을 무시할 수 없다는 취지로 적은 것입니다. UTF8보다는 UTF16이나 32가 궁극에 가깝다고 얘기한 것은 "불공평"하지 않기 때문입니다.

UTF8을 받아들이기에 앞서 "UTF8을 쓰면 한글이 3바이트 혹은 4바이트가 되고, 데이터의 크기나 처리 시간이 2배이상 증가할 수 있다"는 불이익이 있다는 것, 그리고 그 불이익은 기득권자들이 부여한 '핸디캡'이라고 인정하고 받아들이는 일이 선행되어야 합니다. 이 부분에 대한 (최소한, 묵시적인) 동의가 전혀 이루어지지 않은 상태에서 특정 기업에 의한 UTF8로의 이행은, 과거 정부가 상용조합형을 무시하고 KSC5601.1987 완성형으로 강제적으로 이행했던 일이나 MS가 EUC를 무시하고 일방적으로 통합완성형(확장완성형?)을 윈도에 탑재해버린 일을 상기시키는 군요.

괜히 쓰레드에 끼어들어 말이 많았는데,

URL에 국한하지 않고 UTF8에 대한 제 입장은:
"UTF8이 절대 선은 아니지만, 현실적으로 만족할 만한 대안이며,
UTF8로의 이행을 적극 지지하며, 확산을 위해 힘쓴다"는 것입니다.

IE의 항상 UTF8로 보내기에 대한 입장은:
윈도에서 먼저 통합완성형을 걷어내고 UTF8체제로 이행해야합니다. 시장의 반발 때문에 선뜻 그렇게 하지도 못하면서, (대안이 없는)웹브라우져에만 전후좌우없이 그런 옵션을 끼워넣는 것은 MS 입장에선 좋은 전략일지 몰라도, 그 전략에 발맞추지 않는다고 개발자들(예를 들면 아후사전개발자)를 비난할 근거는 못됩니다.

----
the smile has left your eyes...

chunsj의 이미지

iolo wrote:
IE의 항상 UTF8로 보내기에 대한 입장은:
윈도에서 먼저 통합완성형을 걷어내고 UTF8체제로 이행해야합니다. 시장의 반발 때문에 선뜻 그렇게 하지도 못하면서, (대안이 없는)웹브라우져에만 전후좌우없이 그런 옵션을 끼워넣는 것은 MS 입장에선 좋은 전략일지 몰라도, 그 전략에 발맞추지 않는다고 개발자들(예를 들면 아후사전개발자)를 비난할 근거는 못됩니다.

저도 여기에 크게는 동의합니다. (실은 이 의견이 제가 가장 원하는 것이었습니다.) 윈도에서 통합완성형(저는 이것도 EUC-KR의 일종이라고 간주합니다.)을 걷어 내는 것은 기존의 호환성을 위해서 힘들 수 있으므로 가지고는 있되(왜냐하면 아예 없애버리면 이전 데이터를 읽을 수 없으므로...) 기본은 UTF-8로 갔으면 합니다(즉, 생성되는 데이터는 UTF-8 로 생성이 되기를 바랍니다. 지금은 영문윈도에서 한글을 입력하도록 하고 사용하면 UTF-8로 생성이 되지만 한글 윈도에서는 MSCP949로 생성이 되더군요, 물론 어플리케이션의 데이터는 아니고 - 이것은 어플리케이션의 선택사항이므로 - 파일 이름등을 말하는 것입니다). 하지만 이 문제와 웹 어플리케이션에서의 지원 문제와는 다르다고 봅니다. 그리고 이전의 야후사전개발자들은 선택의 여지가 없었기 때문에 그랬다고 볼 수는 있지만, 지금은 이미 IE조차도 표준을 지원하므로 이제는 잘못된 서버 어플리케이션이라는 비난을 피할 수는 없다고 봅니다.

creativeidler의 이미지

글쎄요. 전 '개발자는 오로지 고객의 요구사항 충족에 실패했을 때만 비난 받을 수 있다'라고 생각하기에 거기에는 동의할 수 없네요. 국내에서만 쓰이는 웹사이트라면 EUC-KR을 URL 인코딩으로 보내고 받는 것으로 가정하는 것이 잘못된 요구사항 분석은 아니라고 보는데요. 어쨋든 많은 사용자들이 UTF-8로 보냄에 체크를 안하고 쓰니까요.

오히려 이건 개발자를 위한 거라는 측면에서 이해해야한다고 봅니다. 좋은 코드, HTML & CSS 권고안 준수, 유니코드 등등 모두 개발자를 편하게 해주기에 의미가 있는 것입니다. (물론 브라우저 호환성 문제는 고객과도 상관 있죠.) 이런 걸 의무라고 규정하고 지키지 않았다고 비난하는 것은 좀 문제가 있죠. 더군다나 URL은 복수표준이기 때문에 EUC-KR을 URL 인코딩으로 보내는 것이 표준이 아니라고 말할 수는 없습니다.

꼬마앙마의 이미지

그런데 말입니다.

제가 잘 이해했는지 모르겠군요.

현재 POST는 문제가 없다는 것이지요.

GET부분만이 문제가 된다는것인데,

사용자가

http//xxxx/yyyy.cgi?param1=ABC&param2=한글

이렇게 보냈을때 서버는 사용자의 환경이 어떤것인지 모르기 때문에

이것을 euc_kr로 처리해야 하는지, utf-8로 처리해야 하는지,

아니면 또 다른 문자형식인지 알수 있는 방법이 없다는 것이군요.

이런경우에 USER_AGENT 정보를 보아서 알수 있는 방법은 없을까요?

USER_AGENT정보를 확인해서 한글 사용하는 euc-kr을 사용하기 때문에, euc-kr로 처리하고

일본어를 사용하는 사용자는 shift_jis를 사용하기 때문에 shift_jis 언어셋으로 이해하면 안되는겁니까...?

iolo님께서 말씀하신 모든 사용자가 UTF-8을 사용하는것은 불가능에 가까우니....

머리속이 복잡하네요.

ganadist의 이미지

USER_AGENT에는 사용자의 국가 정보는 담겨있지만 사용자가 쓰는 charset에 대한 정보는 없습니다.

거기다 한국가에서 하나의 charset만 쓴다는 보장도 없고요.

----
데스크탑 프로그래머를 꿈꾸는 임베디드 삽질러

chunsj의 이미지

creativeidler wrote:
글쎄요. 전 '개발자는 오로지 고객의 요구사항 충족에 실패했을 때만 비난 받을 수 있다'라고 생각하기에 거기에는 동의할 수 없네요. 국내에서만 쓰이는 웹사이트라면 EUC-KR을 URL 인코딩으로 보내고 받는 것으로 가정하는 것이 잘못된 요구사항 분석은 아니라고 보는데요. 어쨋든 많은 사용자들이 UTF-8로 보냄에 체크를 안하고 쓰니까요.

많은 사용자들이 UTF-8로 보냄에 체크를 안하는 것은 개발자들이 그렇게 강요을 한 때문입니다. 기본적으로 XP에서는 체크가 되어 있습니다. 그걸 꺼야 된다라고 제가 보기엔 잘못된 어플리케이션을 작성한 개발자(사이트)들이 강요한 것이지요.

반대로 UTF-8로 동작을 하게 하고 UTF-8로 보냄을 켜서 사용하라고 할 수 있었음에도 말이죠. 그리고 이렇게 하면 장기적으로는 사용자들이 더 많은 나라의 더 많은 서비스를 쓸 수 있는 가능성이 높아짐에도 불구하고 말입니다.)

nohmad의 이미지

creativeidler wrote:
글쎄요. 전 '개발자는 오로지 고객의 요구사항 충족에 실패했을 때만 비난 받을 수 있다'라고 생각하기에 거기에는 동의할 수 없네요. 국내에서만 쓰이는 웹사이트라면 EUC-KR을 URL 인코딩으로 보내고 받는 것으로 가정하는 것이 잘못된 요구사항 분석은 아니라고 보는데요. 어쨋든 많은 사용자들이 UTF-8로 보냄에 체크를 안하고 쓰니까요.

국내에서만 쓰일 것이라고 미리 한정하는 좋은 가정이 아닌 것 같습니다. 인터넷이란 게 그렇지만, 해외의 한국인이 사용할 수도 있고, 한국어를 배우고 있는 외국인이 이용할 수도 있고, 해외 여행 중인 한국인이 낯선 땅의 컴퓨터를 통해 이용할 수도 있습니다. gmail이 최근 basic HTML view 옵션을 제공하면서, 시베리아의 인터넷 까페에서도 메일 확인이 가능하도록 하기 위해서라고 적은 것이 생각나는군요.

익명 사용자의 이미지

"URL을 항상 UTF8로 보내기" 옵션이 켜있던지 꺼있던지에 관계 없이
작동하게 하는 방법은 그리 어렵지 않습니다.

이 옵션을 끄라고 강요하는 어플이 있나보죠?

iolo의 이미지

Anonymous wrote:
"URL을 항상 UTF8로 보내기" 옵션이 켜있던지 꺼있던지에 관계 없이
작동하게 하는 방법은 그리 어렵지 않습니다.

이 옵션을 끄라고 강요하는 어플이 있나보죠?

어떤 방법이 있나요?

그렇게 할 수 있는 방법이 있다면, 이 논의 자체가 상당히 무의미해질 수 있습니다만...

그리고, 일부 웹사이트에서 이 옵션을 꺼라/켜라고 강요하는 곳이 있긴합니다.

----
the smile has left your eyes...

익명 사용자의 이미지

iolo wrote:
Anonymous wrote:
"URL을 항상 UTF8로 보내기" 옵션이 켜있던지 꺼있던지에 관계 없이
작동하게 하는 방법은 그리 어렵지 않습니다.

이 옵션을 끄라고 강요하는 어플이 있나보죠?

어떤 방법이 있나요?

그렇게 할 수 있는 방법이 있다면, 이 논의 자체가 상당히 무의미해질 수 있습니다만...

그리고, 일부 웹사이트에서 이 옵션을 꺼라/켜라고 강요하는 곳이 있긴합니다.


urlencode()를 쓰게끔 어플을 고치면 된다는 뜻인듯 한데요.
iolo의 이미지

chunsj wrote:

많은 사용자들이 UTF-8로 보냄에 체크를 안하는 것은 개발자들이 그렇게 강요을 한 때문입니다. 기본적으로 XP에서는 체크가 되어 있습니다. 그걸 꺼야 된다라고 제가 보기엔 잘못된 어플리케이션을 작성한 개발자(사이트)들이 강요한 것이지요.

반대로 UTF-8로 동작을 하게 하고 UTF-8로 보냄을 켜서 사용하라고 할 수 있었음에도 말이죠. 그리고 이렇게 하면 장기적으로는 사용자들이 더 많은 나라의 더 많은 서비스를 쓸 수 있는 가능성이 높아짐에도 불구하고 말입니다.)

정확히 어느 시점인지 모르겠습니다만, 기본으로 켜진 것으로 알고 있습니다.
그것도 문제 아닐까요?

옵션이 꺼져있을 때 개발된 사이트들을 무시하고(나쁜넘 만들었죠) 독점적인 지위를 이용하여, 임의로 옵션을 바꾼 것입니다. 통합완성형 밀어부칠때도 마찬가지였습니다. 아웃룩이 메일을 ksc5601.1987어쩌구해서 묘하게 인코딩해서 보내도, 그 메일을 읽지 못하는 국산 웹메일을 비난했습니다. 아웃룩 편지지를 읽지 못하면 그것도 비난 받았죠.

내가 만든 프로그램 내 맘대로 하겠다는 데 무슨 상관이냐라고 하면 뭐 저도 할말 은 없습니다. MS입장에선 그게 독점의 메리트인 것이고, 저같은 끝발없는 개발자 입장에서 독점의 횡포입니다.

말씀하신대로 그 옵션이 바뀌었을때 사이트를 그 옵션에 맞춰 구축했으면 좋았을 수도 있겠죠. 단, 다음 버전에 그 옵션이 또 무언가로 바뀌지 않는다면 말입니다.

----
the smile has left your eyes...

iolo의 이미지

Anonymous wrote:
iolo wrote:
Anonymous wrote:
"URL을 항상 UTF8로 보내기" 옵션이 켜있던지 꺼있던지에 관계 없이
작동하게 하는 방법은 그리 어렵지 않습니다.

이 옵션을 끄라고 강요하는 어플이 있나보죠?

어떤 방법이 있나요?

그렇게 할 수 있는 방법이 있다면, 이 논의 자체가 상당히 무의미해질 수 있습니다만...

그리고, 일부 웹사이트에서 이 옵션을 꺼라/켜라고 강요하는 곳이 있긴합니다.


urlencode()를 쓰게끔 어플을 고치면 된다는 뜻인듯 한데요.

설마요.. 그걸로 해결될 거 같았으면 얘기가 이렇게 길어지지도 않았습니다.

----
the smile has left your eyes...

익명 사용자의 이미지

iolo wrote:
Anonymous wrote:
iolo wrote:
Anonymous wrote:
"URL을 항상 UTF8로 보내기" 옵션이 켜있던지 꺼있던지에 관계 없이
작동하게 하는 방법은 그리 어렵지 않습니다.

이 옵션을 끄라고 강요하는 어플이 있나보죠?

어떤 방법이 있나요?

그렇게 할 수 있는 방법이 있다면, 이 논의 자체가 상당히 무의미해질 수 있습니다만...

그리고, 일부 웹사이트에서 이 옵션을 꺼라/켜라고 강요하는 곳이 있긴합니다.


urlencode()를 쓰게끔 어플을 고치면 된다는 뜻인듯 한데요.

설마요.. 그걸로 해결될 거 같았으면 얘기가 이렇게 길어지지도 않았습니다.


물론 완전히 해결되지는 않겠지만 일정정도 맞는 말입니다.

아래의 논의는 "URL UTF-8로 보내기 옵션 켬"이 된 IE와 firefox를 가정으로 얘기하겠습니다.

--- 페이지 인코딩 "euc-kr" ----
<a href="http://kldp.net/한글페이지이름.html">가기</a>

위의 페이지의 내용을 가지는 index.html 있다고 칩시다. 그리고 그 페이지안에 위와 같은 링크가 있고, "한글페이지이름.html"이라는 페이지도 있다고 생각합시다.

IE에서 "URL UTF-8로 보내기 옵션 켬"이 되어있는 상태에서는 위 페이지르 찾을 수 없다고 나와버립니다. firefox에서는 제대로 링크됩니다. 즉, 두 브라우져의 행동이 다르게 나타납니다.

그러나, urlencoding을 하여 다음과 같은 index.html을 만들면
양쪽 브라우져에 문제 없이 작동하게 됩니다.
--- 페이지 인코딩 "euc-kr" ----
<a href="http://kldp.net/%C7%D1%B1%DB%C6%E4%C0%CC%C1%F6%C0%CC%B8%A7.html">가기</a>

* 아파치+리눅스의 일반적인 조합를 가정으로 합니다. 즉, 파일시스템도 euc-kr, 콘텐츠도 euc-kr인 경우를 가정합니다.
* 콘텐츠는 euc-kr인데, 파일시스템은 utf-8인 경우는 위의 동작을 예상할 수 없습니다. (이럴 경우는, utf-8문자열을 urlencoding해서 넣어야 하겠죠.)

raymundo의 이미지

Anonymous wrote:
iolo wrote:
Anonymous wrote:
iolo wrote:
Anonymous wrote:
"URL을 항상 UTF8로 보내기" 옵션이 켜있던지 꺼있던지에 관계 없이
작동하게 하는 방법은 그리 어렵지 않습니다.

이 옵션을 끄라고 강요하는 어플이 있나보죠?

어떤 방법이 있나요?

그렇게 할 수 있는 방법이 있다면, 이 논의 자체가 상당히 무의미해질 수 있습니다만...

그리고, 일부 웹사이트에서 이 옵션을 꺼라/켜라고 강요하는 곳이 있긴합니다.


urlencode()를 쓰게끔 어플을 고치면 된다는 뜻인듯 한데요.

설마요.. 그걸로 해결될 거 같았으면 얘기가 이렇게 길어지지도 않았습니다.


물론 완전히 해결되지는 않겠지만 일정정도 맞는 말입니다.

아래의 논의는 "URL UTF-8로 보내기 옵션 켬"이 된 IE와 firefox를 가정으로 얘기하겠습니다.

--- 페이지 인코딩 "euc-kr" ----
<a href="http://kldp.net/한글페이지이름.html">가기</a>

위의 페이지의 내용을 가지는 index.html 있다고 칩시다. 그리고 그 페이지안에 위와 같은 링크가 있고, "한글페이지이름.html"이라는 페이지도 있다고 생각합시다.

IE에서 "URL UTF-8로 보내기 옵션 켬"이 되어있는 상태에서는 위 페이지르 찾을 수 없다고 나와버립니다. firefox에서는 제대로 링크됩니다. 즉, 두 브라우져의 행동이 다르게 나타납니다.

그러나, urlencoding을 하여 다음과 같은 index.html을 만들면
양쪽 브라우져에 문제 없이 작동하게 됩니다.
--- 페이지 인코딩 "euc-kr" ----
<a href="http://kldp.net/%C7%D1%B1%DB%C6%E4%C0%CC%C1%F6%C0%CC%B8%A7.html">가기</a>

* 아파치+리눅스의 일반적인 조합를 가정으로 합니다. 즉, 파일시스템도 euc-kr, 콘텐츠도 euc-kr인 경우를 가정합니다.
* 콘텐츠는 euc-kr인데, 파일시스템은 utf-8인 경우는 위의 동작을 예상할 수 없습니다. (이럴 경우는, utf-8문자열을 urlencoding해서 넣어야 하겠죠.)

저는 기술적인 내용은 잘 모르겠습니다만...

index.html 내에서 그렇게 링크를 걸어주는 것이라면 urlencoding이 좋은 방법이겠지만, 그렇게 바뀐 URL이 사용자 입장에서는 도저히 외울 수 없는 내용이 된다는게 참 가슴아프죠. :-)

URL을 일일이 외우는 경우가 많지야 않겠지만, 위키의 경우 (KLDP wiki도 마찬가지이고) URL만 봐도 해당 페이지의 내용이 뭔지 짐작할 수 있는 것이 큰 장점인데,
* http://wiki.kldp.org/wiki.php/AlanKay - 이 페이지는 Alan Kay 에 관한 페이지란 것을 쉽게 알 수 있는데
* http://wiki.kldp.org/wiki.php/%BC%BC%B9%FA%BD%C4 - 이것은 들어가보기 전까지는 "세벌식"에 관한 페이지란 것을 알 수가 없죠.
* http://wiki.kldp.org/wiki.php/세벌식 - 이렇게 쓰고도 언제 어디서나 어느 브라우저의 어떤 설정 상태에서도 들어갈 수 있다면 정말 좋을 텐데요. :-) 제 홈도 위키를 쓰는데 한글 페이지 링크를 urlencoding을 하도록 고칠까 몇 번이나 시도하다가도 encoding된 URL을 보면 가슴이 아파서 다시 돌려놓습니다. -.-;

좋은 하루 되세요!

꼬마앙마의 이미지

머리속이 복잡하네요.

문제는 그놈의 "URL을 항상 UTF8로 보내기" 라는것이네요.

저는 이 옵션을 이렇게 이해 했었습니다.

페이지의 인코딩이 euc-kr이면 euc-kr로 보내고,

utf-8이면 utf-8로 보내는것으로 알았죠.

그러니까 항상 UTF8로 보내는건 아니면서도, IE가 알아서 UTF8일때는 UTF8로 보내줄줄 알았죠;;;;

그래서 서버에서 파일 이름이 UTF-8이고,

문자셋이 UTF-8이고, urlencode를 하면 모든것이 OK 인줄만 알았죠...

그런데 그게 문제가 심각한가 보군요.

익명 사용자의 이미지

어떤 사이트에 euc-kr페이지 혹은, utf-8페이지로 된 컨텐츠가 있다고 칩시다.

그리고 그 페이지에
<a href="http://foobar.org/안녕.html">안녕</a>이라는
링크가 있다고 합시다.

브라우져에서 위의 링크를 누르면, 브라우져는 urlencoding을 해서 웹서버측에 요청을 하게 됩니다. IE의 경우에 "UTF-8로 인코딩하기"옵션이 켜있는 경우는, local charset을 unicode charset으로 바꾸어서 utf-8인코딩으로 고친 후에 이것을 urlencoding하게 됩니다.

요청하는 url의 인코딩을 UTF-8이라고 표준으로 못박아둔 이유는 바로, 웹서버측의 파일시스템이 무어냐에 상관 없이, 혹은 웹서버측의 파일시스템이 UTF8을 쓴다고 가정하고 UTF-8로 요청한다고 볼 수 있습니다.

아파치는 불행하게도 자신의 파일시스템이 무어냐에 따라서 다른 방식으로 작동합니다. 파일시스템이 utf-8이냐 euc-kr이냐에 따라서 다르게 작동한다는 것입니다.

IE에서 "URL을 UTF-8로 항상 보내기"는 표준에 맞습니다. 그러나, firefox에서 컨텐츠가 euc-kr인 경우는 euc-kr로 url인코딩을 쓰고 utf-8일 경우는 utf-8로 바꾸는 것은 아파치에 대해서만은 합리적인 선택이라고 생각합니다.

파일시스템의 인코딩과 무관하게 utf-8인코딩된 url을 처리해주는 웹서버가 있나요? (mod_url말고) (이는 비단 웹서버만의 문제뿐만 아니라 ftp서버 등등에도 관련된 문제라고 알고 있습니다만)

익명 사용자의 이미지

iolo wrote:
Anonymous wrote:
"URL을 항상 UTF8로 보내기" 옵션이 켜있던지 꺼있던지에 관계 없이
작동하게 하는 방법은 그리 어렵지 않습니다.

이 옵션을 끄라고 강요하는 어플이 있나보죠?

어떤 방법이 있나요?

그렇게 할 수 있는 방법이 있다면, 이 논의 자체가 상당히 무의미해질 수 있습니다만...

...


예 좀 김빠지는 대답이 되겠지만, "한글.html"이라고 링크를 걸지 않도록 고치면 됩니다. 아예 첨부터 urlencoding을 원하는 character set에 맞게 해버리는거죠. 웹 게시판/어플리케이션 등등이라면 이렇게 미리 urlencoding하도록 만드는 방법은 어렵지 않을것입니다.

그냥 일반 웹페이지라면 스크립트 돌려서, 각 사이트별로 적절한 인코딩을 선택해서 그 인코딩에 맞게 urlencoding하도록 하는거죠.

돌 날아올까봐 도망을 ====333

creativeidler의 이미지

EUC-KR 한글을 URL 인코딩해서 보내는 것은 해결책이 안됩니다. 표면적인 인코딩만 USASCII로 갈 뿐 어차피 그걸 디코딩할 때 EUC-KR이라는 정보를 알아야하기 때문입니다. 지금 논의되는 UTF-8로 보내기는 이런 문제까지 해결하자는 것이죠.

근데, 위에 어떤 분이 웹사이트가 언제 외국에 오픈될지 모른다는 말씀을 하셨는데 사실 컨텐츠가 한글로 되어 있는 상황에서 인코딩만 UTF-8로 되어봐야 의미가 없습니다. 그건 사이트 전체의 요구사항에 국제화가 포함될 때야 비로소 고려 대상이 되는 것입니다. 그러니 국제화 요구사항이 없는 사이트가 한국에서 EUC-KR을 디폴트로 인식한다고해서 개발자를 비난할 수는 없다는 것이죠.

그리고 IE가 UTF-8을 디폴트로 한다면 사이트를 그렇게 개발하면 되지 않느냐.. 맞는 말입니다만, 여기에는 역사적인 이유를 배제할 수가 없죠. 5.0 이전 버전에서는 없었던 기능이고 그 때 개발된 사이트들은 EUC-KR을 가정할 수 밖에 없었습니다. 그런 상황에서 6.0이 나왔다고해서 기존 사이트를 다 뜯어고칠 수는 없는 노릇이니 사용자에게 그 옵션 끄라고 하게 된 것이죠. 역시 개발자의 잘못으로 돌릴 일은 아니라는 생각입니다.

사실 이 문제는 HTML 표준 등의 문제와는 다른 얘깁니다. 개발자 한둘이서 자기 사이트만 잘 만든다고 해결될 문제가 아니라 UTF-8이 de facto standard로 정착되어야하는 문제고 우리 나라의 모든 웹개발자가 머리를 맞대야할 문제입니다.

nohmad의 이미지

creativeidler wrote:
근데, 위에 어떤 분이 웹사이트가 언제 외국에 오픈될지 모른다는 말씀을 하셨는데 사실 컨텐츠가 한글로 되어 있는 상황에서 인코딩만 UTF-8로 되어봐야 의미가 없습니다. 그건 사이트 전체의 요구사항에 국제화가 포함될 때야 비로소 고려 대상이 되는 것입니다. 그러니 국제화 요구사항이 없는 사이트가 한국에서 EUC-KR을 디폴트로 인식한다고해서 개발자를 비난할 수는 없다는 것이죠.

국제화에 대한 특별한 요구가 없더라도 UTF-8 인코딩을 사용하는 것은 잠재적으로 또는 실제적으로 이로울 수 있는 여지가 많습니다. 예를 들어 영한 사전 서비스만 해도 현재 포털들 대부분이 euc-kr을 사용하면서 음성기호를 표시하기 위해 이미지를 사용합니다. 유니코드라면 phonetic symbol 영역이 따로 존재하니 그럴 필요가 없죠. 게시판이나 포럼만 해도 원래 범용성을 목표로 만들어지는데, 다른 나라 문자를 사용할 일이 없다고 미리 용도를 한정하고 euc-kr에 의존하도록 만들 필요는 없는 것입니다. UTF-8을 사용한다고 해서 별다른 추가 노력이 드는 것도 아니니까요. 그외에도 인명, 지명, 작품명 등을 원어 그대로 쓰거나 외국어 학습을 위해 다른 나라의 문자를 사용하는 것이 필요한 상황은 생각보다 많고, 이것을 지원하는 어플리케이션은 당연히 환영받을 것입니다. UTF-8 인코딩은 이 모든 상황에 대해 추가적인 작업을 요구하지 않습니다.

이런 일로 개발자를 비난할 필요도 없고, 또 애써 방어적 행동을 취할 필요도 없습니다. 중요한 것은 국제화(i18n), 다국어화(m17n) 등은 시대적인 요구이고, 이것이 주는 이로움에 대해 동시대의 개발자 및 사용자 모두가 깊이 생각해봐야 한다는 점입니다.

익명 사용자의 이미지

nohmad wrote:
그외에도 인명, 지명, 작품명 등을 원어 그대로 쓰거나 외국어 학습을 위해 다른 나라의 문자를 사용하는 것이 필요한 상황은 생각보다 많고

utf-8로 만들어봐야 글꼴이 없어서리 :roll:
유니코드 전체가 있는 글꼴이 있기는 있나요??

creativeidler의 이미지

Quote:
예를 들어 영한 사전 서비스만 해도 현재 포털들 대부분이 euc-kr을 사용하면서 음성기호를 표시하기 위해 이미지를 사용합니다. 유니코드라면 phonetic symbol 영역이 따로 존재하니 그럴 필요가 없죠.

이건 다른 문제입니다. 이건 HTML 인코딩을 유니코드로 채용하면 깨끗이 해결되는 문제이고 UTF-8로 보낼까 말까랑은 상황이 다르죠. 제가 문제 삼는 것은 현재 상황이 클라이언트에서 UTF-8로 보낼 것을 가정할 수 있는 상황이 아니기 때문에 일단 EUC-KR을 가정할 수 밖에 없다는 것입니다.

그리고 국제화 요구사항이 생길지도 모른다는 가능성은 물론 있습니다만 비즈니스에서 모든 가능성을 반영하진 않습니다. 오히려 그 요구사항이 구체화되면 그 때 바꾸는 게 이득일 수 있죠. 이건 어디까지나 개개의 기업에서 판단해야할 문제지 가능성이 있으니까 하는 게 좋다..는 식은 좋은 논리가 아니라고 생각됩니다.

Quote:
UTF-8 인코딩은 이 모든 상황에 대해 추가적인 작업을 요구하지 않습니다.

이건 사실이 아닙니다. 이게 되려면 무엇보다 클라이언트에게 UTF-8로 보낼 것을 체크하도록 요구해야합니다. 이건 어떤 프로그래밍 부담보다도 큰 부담이죠. 만약 UTF-8로 보내는 설정이 일반적으로 널리 퍼져 있다면 좋겠지만 현실은 그 반대이므로 지금은 분명히 추가 비용이 지출되는 상황입니다. 지금 상황에서 혼자만 UTF-8로 보냄으로 체크하는 것을 기준으로 사이트를 만들면 엄청난 유저들의 항의에 부딪혀야할 것입니다.
wkpark의 이미지

iolo wrote:
URL을 UTF8로 보내는게 표준? 그런가요?
간단하게 말씀들 하시지만, 생각보다 복잡한 문제입니다.

제가 알기로는 애초에 URL에는 인코딩은
"US-ASCII charset을 기준으로 하고, US-ASCII영역외의 문자나 특정 문자(=, /, _, & 이런것들이죠)에 대해서 흔히말하는 URL 인코딩(%인코딩)을 한다"가 표준이라고 알고 있습니다.(rfc2616)

예를들면:

http://xxxx/yyyy.cgi?param1=ABC&param2=한글

이라고 하면 저 '한글'이라는 부분을 어떻게 할것인가의 문제인 거죠.

표준에 근거하여 %인코딩을 한다면... US-ASCII영역 밖의 charset은 EUC-KR인가 UTF-8인가? 참조할 charset이 없으며 US-ASCII인데... 거기에는 '한', '글'을 표현할 방법이 없다는 겁니다. GET요청 자체가 HTTP의 Content-Type헤더보다 먼저나오고 상위 수준의 헤더니 참조할 charset이 없다는 거죠. 곤란하죠 -.-;;

그래서 그 "기본 charset"이 US-ASCII가 아니고 UTF-8이라면, '한글'이라는 부분을 UTF-8을 기준으로 %인코딩하거나, 아예 안하면 되는 거죠.

그러면 IE식의 UTF8로 보내기가 좋은 해결책이 아니냐라고 생각할 수 있지만, 몇가지 문제점이 있습니다.
첫째는, 표준에 근거한 것이 아니다. 즉, 서버에게 charset을 UTF8로 간주하라고 주장할 근거가 없다는 것입니다.
둘째는, GET요청이 아닌 경우에는 어떻게 할것인가? 즉, HTTP본문 안쪽에 들어간 POST 데이터들도 해당 되는가의 문제입니다. 이 경우에는 Content-Type헤더에 charset을 명시해줄 수 있으므로 UTF8로 해야할 이유가 별로 없다는 거죠. 실제로 IE도 UTF8로 보내기는 GET에만 적용됩니다. Content-Type에 charset을 명시하지 않고 POST로 한글 데이터를 보내면 서버쪽 응답에서 사용한 charset이 사용됩니다.

예를 들어,
Content-Type:text/html;charset=EUC-KR인 웹 페이지에
다음과 같은 내용이 있다고 해보면:

<a href="xxx.cgi?value=한글">링크</a>

<form action="xxx.cgi" method="post">
<input type="text" name="value" value="한글">
<input type="submit">
</form>

xxx.cgi가 받는 value의 값은 EUC-KR일까요? UTF-8일까요?
....


흠 읽다가 이상한 점이 있어서 글 남깁니다.

form의 input 혹은 textarea항목으로 해서 post/get으로 넘기면,
각 필드는 모두 페이지의 인코딩에 의존적으로 보내집니다.
IE, firefox 모두 같습니다.
음.. 다시 말해서 데이타를 전혀 가공하지 않고 단지 url인코딩해서 보내기만 하는것이 되겠군요.

온갖 참된 삶은 만남이다 --Martin Buber

iolo의 이미지

wkpark wrote:
iolo wrote:

예를 들어,
Content-Type:text/html;charset=EUC-KR인 웹 페이지에
다음과 같은 내용이 있다고 해보면:

<a href="xxx.cgi?value=한글">링크</a>

<form action="xxx.cgi" method="post">
<input type="text" name="value" value="한글">
<input type="submit">
</form>

xxx.cgi가 받는 value의 값은 EUC-KR일까요? UTF-8일까요?
....


흠 읽다가 이상한 점이 있어서 글 남깁니다.

form의 input 혹은 textarea항목으로 해서 post/get으로 넘기면,
각 필드는 모두 페이지의 인코딩에 의존적으로 보내집니다.
IE, firefox 모두 같습니다.
음.. 다시 말해서 데이타를 전혀 가공하지 않고 단지 url인코딩해서 보내기만 하는것이 되겠군요.

이 부분을 말씀하시는 것인가요?
원규님 말씀이 맞습니다. 제가 말하고자하는 내용도 별로 다르지 않습니다만...

항상 UTF-8로 보내기의 문제점은, '항상'이 아니라는 거죠.
표준에는 같은 GET메소드인데 왜 어떨 때는 UTF8이고 어떨 때는 EUC-KR인가요?
그렇다고 정말 '항상' UTF-8로 보내면(페이지의 인코딩을무시하고) 그것도 곤란하지 않을까요?
밑에 제시된 IRI표준에 따른다면(확 줄여서 얘기하면 항상 UTF8을 쓰고 특수문자들과 US-ASCII외의 문자들은 %인코딩한다는 것인데요...)
그렇다면 이것은 지금 IE처럼 한다는 것인가요? 아니면 정말 '항상' UTF-8로 보내야한다는 것인가요?

UTF-8로 가는 길은 아직도 멀고도 험난한것 같습니다.

제 경우에는 어떤 웹 어플리케이션을 짜더라도 IE의 항상 UTF-8로 보내기 옵션에 의지하지 않습니다. 그것이 세팅되어 있던 말던... 상관없이 돌아가도록 하는 것입니다.(밑에 어떤 분이 url encode를 항상해주면 된다고 하셨는데... 그 정도는 아니구요-.-;)

일단, 가능하면 문자열 파라메터를 GET으로 넘기지 않습니다.
그리고 혹시 넘겨야할 경우가 있을때는 제 쪽에서 먼저 Base64(base64한 결과는 %인코딩을 모두 무사통과하므로 urlencode에 비해 크게 효율이 떨어지지 않습니다)해버립니다. 물론 그 문자열을 받는 쪽과는 어떤 문자셋을 쓸것인지 사전 약속이 되으니 문제가 없습니다. 그 약속마저 불분명할때는 소위 말하는 카멜 인코딩을 해버립니다.

----
the smile has left your eyes...

wkpark의 이미지

iolo wrote:
wkpark wrote:
iolo wrote:

예를 들어,
Content-Type:text/html;charset=EUC-KR인 웹 페이지에
다음과 같은 내용이 있다고 해보면:

<a href="xxx.cgi?value=한글">링크</a>

<form action="xxx.cgi" method="post">
<input type="text" name="value" value="한글">
<input type="submit">
</form>

xxx.cgi가 받는 value의 값은 EUC-KR일까요? UTF-8일까요?
....


흠 읽다가 이상한 점이 있어서 글 남깁니다.

form의 input 혹은 textarea항목으로 해서 post/get으로 넘기면,
각 필드는 모두 페이지의 인코딩에 의존적으로 보내집니다.
IE, firefox 모두 같습니다.
음.. 다시 말해서 데이타를 전혀 가공하지 않고 단지 url인코딩해서 보내기만 하는것이 되겠군요.

이 부분을 말씀하시는 것인가요?
원규님 말씀이 맞습니다. 제가 말하고자하는 내용도 별로 다르지 않습니다만...

항상 UTF-8로 보내기의 문제점은, '항상'이 아니라는 거죠.
표준에는 같은 GET메소드인데 왜 어떨 때는 UTF8이고 어떨 때는 EUC-KR인가요?
그렇다고 정말 '항상' UTF-8로 보내면(페이지의 인코딩을무시하고) 그것도 곤란하지 않을까요?...


아.. 표준이 이렇다 저렇다라는 얘기가 아니라, IE의 구현방식에 대해 얘기한건데요,
IE에서 "URL을 UTF-8로 항상보내기"를 체크하면 다음과 같은 url은
UTF-8인코딩으로 바뀌어집니다.

http://wiki.kldp.org/wiki.php/한글
(이것을 주소창에 직접 치면 kldp wiki는 euc-kr인코딩이고, 한글이라는 이름의 페이지가 없기때문에 page가 없다는 메시지가 나오죠. 그리고, "한글"이라는 페이지인자는 utf-8로 인코딩되어 깨져나오죠.

그런데, 다음과 같이 하면 제대로 보입니다.

http://wiki.kldp.org/wiki.php?한글
(주소창에 위와 같이 치면 "한글"이라는 글자가 utf-8로 인코딩되어
인자로 전달되지 않습니다. 그냥 그대로 전달되고, 그런 페이지가
없다는 메시지에도 "한글"이라는 이름으로 정상적으로 표시됩니다)

(모니위키는 path_info를 먼저 사용하고, 그것이 없으면 query string을 파싱해서 페이지이름을 얻어내게끔 되어있습니다)

이게 정말 그런지를 테스트 해보려면 다음과 같은 간단한 php스크립트를 만든 다음에 이 페이지를 열어보세요

<?php

print urlencode($_SERVER['PATH_INFO']).'?';
print urlencode($_SERVER['QUERY_STRING']);

?>

http://chemie.skku.ac.kr/~wkpark/url.php/한글?한글
(IE에서 주소창에 직접 쳐넣어야 합니다.)

?(물음표) 뒤의 query string인자는
utf-8로 인코딩하지 않고 있는데, 이거 IE에서 맞게 구현한것인가요?

IE에서 "URL을 UTF-8로 항상 보냄"이라는 옵션은 URL의 path부분만 UTF-8로 인코딩하지, URL의 query string은 UTF-8로 인코딩해서 보내지 않고 있습니다. rfc에는 분명히
URL는 schema+path+[?+query]로 표현된다고 써있는데, query string도 URL에 포함되고 있는데, IE는 query를 제외한 path만 UTF-8로 인코딩하고 있습니다.

온갖 참된 삶은 만남이다 --Martin Buber

iolo의 이미지

IE의 URL처리는 분명히 정상이 아닙니다.
이것과는 다른 문제일 수도 있겠지만...

예전에 웹프로그래밍을 많이 할때는 ?와 마지막 /의 위치등과 연관되서 어떻게 어떻게 한다는 나름대로의 규칙이 있다는 것을 알았는데, 지금은 정확히 기억이 나지 않는군요.

이것과 같은 원리인지는 모르겠지만, 한가지 기억나는 예는, Content-Dispostion 헤더에 attachment라고 명시하고 다운로드할 파일 이름을 지정해줘도 그것을 무시하고 URL의 마지막 / 이후를 파일 이름으로 간주하던 기억이 나네요. 아마 IE 5.x였던거 같은데 6.x는 어떤지 모르겠습니다만...
웹메일의 첨부파일 내려받기(파일 자체는 웹 경로 밖에 있고), CGI가 파일을 읽어서 클라이언트로 뿌려주는 형태였는데.. IE가 계속 엉뚱한 이름으로 저장할려고 해서 URL끝에 /filename.txt 이런식으로 적어줬던것 같습니다.

그건 그렇고... 원규님이 말씀하신 규칙은, 모르고 한다면 통밥으로 처리해야할 것인데, 저렇게 정리해놓고 보니 한결 명확하군요.
그런데, 쿼리부분은 어떻게 한다는 거죠? 그냥 EUC-KR(윈도니까 CP949?)이 되는 건가요?

----
the smile has left your eyes...

wkpark의 이미지

iolo wrote:
IE의 URL처리는 분명히 정상이 아닙니다.
이것과는 다른 문제일 수도 있겠지만...

예전에 웹프로그래밍을 많이 할때는 ?와 마지막 /의 위치등과 연관되서 어떻게 어떻게 한다는 나름대로의 규칙이 있다는 것을 알았는데, 지금은 정확히 기억이 나지 않는군요.

이것과 같은 원리인지는 모르겠지만, 한가지 기억나는 예는, Content-Dispostion 헤더에 attachment라고 명시하고 다운로드할 파일 이름을 지정해줘도 그것을 무시하고 URL의 마지막 / 이후를 파일 이름으로 간주하던 기억이 나네요. 아마 IE 5.x였던거 같은데 6.x는 어떤지 모르겠습니다만...
웹메일의 첨부파일 내려받기(파일 자체는 웹 경로 밖에 있고), CGI가 파일을 읽어서 클라이언트로 뿌려주는 형태였는데.. IE가 계속 엉뚱한 이름으로 저장할려고 해서 URL끝에 /filename.txt 이런식으로 적어줬던것 같습니다.

그건 그렇고... 원규님이 말씀하신 규칙은, 모르고 한다면 통밥으로 처리해야할 것인데, 저렇게 정리해놓고 보니 한결 명확하군요.
그런데, 쿼리부분은 어떻게 한다는 거죠? 그냥 EUC-KR(윈도니까 CP949?)이 되는 건가요?


방금 FireFox, IE 모두 테스트해보았습니다.

?(물음표) 이하 query string은 그냥 EUC-KR(CP949)로 보내지는군요
(IE/FireFox 모두 같습니다. ㅤㅎㅐㅎ=>%C1d)

query string을 제외한 URL(schema+path)은 IE의 경우는 UTF-8, FireFox는 EUC-KR(CP949") (IE에서는 URL을 UTF-8로 보냄을 켬)

form으로 해서 input/textarea로 넣어서 GET을 하는 경우는
페이지의 인코딩에 맞춰서 넘겨주고요 (IE/FireFox 모두 같습니다)
(즉, 인코딩의 변환 없이 그냥 raw로 urlencode)

온갖 참된 삶은 만남이다 --Martin Buber

iolo의 이미지

wkpark wrote:
iolo wrote:
IE의 URL처리는 분명히 정상이 아닙니다.
이것과는 다른 문제일 수도 있겠지만...

예전에 웹프로그래밍을 많이 할때는 ?와 마지막 /의 위치등과 연관되서 어떻게 어떻게 한다는 나름대로의 규칙이 있다는 것을 알았는데, 지금은 정확히 기억이 나지 않는군요.

이것과 같은 원리인지는 모르겠지만, 한가지 기억나는 예는, Content-Dispostion 헤더에 attachment라고 명시하고 다운로드할 파일 이름을 지정해줘도 그것을 무시하고 URL의 마지막 / 이후를 파일 이름으로 간주하던 기억이 나네요. 아마 IE 5.x였던거 같은데 6.x는 어떤지 모르겠습니다만...
웹메일의 첨부파일 내려받기(파일 자체는 웹 경로 밖에 있고), CGI가 파일을 읽어서 클라이언트로 뿌려주는 형태였는데.. IE가 계속 엉뚱한 이름으로 저장할려고 해서 URL끝에 /filename.txt 이런식으로 적어줬던것 같습니다.

그건 그렇고... 원규님이 말씀하신 규칙은, 모르고 한다면 통밥으로 처리해야할 것인데, 저렇게 정리해놓고 보니 한결 명확하군요.
그런데, 쿼리부분은 어떻게 한다는 거죠? 그냥 EUC-KR(윈도니까 CP949?)이 되는 건가요?


방금 FireFox, IE 모두 테스트해보았습니다.

?(물음표) 이하 query string은 그냥 EUC-KR(CP949)로 보내지는군요
(IE/FireFox 모두 같습니다. ㅤㅎㅐㅎ=>%C1d)

query string을 제외한 URL(schema+path)은 IE의 경우는 UTF-8, FireFox는 EUC-KR(CP949") (IE에서는 URL을 UTF-8로 보냄을 켬)

form으로 해서 input/textarea로 넣어서 GET을 하는 경우는
페이지의 인코딩에 맞춰서 넘겨주고요 (IE/FireFox 모두 같습니다)
(즉, 인코딩의 변환 없이 그냥 raw로 urlencode)

IE 나름의 처리 원칙이 있다니, 그나마 다행입니다만 역시 '나름'이라는 것이 문제겠죠. 어쨌든 원칙이 없는 것 보다는 백배 낳은 상황입니다.

파이어폭스가 path부분을 EUC-KR로 보낸 것은 해당 시스템의 로케일이 ko_KR.EUC-KR (윈도 포함)이기 때문이거나, 파이어폭스 옵션에서 한글 우선 설정들을 했기 때문이 아닐까요?

이게 페이지 안에 포함된 링크(위치창에 입력하고 엔터치는 경우가 아닌)라면 문제가 또 달라지죠. 물론 HTTP 프로토콜 입장에서는 둘다 GET 메소드이고 동일하죠.

그 웹 페이지의 문자셋(정확한 표현을 하자면 charset encoding이겠지만 url encoding과 헷갈리는 것 같아서 이 쓰레드에썬 계속 문자셋이라고 썼습니다)이 EUC-KR이라면(그 페이지의 헤더에 Content-Type:text/html;charset=EUC-KR이 있었다면) 그 페이지 (바디) 안에있는 링크의 url은(path는? query는?) 어떤 문자셋을 쓸까요(써야 할까요)?

계속 맴도는 것 같습니다만... 역시 답이 보이지 않네요-.-;

전 그냥 url 표준에 이런 사전 정의된 query 파라메터가 하나 생겼으면 좋겠습니다.

http://xxx/yyy.cgi?a=b&c=한글 &charset=EUC-KR

그리고 각 브라우져의 세팅에 저기에 사용할 기본값을 지정할 수 있으면 되지 않을까요?

그게 아니라면 email에서 사용버 방법을 그대로 채용해줬으면 좋겠습니다. 카멜인코딩 말이죠... (RFC1521인가요?)

제가 RFC를 제안하고 자시고 할 위치도 아니고, 능력도 안되지만 어떤식이든 명확하게 해줬으면 좋겠네요. 아예 안되면 안된다고 하는 게 낫지... 지금의 urlencoding(%인코딩)은 없느니만 못합니다.

----
the smile has left your eyes...

익명 사용자의 이미지

日本語テストです。

익명 사용자의 이미지

日本語テストです。