성철님이 제안하신 방법이 현재로써는 가장 합리적인 방법 같네요.

누가 시간을 내어서 한국어용 데이터베이스 문자셋을 euc-kr 대신에 ksc5601fix(? 확장완성형)로 대체할 수 있도록 PostgreSQL 지원 문자셋을 하나 만들어서 PostgreSQL 개발진에게 보내주면 모든게 깔끔하게 해결날 문제인데, 누가 할지.

도전하는 사람은 아름답습니다. :)

확장 완성형 코드 표가 어디에 있나요? 별로 어려운 작업은 아닐 것 같은데...

그리고 지금의 문제는 확장 완성형 코드가 구현되어 있지 않기 때문이 아니라 멀티바이트 문자의 경우 모든 바이트의 첫 비트가 1로 set되어 있다고 가정하고 이것이 아닐 경우 에러를 내는 것 같거든요? 그러니 멀티바이트 개발자(일본에 계신 것 같은데)에게 이 코드의 의도를 물어보고 이 전제가 한글의 경우는 틀리다는 것을 알려주어 고치게 하는게 나을 것 같다는 생각이 듭니다. 좀더 연구를 해보고 메일을 한번 보내보죠뭐... 전에도 다른일로 메일을 보냈는데... 제 영어가 엉터리라서인지.. 답장이 안오더군요. -.-;;

그리고 확장 완성형 코드가 구현되면 unicode로 변환될때에 글자가 깨어지지 않겠네요... 근데 지금은 깨어지는지 모르겠네요. db를 unicode로 하고 client쪽을 euc-kr로 한 다음에 '아햏햏'을 입력을 하면 어떻게 되는지... test 해봐야겠네요.

convert 작업일 경우, 아햏햏 같은 경우는 깨어집니다. 현재 euc-kr 코드표만 있거든요.

이놈 수정은 별로 어려운 것이 아닌데,

그 pg_verifymbstr() 함수의 문제는 좀 더 까다롭더라구요. 단순히 '첫번째 비트를 1로 하는 것 만이 멀티바이트 문자셋이 아니다' (현재 패치방법) 이게 아니더라구요. 왜냐하면, 가령 \xbc\x00 같은 깨어진 한글 같은 경우는 분명 잘못된 문자열인 관계로 저 pg_verifymbstr() 함수에서 걸려줘야하는데, 못걸려지는 경우가 종종있습디다.

확장 완성형 문자셋에 대한 것은 제가 찾아서 이곳에 다시 알려드리지요. 지금 좀 바빠서.

지금 찾아보니, 가장 바른 표현은 확장 완성형이라기 보다는 코드 페이지 949 (cp949) 인것같네요.

우리나라에서 국가적으로 제정한 적도 없고, 그렇다고 세계적으로 인정한 것도 없는 단지, M$ 사에서 사용하기 위한 코드 페이지입니다.

이놈에 대한 unicode 맵핑 문서는 아래에 있습니다.

http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/KSC/HANGUL.TXT

구분이 완성형, 확장완성형, 조합형 ... 이런식의 표가 있으니, 참조 하시면 될 듯싶습니다.

아무튼

create database dbname encoding = 'cp949'

이런식이면 모든게  해결 날듯싶네요.

이런 날이 오길.. (한편으로 안왔으면 좋겠지만)

(문자셋 이야기는 모든 것을 떠나서 조합형으로 가야함 - 세종대왕님의 의견을 받들어)

다시 소스를 봤는데,

이미 uhc 라는 이름으로 문자셋을 PostgreSQL에서 지원하는군요.

'아햏햏' 같은 놈은 uhc 로 convert 한다면 해결이 나겠네요.

mydb=# select convert(convert('아햏햏', 'uhc', 'utf8'), 'utf8','uhc');
 convert
---------
 아햏햏
(1 row)

Time: 1.343 ms

그렇다면, database encoding 으로 uhc를 지원하게 하면 이 모든 문제를 해결 할 수 있을 듯싶습니다.

그렇군요. UHC가 지원되는군요.

근데... UHC가 뭐죠? 한 5년 정도 한글 코드쪽 일을 할 일이 없어서 관심을 끊었더니 모르는게 많아졌네요. 쩝...

UHC는 몇달전에 모질라에서 제공을 하면서 보게 되었는데... 어떤 코드인지 모르겠네요. Unified Hangul Code... 뭐.. 이렇게 되는건가요?

저도 시간이 많지 않기 때문에 빨리는 못해도... 천천히... 찾아볼랍니다. postgresql이 한글 문제로 쓰기 뭐한 놈이 되는 것은 참.. 맘이 아파서리...

UHC 이놈이 통칭 확장 완성형입니다.

가장 바른 표현은 cp949 인 것 같습니다.

앞에서 언급했듯이.

문제는 uhc 라고 표현하는 이놈이 client only charset 으로 내정하고 있다는 것이 문제지요.

오늘 저녁 먹고 소스를 차근히 살펴보았는데, euc-kr 대신 uhc 문자셋으로 데이터베이스를 만들 수 있도록 허용하려면 변경 되어야할 부분이 한두가지가 아니더군요. :( 저는 포기 했습니다.

결국 db는 utf-8을 쓰고 클라이언트는 UHC를 쓰면 모든 문제가 해결되는 것이군요.

utf-8의 길자 길이가 고무줄이라서 varchar 같은 type의 길이를 잡는 것이 골치아프다는 것 빼고는....

근데 문제라는게 우습군요. 결국 모든것이 완셩형을 쓰면서 발생한 것인데.... 조합형 썼으면 이런 고민 안해도 되는것을... 으그...

결국 cp949가 국제 표준 수준으로 인정받게 된 상황을 보니 기분 안 좋습니다.

유니코드로 가려면, 100% 유니코드로 가야합니다. 유니코드 <-> uhc 변환 작업이 성능을 떨어뜨리는 결정적 요인으로 작용할 듯싶습니다. 글자가 너무 많아서...

그 변환 작업을 서버가 하든 클라언트가 하든 그 비용을 누군가는 감당해내야하니까요.

지난번 글에서도 똑같은 말이였지만,

현실적으로 가장 합리적인 방안은,

uhc 코드를 database encoding charset으로 지정할 수 있도록 하는 것이고,

그것이 힘들다면, database backend를 해킹하는 방법일 듯싶습니다.

꿈같은 이야기로, 조합형으로 가는 것이 가장 멋지겠지만.

cp949 이놈은 국제표준으로 채택이 된적도 없구요, 한국 내에서도 마찬가지입니다. 단지 거의 모든 사람들이 그 코드 체계를 쓰니까 마지 못해 unicode <-> uhc 의 맵핑이 있는 것 뿐입니다.

나중에 M$ 동네쪽에서 이 cp949 코드체계가 마음에 들지 않는다고 바꾼다면, 충분히 바뀔 수 있는 놈입지요. 멋있는 M$ 동네. (국어 학자들, 전산학자들은 뭐하고 있었나 몰러...)