METHOD URI VERSION

많은 옵션이 붙을 수 있지만 이정도가 페이지를 요청하기 위한 기본 쿼리라고 생각하시면 됩니다. METHOD는 ‘GET’, ‘POST’, ‘HEAD’, ‘OPTION’ 정도가 될 수 있겠고, URI는 PATH + QUERY STRING이라고 생각하시면 되겠습니다.

자 그럼 이걸 응용해 봅시다.

GET /index.php HTTP/1.1

위 코드는 /index.php 페이지를 HTTP/1.1 프로토콜을 사용해서 호출하겠다는 얘기입니다. 여기에 값을 넘겨주려면 QUERY STRING을 사용하면 됩니다.

아래와 같이 var1이란 변수에 1234, var2란 변수에 2345란 값을 담아서 페이지를 호출해봅시다.

GET /index.php?var1=1234&var2=2345 HTTP/1.1

간단하죠. 단 URI의 길이에는 제약이 있기 때문에 이런 방식을 사용할 경우 긴 데이터를 넘겨줄 순 없습니다.

긴 데이터를 넘겨줄 때는 POST를 사용하게 되는데요. POST를 사용해서 값을 넘겨줄 때는 아래와 같은 코드를 사용하게 됩니다.

POST /index.php HTTP/1.1 Content-type: application/x-www-form-urlencoded Content-length: 19 var1=1234&var2=2345

Content-length는 넘겨줄 값의 길이를 의미합니다. 간단하죠. 뭐하튼 값을 넘겨주는 데는 GET과 POST 방식을 사용할 수 있고, GET 방식에서는 값을 URI에 붙여서 보내준다는 얘기를 하고 싶었습니다.

그런데 브라우져마다 GET 방식으로 값을 넘겨줄 때 사용하는 인코딩이 동일하지가 않네요. 예전에 ‘웹 서비스와 UTF-8‘이란 글에 적어놨듯이 RFC2718에서는 URI를 UTF-8로 인코딩할 것을 권고하고 있습니다.

그렇다면

1. euc-kr로 인코딩된 페이지에서 다른 페이지로 값을 GET 방식을 사용해서 넘겨준다면 어떤 인코딩을 사용해야할까요?
2. utf-8로 인코딩된 페이지에서 다른 페이지로 값을 GET 방식을 사용해서 넘겨준다면 어떤 인코딩을 사용해야할까요?
3. 만약 url에 직접 query string을 붙여서 페이지를 요청할 경우에는 어떤 인코딩을 사용해야할까요?

URL을 정의하고 있는 RFC2396에서는 URI를 PATH+QUERY 로 정의하고 있고, 이를 확장한 RFC2718에서 URI를 UTF-8로 인코딩하자고 했으니 위의 모든 경우에서 URI는 utf-8로 인코딩되어야 맞습니다. (단 1번의 경우에는 %인코딩을 사용해서 값을 Escape시켜줘야겠죠.)

하지만 재앙의 근원 Internet explorer에서는 3번과 같은 상황일 때 query string을 로컬 인코딩으로 인코딩해버립니다. ^[1] ajax를 사용할 때 생기는 문제에 비교하면 이 정도는 애교입니다.

1. utf-8 페이지에서 ajax + get으로 값을 전송합니다. 어떤 인코딩으로 값이 전송될까요?
2. euc-kr 페이지에서 ajax + get으로 값을 전송합니다. 어떤 인코딩으로 값이 전송될까요?
3. utf-8 페이지에서 ajax + post로 값을 전송합니다. 어떤 인코딩으로 값이 전송될까요?
4. euc-kr 페이지에서 ajax + post로 값을 전송합니다. 어떤 인코딩으로 값이 전송될까요?

3, 4번의 경우 Internet explorer를 쓰건 safari, firefox등을 쓰건 모두 utf-8로 값이 전송됩니다. (이유는 묻지 마세요. 안찾아봤습니다.) 2번의 경우는 모든 경우에 euc-kr로 값이 전송되구요.

하지만 1번의 경우 분명 utf-8로 값이 전송되어야 할 것 같지만 Internet explorer는 euc-kr로 값을 전송합니다. 상식적으로도 이해가 가질 않지만 그렇게 동작하고 있습니다.

덕분에 utf-8로 값이 넘어왔다고 가정한 프로그램은 오동작을 하게 될 수 밖에 없습니다. 전 정말 Internet explorer를 이해할 수가 없습니다.

상식이 통하는 세상에 살고 싶습니다. Internet explorer 노력하세요.

1. lastmind님이 포스팅하신 ‘On encoding uri with nonascii characters‘에 따르면 Internet explorer에서는 PATH는 utf-8로 (혹은 %인코딩으로) 인코딩하지만 Query string에 대해서는 시스템의 local encoding, 즉 한글 윈도우라면 euc-kr을 사용한다고 하네요.

   그렇다면 영문판 윈도우에서는 어떤 결과가 나올지 궁금하네요.

Related Posts

• 3/16/2009 -- 인터넷 뱅킹과 SSL… 변명은 이제 그만… (2)
• 9/5/2008 -- 매력적인 Internet Explorer 8 Beta2 의 개발툴 (1)
• 10/25/2007 -- 오픈웹과 관련해서… (4)
• 9/4/2006 -- wordpress: korean trackback! (22)
• 1/25/2005 -- 컴퓨터 속의 한글 (22)

하지만 wordpress 기본 파일을 수정할 경우 업데이트를 할 때마다 다시 수정해줘야 하는 번거로움이 있기 때문에 그냥 plugin 을 작성해버렸습니다. 막상 plugin 을 작성하려고 보니 trackback_post 에 대한 action 은 글이 삽입된 이후에 실행되도록 되어 있더군요. 역시 그냥 wp-trackback.php 를 수정해서 사용해야 하는건가 하는 생각이 들었지만, 뭐 정도가 아니면 돌아가면 되는 법!! 이미 데이타베이스에 입력완료된 trackback 을 update 하도록 하는 hack 에 가까운 플러그인이 만들어져버렸습니다. -_-v

혹시나 필요한 분은 아래 url 에서 받아서 사용하시면 되겠습니다.

http://mytears.org/resour...korean_trrackback-1.0.zip

p.s) wind-like 님이 수정하신 버젼과는 다르게 ‘트랙백을 받는 경우’ 하고만 관련이 있습니다.

Related Posts

• 1/25/2005 -- 컴퓨터 속의 한글 (22)
• 2/2/2009 -- 워드프레스 2.7을 위한 Trackback for Korean 패치 (6)
• 9/14/2006 -- wordpress: 최근 추가한 플러그인들… (4)
• 8/13/2005 -- proftpd: codeconv module (5)
• 1/29/2009 -- wp-codebox, wp-openid 버그 패치 (4)

해당 쓰레드: http://forum.standardmag.org/viewtopic.php?id=189

예전에 웹메일을 만들어볼 땐 RFC 는 찾아보지 않고 그냥 여러가지 케이스를 놓고 이렇게 구성되어 있구나 정도만 알고 있었는데… RFC 문서에 제약조건들이 상세히 설명되어 있군요… (당연한거지만)

1. ASCII 케릭터가 아닌 경우 =?charset?encoding?encoded-text ?= 의 형태로 인코딩 되어야 한다
2. encoded text 는 75자를 넘으면 안된다 (charset, encoding, delimiters 포함!)
3. 75자 이상이 나와야 하는 경우는 여러 줄로 나눠 쓰는 건 문제가 되지 않는다…
4. encoded text 사이의 white space 는 무시된다

대략 이정도로 정리가 되네요… 하튼 재밌어 보여서 코드를 구현해봤습니다… 처음엔 그냥 단순하게 75자 단위로 되도록 wordwrap 을 이용해서 잘랐었는데… 그렇게 할 경우에 글자와 글자 사이에서 잘리는 경우가 생길 수 있어 문제가 된다는군요…

예전에 그런 식으로 마구마구 보내진 경우 때문에 디코딩 함수를 좀 묘하게 짰었는데… 그게 메일발송 프로그램 쪽에서 잘못한 거 였나보군요…

뭐 그래서 글자를 utf-8 이라고 가정해버리고 글자들의 경계에서만 잘리도록 함수를 만들어 봤습니다… (요샌 이런 간단간단한 코드를 짜는게 재밌네요) 예전 xchat 의 딩딩 바이러스를 해결할 때에 사용했던 glib 의 utf8_validation 형태를 빌려봤는데… 우선 대강 잘 동작합니다…

다 만들어놓고 저 쓰레드에 또 한 번 “그렇게도 만들어봤어요~” 식으로 올려볼까 했는데 신정식님이 더 멋지게 만들어놨길래… 흑흑;;; 그냥 제 블로그에만 포스팅을!! 조금 더 효율적으로 고칠만한 부분들이 있긴 한데… 건들기가 귀찮네요… 꺄하하핫;;

rfc2047: http://www.faqs.org/rfcs/rfc2047.html
코드: http://mytears.org/resour...mysrc/php/base64/test.php

Related Posts

• 8/13/2005 -- proftpd: codeconv module (5)
• 1/25/2005 -- 컴퓨터 속의 한글 (22)
• 9/4/2006 -- wordpress: korean trackback! (22)
• 3/7/2005 -- 웹서비스와 utf-8 (1)
• 2/19/2005 -- 스팸과의 전쟁 -_-!! (5)

얼마 전 젠투 한국 사용자그룹의 유리님의 개인 portage-overlay 리스트를 보다가 proftpd 의 charset conversion 패치를 발견했다. 원 출처는 일본 쪽인 듯 싶은데, 이 패치를 적용하면 client 에서 사용하는 charset 과 server에서 사용하는 charset 을 설정하는게 가능해진다.

http://home.h01.itscom.ne...roftpd-iconv/index-e.html

만약 중간에 charset conversion 에 실패했다거나 한 경우 어떻게 처리를 하나 봤더니, 변환에 실패한 글자를 ‘?’ 로 바꿔버리고 있었다. out_buffer size 를 in_buffer size 의 세 배 크기로 할당하고 중간에 에러가 발생하면 무조건 변환이 실패한 것으로 생각하기 때문에 한 글자를 표현하는데 3바이트보다 더 많은 바이트 수가 필요하다면 (ucs2 로는 표현 못하는 글자를 사용하는 경우), 버퍼 오버플로의 희생양이 될 수도 있을 듯 싶다. 그래도 원하는 코드를 삽입하는 건 힘들고 그저 segmentation error 를 부를 뿐이겠지만 찝찝한 건 사실이므로 에러가 발생할 경우 errno 를 참고하도록 패치를 해야겠다.

근데 실제 적용을 해보니 Directory 나 .ftpaccess 를 통한 지역 설정이 허용되지 않는다. 내가 사용하는 폴더들에 한해서 저 패치의 영향을 받게 하는게 목적이었기 때문에 결국 패치를 해버렸다. proftpd 개발자 문서는 서버가 다운되었었는지 참고를 할 수가 없었고, 그나마 미러링 된 곳도 찾을 수가 없어서 한참 헤매긴 했지만!! 결국!! 내가 원하는 데로 패치 성공 -_-v

패치파일:

http://mytears.org/resour...atches/mod_codeconv.patch

mod_autoindex 도 몇 일전에 charset 을 설정해줄 수 있도록 패치했고, 그 외에는 이미 다 준비가 되어 있었기 때문에 누군가 mod_autoindex 의 새로운 테마만 만들어준다면 바로 utf-8 환경으로 넘어갈 수 있을 듯 싶다.

FTP 관련해선 RFC2640 에 있는 것을 구현하는 것이 옳다고 생각하지만 중간 단계로써 mod_codeconv 도 나름의 의미가 있을 듯 싶다.

p.s) 위의 사이트에 나와있는 메일 주소로 패치파일을 보내주려 했지만 메일주소가 죽어있네요.

Related Posts

• 9/4/2006 -- wordpress: korean trackback! (22)
• 11/28/2005 -- RFC2047: Message Header Ext for Non-ASCII (0)
• 8/11/2005 -- apache: mod_autoindex hack!! (3)
• 1/25/2005 -- 컴퓨터 속의 한글 (22)
• 9/19/2006 -- 내가 참여했던 오픈소스 (1)

URIs

Internationalization of URIs is important because URIs may contain all kinds of information from all kinds of protocols or formats that use characters beyond ASCII. The URI syntax defined in RFC 2396 currently only allows as subset of ASCII, about 60 characters. It also defines a way to encode arbitrary bytes into URI characters: a % followed by two hexadecimal digits (%HH-escaping). However, for historical reasons, it does not define how arbitrary characters are encoded into bytes before using %HH-escaping.

Among various solutions discussed a few years ago, the use of UTF-8 as the preferred character encoding for URIs was judged best. This is in line with the IRI-to-URI conversion, which uses encoding as UTF-8 and then escaping with %hh:

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:
URN syntax : RFC 2141 (syntactically, URNs look like a URI scheme, but semantically, they are not)
IMAP: RFC 2192 (the IMAP protocol uses a modified version of UTF-7, but its URIs use UTF-8)
FTP ( RFC 2640 uses UTF-8, but tolerates legacy encodings)
XPointer (W3C Working Draft)

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

위에서 보다시피 RFC2718 에서는 URL 을 UTF-8 로 보내라고 제안하고 있으며, FTP 관련해서는 RFC2640 에서 path name 을 UTF-8 로 넘겨주라고 되어 있다. 그러므로 Internet Explore 에서 ‘URL 을 항상 UTF-8 로 보냄’ 을 해제시키는 것은 올바른 해결법이 아니라고 생각된다.

현재 까지의 대부분의 ftp client 에서 i18n 관련해서 별다른 고려를 하지 않고 있었기 때문에 path name 을 client 의 legacy charset 을 이용해서 넘겨주도록 구현되어 있다. 그렇기 때문에 (한글 기준으로) euc-kr 로 된 path name 이 사용되어 왔고 결국 server 측에도 euc-kr 로 저장되고 있는 실정이다.

그런 상황이다 보니 위의 권고안 대로 URL 을 UTF-8 로 넘겨주는 경우 실제 파일을 찾지 못하고 ‘404 Page Not Found’ 를 만나게 될 수 밖에 없는 것이다.

해결책은 간단하다고 생각한다. RFC2640 이 구현된 FTP server/client 를 사용하게 될 경우 자동으로 path name 에 UTF-8 을 사용하게 되므로 server 측에서 path name 에 별다른 조작을 가하지 않는 이상 filename 에 UTF-8 로 사용하게 될테고… 결국 UTF-8 로 된 URL 을 아무 문제없이 파일을 처리할 수 있게 된다.

얼른 이런 것들이 흥보가 되고 널리 쓰이게 되서 ‘URL 을 항상 UTF-8 로 보냄’ 을 체크해제 하라는 말을 안볼 수 있는 세상이 왔음 좋겠다 -_-;;

p.s) 현재 RFC2640 이 구현되어 있는 건 filezilla 밖에 모르겠네요. proftpd 의 경우 1.3.1rc 버젼부터 rfc2640 을 지원합니다.

Related Posts

• 11/28/2005 -- RFC2047: Message Header Ext for Non-ASCII (0)
• 8/13/2005 -- proftpd: codeconv module (5)
• 1/25/2005 -- 컴퓨터 속의 한글 (22)
• 3/25/2009 -- ajax와 encoding 문제… (2)
• 1/23/2009 -- Punbb update (0)

우선 한글은 조합형, 완성형, 확장 완성형, iso2022-kr, unicode 등으로 표현이 가능하며… 조합형, 완성형, 확장 완성형, iso2022-kr 등은 symbol table 과 한자 테이블 또한 가지고 있지만 여기서 관련된 내용은 거의 얘기하지 않을 겁니다.

1. 조합형 (Johab)

   ASC II 범위에 있는 글자는 그대로 프린트하고 한글인 경우 MSB 를 1로 세팅하고 나머지 비트를 초성(5bit) / 중성(5bit) / 종성(5bit) 을 표현하는데 사용한다. 이론 상으로 한글 11172 자를 모두 표현해낼 수 있으며 한글 입력을 처리하기가 아주 쉽다. 다만 Microsoft 에서 완성형을 선택함에 따라 잊혀진 인코딩이 되어가고 있다.

2. 완성형 (EucKR)

   ksx1001 에 정의되어 있으며 역시나 ASC II 범위의 글자는 그대로 프린트 한다. 한글의 경우 연속된 두 개의 바이트를 이용해서 표현하게 되며 첫번째 바이트와 두번째 바이트 모두 0xA1~0xFE 사이의 값을 가진다.

   한글은 2350 자 밖에 지원하지 않지만 MS windows 에서 선택함에 따라 널리 사용되고 있다.

3. 확장완성형 (Unified Hangul Code)

   Microsoft 에서 EucKR 에 몇 가지 글자를 더 추가한 인코딩으로 UHC, cp949 등으로도 불린다. 빈 공간에 글자를 추가해 넣었기 때문에 바이너리 값 그대로 정렬을 시도할 경우 한글의 가나다라 순서대로 정렬되지 않는 문제가 있다.

   EucKR 과 마찬가지로 한글을 표현하는데는 2바이트를 사용하며 첫번째 바이트는 0×81~FE 사이 두번째 바이트는 0×41~5A, 0×61~7A, 0×81~FE 영역을 차지한다.

4. iso2022-kr

   EucKR 을 7bit 만 사용하며 표현하는 방식으로 RFC1557 에 정의되어 있다. Designator Sequence (0×1B 24 29 43), SO (0×0E), SI (0×0F) 등을 이용해 EucKR 을 7bit 로 변환시킨다.

   Designator sequence 는 non ASC character 를 만나기 전에 아무 때나 한 번만 나와주면 되며, non asc character 를 만나면 SO 를 출력 후 다시 asc character 를 만날 때까지 0×7F 와 AND 연산을 해서 출력한다. (MSB 를 reset) 그러다가 asc character 를 만나게 되면 SI 를 찍고 나서 다음 글자들을 프린트하면 된다. 이런 과정을 반복하면 EucKR 은 iso2022-KR 로 변환된다.

   그 과정을 pseudo code 로 표현하자면 (위에 설명이 좀 복잡하게 보이는데 실제로 보면 간단하다.)
   print 0x1B 0x24 0x29 0x43 // Designator Sequence stats = asc while( char = get_next_char() ){ if( stats == asc ){ if( char & 0x80 ){ print 0x0E // SO stats = non_asc } } else{ if( !(char & 0x80) ){ print 0x0F // SI stats = asc } else char &= 0x7F; } print char }

   (위의 pseudo code 에서는 Designator Sequence 를 맨 앞에 출력을 했지만 iconv 등에서는 처음으로 non asc character 를 만났을 때 출력하고 있다.)

위의 네가지 인코딩 이 그동안 많이 쓰여왔던 인코딩 들인데 국제화 시대인 지금은 오로지 한글만을 표현할 수 있는 저런 인코딩으로는 뭔가 부족하다. 그렇기 때문에 유니코드 콘소시움에서는 여러가지 언어를 함께 표현할 수 있도록 unicode 라는 글자집합(character set)을 만들어 냈으며, 유니코드를 표현하는 5가지의 encoding 을 제공하고 있다. (ucs2, ucs4, utf-7, utf-8, utf-16)

1. ucs2

   2바이트 고정형 인코딩, unicode 와 4.0 버젼과 동일하다. Endian 관련해서 Big Endian 과 Little Endian 으로 표현이 가능하다.

2. ucs4

   4바이트 고정형 인코딩. 길이를 제외하곤 ucs2 와 거의 동일하다.

3. utf-7

   unicode 의 mail safe version. RFC1642 에 정의되어 있다. BASE64 와 비슷한 방식을 통해 unicode 를 7bit 로 표현하게 된다.

4. utf-8

   가변형 인코딩으로 1바이트영역은 Asc II 와 100% 호환된다. 0×00 이 사용되지 않으므로 전통적으로 C 언어에서 사용해온 null terminated 방식을 사용하는데 문제가 없고 2바이트 이상을 사용하는 경우 특수한 규칙을 가지고 있기 때문에 validation 이 가능하다.

5. utf-16

   ucs2 와 ucs4 를 적절하게 혼합해서 사용하는 방식으로 BMP (Basic Multilingual Plane) 에 들어있는 글자는 2 바이트로 표현하게 되고 그 외의 글자들은 4 바이트를 이용해서 표현하게 된다.

utf-7 과 utf-8 을 제외하고는 byte order 가 중요시 되기 때문에 BOM(Byte Order Mark) 를 문서 맨 앞에 삽입해야 한다. 그렇기 때문에 Unicode 로 작성된 텍스트 파일의 경우 BOM 을 이용해 어떤 인코딩을 사용하는 지지 알아내는게 가능하다. (utf-8 을 위한 BOM 도 존재하지만 utf-8 의 경우 Byte Order 가 정해져 있기 때문에 BOM 을 의무적으로 삽입할 필요는 없다.)

대강 ucs2, ucs4, utf-8, utf-16, utf-32 의 특징을 정리하면 위의 표와 같다. UTF-8 의 경우엔 ASC II 와 호환이 되기 때문에 영어권 언어들에서 별다른 조작 없이도 문제를 일으키지 않게 되므로 널리 쓰이고 있다. UTF-8 과 UCS2 사이의 변환은 아래와 간단한 규칙을 통해 이루어지게된다.

1. 0×00~0×7F 까지는 그냥 표시한다.
2. 0×80~07FF 까지는 B110xxxxx 10xxxxxx (2바이트)
3. 0×0800-FFFF 까지는 B1110xxxx 10xxxxxx 10xxxxxx (3바이트)
4. 이후는 UCS4 영역이고 위와 같은 방식으로 4바이트까지 확장됩니다.

보다시피 ASC II 는 그대로 표현하고 있습니다. 그리고 2바이트 이상을 사용하는 문자에서는 2진수 기준으로 앞에 붙어있는 1의 개수가 그 글자를 표시하는데 사용된 바이트 수를 나타내며, 2번째 바이트부터는 맨 앞에 10 을 붙여줌으로 이건 글자의 시작이 아니라는 걸 표시하게 됩니다. 위의 두 규칙을 지키면서 unicode 를 2진수로 바꾸어 xx 로 표시된 영역에 차례로 배치하게되면 ucs -> utf-8 변환은 끝이 납니다. 한글은 UTF-8 로 표현하게 될 경우 한 글자 당 3 바이트 씩을 차지하게 됩니다.

그리고 이 유니코드에서 한글이 차지하는 영역은 아래와 같습니다.

1. U+1100: 조합형 영역

   첫가끝 코드라는 이름으로도 불리고 있으며 초성(첫), 중성(가운데), 종성(끝)이 각기 다른 영역에 배치되어 있다. 이 영역에 있는 글자들을 이용하면 한글 고어까지도 표현이 가능해진다.

   한글 한 글자를 표현하는데 많은 저장공간이 필요하다는 점과, iconv 에서 첫가끝 영역 -> Euc-KR, iso2022-kr, UHC 로의 변환이 불가능한 점 등이 약간의 문제라고 생각됨.

2. U+3130: 한글 자모 영역

   ㄱ,ㄴ,ㄷ,ㄹ, … , ㅏ,ㅑ,ㅓ,ㅕ, … 등의 자음과 모음이 배치되어 있는 영역

3. U+AC00: 완성형 영역

   가각… 같이 이미 완성되어 있는 한글 케릭터가 11172 자 배치되어 있다.

Link:

• http://mytears.org/resources/doc/Hangul_Code/
• http://www.jinsuk.pe.kr/U...ode/Unicode_intro-kr.html
• http://ko.wikipedia.org/wiki/UTF-8
• http://ko.wikipedia.org/wiki/UTF-16
• http://unicode.org
• http://www.unicode.org/charts/PDF/U1100.pdf
• http://www.unicode.org/charts/PDF/U3100.pdf
• http://www.unicode.org/charts/PDF/UAC00.pdf

Related Posts

• 9/4/2006 -- wordpress: korean trackback! (22)
• 11/28/2005 -- RFC2047: Message Header Ext for Non-ASCII (0)
• 8/13/2005 -- proftpd: codeconv module (5)
• 3/25/2009 -- ajax와 encoding 문제… (2)
• 8/11/2005 -- apache: mod_autoindex hack!! (3)