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

+1입니다.

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

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

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

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

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

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

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

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

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로 변경하는 큰 틀의 접근이 필요하다.

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

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

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

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

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

말씀하신 "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의 문제로 인식이 되는 경우가 많으니. 이를 자기들 편한 방법으로 해석하고, 해결책을 제시하고, 사용자(개발자)의 문제로 떠넘기는 것입니다.

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

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

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

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

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

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

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

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

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

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

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

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

저도 동의합니다. 개발자의 입장에서, 뭔지 모를 때는 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 입장에선 좋은 전략일지 몰라도, 그 전략에 발맞추지 않는다고 개발자들(예를 들면 아후사전개발자)를 비난할 근거는 못됩니다.

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

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

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

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

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

어떤 방법이 있나요?

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

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

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

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

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

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

머리속이 복잡하네요.

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

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

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

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

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

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

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

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

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

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

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

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

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

항상 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에 비해 크게 효율이 떨어지지 않습니다)해버립니다. 물론 그 문자열을 받는 쪽과는 어떤 문자셋을 쓸것인지 사전 약속이 되으니 문제가 없습니다. 그 약속마저 불분명할때는 소위 말하는 카멜 인코딩을 해버립니다.

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

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

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

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

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(%인코딩)은 없느니만 못합니다.