그런 것 같더군요. 내부적으로 ucb2로 변환하는 것 같았습니다. 굳이 그럴 필요가 있을지 의문인데요. 이럴 것이면 서버 인코딩 옵션을 utf-8과 ucb2로 선택할 수 있도록 해서 한국, 일본, 중국의 경우에는 ucb2를 사용하게 했었으면하는 생각이 드네요.

국제화 담당하시는 분이 일본분이신데... 무슨 이유가 있겠죠?

저희도 PHP에서 작업중 위와 동일한 에러를 만났습니다....

어떻게 대처 해야 하는 지요....

서버 postgres 7.4.6 -- unicode 로 생성해서 사용중....

도움을 부탁드립니다.   ^-^  감사...

$body = preg_replace_callback('/./u', 'escapeucs4', $body);

body 는 utf8 이고요.

4bytes 부터 ucs4 로 판단하고, & # 40323;(붙여서) 요런식으로 ucs4 를 10진수문자열로 바꾸세요.

utf8 -> ucs 는 계산만으로 변환이 되고, 구글링 하면 금방 나옵니다.

맘에들진 않지만 한글자 한글자 판단할 수 밖에요.

잠깐 소스를 봤는데 UTF-8을 UCS-2로 변환해서 처리하는 부분이 없는 것 같은데 굳이 이런 에러를 내는 이유를 모르겠네요.

Java 처럼 모든 문자를 내부적으로 unicode로 처리하는 것도 아니고 서버 인코딩된 그 문자를 그대로 내부에서도 쓰고 있거든요?

그리고 utf-8과 다른 문자 인코딩간의 변환 과정에서도 UCS-2는 사용되지 않습니다.

지금 문제가 되는 오류도 특별히 UCS-2로 변환하는 과정에서 어쩔 수 없어서 내는 오류가 아니라 유용성 검사를 하는 과정에서 발생 시키네요.

제 생각에는 UCS-4에 해당하는 언어의 고유 인코딩을 지원하지 않고 있기 때문에 이런 오류 메세지를 출력하는 것 같습니다. 클라이언트와 서버 양쪽에서 순전히 unicode로만 사용한다면 특별히 이런 검사를 할 필요는 없어 보이네요.

그런데 궁금한 것이.. UCS-4 영역을 쓸 일이 있나요? 제가 요즘 동향을 전혀 몰라서 그러는데 UCS-4 영역에 한글이나 한자가 추가 되었나요? MS나 Java에서도 UCS-2만 쓰고 있는 것으로 알고 있었는데 아닌가요? 이거 5,6년전 지식으로 먹고 사는 것도 한계에 다다른 듯...

8.1beta부터 지원한다는 군요

http://developer.postgresql.org/docs/postgres/release.html#RELEASE-8-1