database.sarang.net
UserID
Passwd
Database
DBMS
MySQL
ㆍPostgreSQL
Firebird
Oracle
Informix
Sybase
MS-SQL
DB2
Cache
CUBRID
LDAP
ALTIBASE
Tibero
DB 문서들
스터디
Community
공지사항
자유게시판
구인|구직
DSN 갤러리
도움주신분들
Admin
운영게시판
최근게시물
PostgreSQL Q&A 5129 게시물 읽기
No. 5129
한글 문자셋 문제 드디어 방법을 찾았습니다!!!!
작성자
김상기(ioseph)
작성일
2003-12-29 18:09
조회수
24,333

역시 메뉴얼을 잘 읽어야한다는 생각을 다시 한번 합니다.

개념은 이렇습니다.

DB 차원의 자료는 utf-8로 저장되고,

client 차원의 자료 입출력은 uhc로 하고,

이것이 단지 세션 환경변수 값으로 가능하군요.

그 나머지 변환은 서버가 알아서 해 줍니다.

 

그 방법은

psql 로 예를 들면,

mydb=# create table t (a text);
CREATE TABLE
Time: 40.361 ms
mydb=# insert into t values ('아햏햏');
ERROR:  invalid byte sequence for encoding "EUC_KR": 0xc164

mydb=# create database mydb2 encoding = 'utf8';
CREATE DATABASE
Time: 127.638 ms

mydb=# \c mydb2
You are now connected to database "mydb2".

mydb2=# show server_encoding;
 server_encoding
-----------------
 UNICODE
(1 row)
Time: 2.139 ms

mydb2=# show client_encoding;
 client_encoding
-----------------
 UNICODE
(1 row)
Time: 0.868 ms

mydb2=# set client_encoding = 'uhc';
SET
Time: 4.142 ms

mydb2=# create table t (a text);
CREATE TABLE
Time: 47.882 ms

mydb2=# insert into t values ('아햏햏');
INSERT 20896 1
Time: 3.751 ms

mydb2=# select * from t;
   a
--------
 아햏햏
(1 row)
Time: 1.683 ms

 

핵심은 set client_encoding 이었습니다.

php일 경우라면, db 연결을 한 다음 바로 다음에 set 명령으로 client_encoding 값만 지정해 준다면 어떠한 코드 수정 없이 바로 사용할 수 있겠네요. 그리고, DB 차원의 모든 자료는 unicode로 바꾸고.

 

답을 찾았습니다. 이제 euc-kr 놈을 포기할 수 있을 것같습니다.

(odbc 에서는 잘 될지 모르겠습니다. 아직 안해봤지만)

 

큰 문제 하나를 풀었네요. 기분 끝내줍니다. :)

사용해 보시고, 문제점이 발생하면 알려주세요.

자료가 unicode로 간다면, 형태소 분석은 보다 편해집니다. unicode놈의 내부는 한글을 초,중,종성으로 분리해 낼 수 있거든요.

 

이 글에 대한 댓글이 총 14건 있습니다.

드디어 해결책을찾았군요

 

아직 jdbc에선 uhc문자셑을 지원하지 않나보네요

 

하지만 하나씩 하나씩 되어가길..

 

가우님이 2003-12-29 19:19에 작성한 댓글입니다. Edit

오오 -.- 역시

어서 좋은 결과를~ ㅎㅎ

tsearch2 를 도입해야 하겠군요! -.-

신기배(nonun)님이 2003-12-30 12:26에 작성한 댓글입니다.

이런 글은 아무래도 Tutorial 측으로 가야 할것 같군요.

모두 입벌리고 있는 사람들 밖에 않보이는군요.

 

계속 수고해 주세요. ^^;

정재익(advance)님이 2003-12-30 20:45에 작성한 댓글입니다.

멋진 정보 감사드립니다..

한가지 의문이 들어서 문의드립니다.

 

얘기하신대로 php에서 접근하는것은 제대로 보이는데요

텔넷접속 psql 로 접속해서 테스트해보니 글자가 제대로 안보이는군요. 그냥 dd 라고만 나옵니다.

 

이부분은 어디를 확인해봐야하는지요.. 부탁드립니다.

감사합니다.

추가 : SecureCRT Version 4.0.9 (build 460)

          echo $LANG -> ko_KR.eucKR

초보자님이 2003-12-31 17:04에 작성한 댓글입니다.
이 댓글은 2003-12-31 17:26에 마지막으로 수정되었습니다. Edit

psql 도 마찬가지입니다.

 

윗 예제처럼

psql 명령이 실행된 다음 psql 프롬프트에서

set client_encoding = 'uhc';

이렇게 set 명령을 한번 실행시켜주면 됩니다.

 

매번 항상 해야하는 것이니까,

$HOME/.psqlrc

파일에다가 윗 명령을 써주면 됩니다.

 

김상기(ioseph)님이 2003-12-31 19:29에 작성한 댓글입니다.

물론 위 예제처럼 그대로 따라했죠..

앞서 얘기한것처럼 웹에서 확인도 햇구요..

헌데 CRT에서 select 했을때 한글이 안보이고 dd 로 나와서..낭패죠.ㅡ.ㅡ

 

그러니까.. 데이타는 일단 제대로 들어갔다고 보여지구요.

psql에서 디스플레이가 제대로 안되는게 아닌가 해서요...

리눅스셋팅이나 PostgreSQL 설치시 어떤 문제가 있지 않나 생각해봅니다.

 

에궁 처음 설치해본거라서..더 검색을 해봐야겠네요..

답변 감사합니다.

초보자님이 2003-12-31 20:54에 작성한 댓글입니다. Edit

우선.. 한글 해결방법을 알려주신 상기님께

 

감사드립니다.^^

 

제 경우 initdb 와 create database 명령을 사용할때 특별히 추가적인 인자를 주지 않았습니다.

 

그래서 서버 엔코딩은 SQL_ASCII 입니다.

 

이상한게, 같은 인터페이스에서 자료를 입력했는데, 왜 psql에서 볼때 한쪽만 제대로 결과가 출력되는지.. 흠..

 

벌써 3번째 덧말만 수정하는 군요. 소팅과 관련해서도 간단히 실험해보았습니다. 문제 없습니다.

 

이전에 tsearch2 만 가져다 붙이면.. 한단계 성장하지 않을까 싶네요..

 

아 또.. 4번째 덧말편.

DB에서 유니코드로 데이터를 처리해버리게 되면, 기존에 유니코드 데이터형을 따로 지원했던 MS-SQL보다 이미 한 단계 발전되어 있던 셈인가요? 어째 계속 PostgreSQL에 빠져들고만 싶은..

 

개인적으로 Stored Procedure 부분만 강화되었으면 참 좋겠다는 @@

 

흠...

 

그럼.. 즐거운 시간 보내세요..

 

ps. crt에서 표시되는 문제는 아마도.. crt 설정문제가 아닐까 싶다는..일전에 잠시 소개했던 Aqua Data Studio에서는 굳이 Client_encoding을 uhc로 설정해주지 않아도 자동으로 한글을 보여줍니다.

 

uhc로 설정하는 것은 psql이나 유니코드를 바로 지원하지 못하는 클라이언트들에게만 해당되는 얘기 같습니다.

 

이대로보만 본다면, ADO에서 바로 PostgreSQL 사용하는 것도 큰 무리는 아닐 듯 싶네요..

이상호(search5)님이 2004-01-01 06:49에 작성한 댓글입니다.
이 댓글은 2004-01-01 09:08에 마지막으로 수정되었습니다.

이상호님 글을 보고 테스트를 해봤습니다.

제가 사용한건 EMS PostgreSQL Manager(2.0.0.3) 입니다.(이하 EMS)

본문과 같은 환경을 만들고 EMS에서 접속을 했을때 client_encoding을 ufc 로 했을때만 한글이 제대로 출력이 되었습니다.

님이 얘기하신 Aqua Data Studio는 테스트를 못해봤습니다.

 

어째뜬 다분히 클라이언트 툴에 따라 다를 수 있다는 얘기인데요.Manager Tool에서는 그렇다치고 저는 처음 배우는 단계라 가능하면 콘솔에서 psql로 작업을 하고자 합니다.  상기님도 콘솔(텔넷으로 psql실행시) 작업을 한것으로 보여지는데 어떤 툴(환경)을 사용하신건지 궁금해지는군요. 알려주시면 감사하겠습니다.

초보자님이 2004-01-01 20:28에 작성한 댓글입니다.
이 댓글은 2004-01-01 20:30에 마지막으로 수정되었습니다. Edit

SecureCRT 의 경우... 유니코드로 된 한글을 제대로 보실려면...

 

메뉴중에 Session Option -> Emulation -> Advanced

 

의 Character Encoding 부분을

 

'UTF-8'로 변경하세요

김영우님이 2004-01-01 23:25에 작성한 댓글입니다. Edit

제가 사용하는 문자셋에 관한 정보입니다.

------------------------------------------------------
# pg_controldata PGDATADIR
LC_COLLATE:                           ko_KR.eucKR
LC_CTYPE:                             ko_KR.eucKR     
-------------------------------------------------------
select version();
PostgreSQL 7.3.2 on i686-pc-linux-gnu,
compiled by GCC gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
-------------------------------------------------------
 server_encoding
-----------------
 SQL_ASCII   

 client_encoding
-----------------
 SQL_ASCII   
-------------------------------------------------------
# env
JLESSCHARSET=ko
LANG=ko_KR.eucKR
-------------------------------------------------------
그런데 저는 한글 사용에 대한 문제가 전혀 없었습니다.

그래서, 위에서 한글문자셋이 해결되었다는 것이 잘 느껴지지 않습니다.

insert 에서도 select  like '%한글'  비교에서도,

잘 동작되었습니다.

어떤 것이 문제인지 조차 잘 몰라서 댓글을 올려봅니다.

운영체제는 레디헷 8 패키징을 그대로 설치했습니다.

문자셋은 한글을 기본으로 하고, 영문을 추가언어로 하는 것 정도였습니다.

pgsql초보님이 2004-01-02 14:42에 작성한 댓글입니다. Edit

테스팅 한다고 좀 답장이 좀 늦었습니다.

RedHat 8.x 로 운영되는 시스템에서는 일단 한글 관련 정렬 문제는 해결이 되었더군요.

하지만, 로케일 전체적인 문제는 아직 해결하지 못했나봅니다. 이 문제는 glibc 문제였거든요.

 

SQL_ASCII 문자셋으로 데이터베이스를 만들면, 다음 문제점들을 안고 있습니다.

  • 모든 문자를 ascii로 간주하기 때문에, 한글 하나를  '글자 한개'로 보지 않고, '글자 두개'로 봅니다.
    mydb=# select length('가');
     length
    --------
          2
    (1 row)
    이문제는 db 차원안에서 모든 문자열 관련 함수들에서 그대로 적용됩니다. 또한 ~ 와 같은 정규식에서도 한글 정규식을 쓸수도 없지요. 그외 수 많은 제약이 따릅니다. 한가지 예만 보여드리면,
    mydb=# select '아버지' ~ '[가나다라마바사아]';
     ?column?
    ----------
     t
    (1 row)
    mydb=# select '자기야' ~ '[가나다라마바사아]';
     ?column?
    ----------
     t
    (1 row)
    윗 예제들은 버그가 아니라, DB 문자셋을 잘못지정해서 빚어진 사태인 것입니다.
  • 다음 한글 정렬에서 확장완성형 글자들이 중간중간에 끼어들게 됩니다. ascii 값으로 '햏'이 '자' 보다 글자값이 작기 때문이지요. - 이문제는 unicode로 가지 않는다면, 모든 rdbms에서 같은 결과를 보입니다.
  • like 연산에서 인덱스를 사용할수 없게 됩니다. like '가%' 이런식으로 사용되는데, 그 칼럼 인덱스를 만들어두었다면, (물론 btree 인덱스를 말합니다) PostgreSQL에서는 윗 구문을 다시 내부적으로 '가'에서 '각' 앞까지를 찾게 됩니다. 이렇게 하려면 한글 문자셋을 참조 해야겠지요. 이때로 '탄%' 처럼 니은받침일 경우는 '탅' 앞까지가 정확하겠지요. euc_kr 로도 해결할 수 없는 부분입니다. 결국 unicode 쪽으로 옮겨갈 수 밖에 없습니다.
    이부분이 정상적으로 움직여야하는 것과 서버의 nls 기능을 함께 사용하고자 한다면, initdb 작업에서 로케일 지정과 함께, --lc-collate=C  옵션도 함께 주어야 가능하더군요.

 

김상기(ioseph)님이 2004-01-03 11:41에 작성한 댓글입니다.

네..

그런 문제점이 있었네요.

답변감사합니다.

그런데.. 또 질문 거리가 생겼네요.

이 질문을 따로 다시 올리겠습니다.

사실 어디서 손봐야 할지도 모르겠고,

다른 분들도 관심있게 생각할 것 같거든요.

새해 복 많이 받으십시요.

pgsql초보님이 2004-01-03 13:37에 작성한 댓글입니다. Edit

여기 글들이 쓰여진지 만 2년만에 댓글을 달게 됐네요..

중간에 콘솔 상에서 한글 입력 안되는 문제를 저도 방금 겪었는데..

쉘 상에서 LC_MESSAGES 값을 ASCII로 하고 psql 을 실행하니 한글이 제대로 입력됩니다.

 

그리고 답변을 들을 수 있을지 모르겠는데요.

PHP를 이용해서 DB에  매번 쿼리를 전송할 때 마다 set client_encoding을 지정해 줘야 하는지요. default로 지정하는 방법은 없는지 알고 싶네요.. 혹시 경험 있으신 분 있으면 답변 부탁드립니다.

최웅규(turbojet)님이 2005-12-06 21:00에 작성한 댓글입니다.

자문 자답을 하게 되네요. db가 생성된 디렉터리에 postgresql.conf 파일을 보시면..

#client_encoding = sql_ascii    # actually, defaults to database encoding

 

위와 같이 되어 있는 부분이 있습니다.

이 부분을 주석 제거하시고 sql_ascii를 uhc로 변경하시면 쿼리를 전송할 때 마다 문자셋을 변경해 줄 필요가 없습니다.

 

client_encoding = uhc   # actually, defaults to database encoding

 

최웅규(turbojet)님이 2006-01-02 14:08에 작성한 댓글입니다.
[Top]
No.
제목
작성자
작성일
조회
5132[질문] pg_sorttemp*.* 파일 삭제여부 부연설명부탁드려요 [1]
질문하는사람
2003-12-30
2347
5131pgsql용 게시판... [2]
이훈우
2003-12-30
3010
5130[질문] pg_sorttemp*.* 파일 삭제여부 [1]
질문하는사람
2003-12-29
2390
5129한글 문자셋 문제 드디어 방법을 찾았습니다!!!! [14]
김상기
2003-12-29
24333
5128[질문]윈도우에서 PostgreSQL 종료문제?? [2]
황남주
2003-12-29
3353
5127[질문] 'LOG: shmdt(0xe20000) failed: Invalid argument' 이거 어디서 확인하죠? [1]
황남주
2003-12-29
3123
5126난감한 index... [6]
초보
2003-12-28
4405
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2023 DSN, All rights reserved.
작업시간: 0.048초, 이곳 서비스는
	PostgreSQL v16.1로 자료를 관리합니다