마님네

오라클에서 유니코드의 사용

1. 컬럼의 데이터타입에 nchar, nvarchar2를 사용
기존 DB캐릭터셋 변경 없음
캐릭터셋 변환으로 인한 부하 발생

2, DB캐릭터셋을 유니코드로 변경(AL32UTF8)
캐릭터셋 변환으로 인한 부하 없음



OTN Forum > Translated Oracle Product >
http://otn.oracle.co.kr/forum/forum_open_list.jsp?forum_cate=tran


[TIP] characterset 선정시 주의 사항

한글을 지원하는 characterset 에는 아래의 것들이 있습니다.

KO16KSC5601
- 완성형
- 한글 2350자 지원

KO16MSWIN949
- 일명 확장완성형(MS에서 windows 에 만들어 놓은 codepage)
- 한글 11172자 지원
- 한글 순서가 뒤죽박죽(2350자의 KSC5601 에서 지원하는 글자는 가나다 순이지만 그 외 글자는 남는 코드 여기저기에 들어가 있음)
- 8.0.6 이상에서만 사용가능 (8.0.5 이하 버전과의 db link나 client 가 8.0.5 등인 경우는 문제가 발생)

UTF8
- Unicode의 CES 중 하나(구현방법중 하나라고 생각하면 될 듯)
- ascii는 1byte, 그 외 유럽쪽은 2byte, 아시아는 3byte(CJK)
- 한글 11172자 지원(고어도 지원) 및 가나다 순 정렬
=> '가'와 '나'의 차이와 '나'와 '다'의 차이가 같음. 제대로 된 전화번호부를 만들 수 있을 듯...

AL32UTF8
- Unicode의 CES중 하나(9i부터 나온 것으로 알고 있음)
- Length semantics로 하면 4 byte( varchar2(3 char) 로 하면 12byte, UTF8에서는 9byte로 알고 있음)
- UTF8과 한글지원 부분은 똑같은 것으로 알고 있음.
- 8i는 미지원이므로 db link나 8i client 사용시 정상적 처리 불가

* AL16UTF16 (논외)
- Unicode의 CES중 하나
- national characterset 에서만 선택가능
- 모든 글자를 2byte or 4byte로 표현

고로

용량을 줄이면서 한글표현 다하고 싶고 8.0.5는 없다면 ko16mswin949를,
한글 표현 제대로 하면서 가나다 순으로 제대로 정렬될 필요가 있으면서 8i와 전혀 연동할 계획이 없다면 AL32UTF8,
위와 같지만 8i가 껴있다면 UTF8로 하시는 것이 좋을 듯 합니다.



UTF8과 AL32UTF8의 차이점

Supplement Character(UTF8에서 4바이트 이상을 차지하는)를 사용하는 것이 아
니라, 일반적인 다국어라면 UTF8와 AL32UTF8의 차이점은 거의 없다고 보시면 됩
니다.

Oracle 캐릭터셋으로서의:
UTF8은 UNICODE 3.0만을 지원하며, 앞으로도 계속 그렇게 유지됩니다.

하지만, UNICODE라는 캐릭터셋 자체도 www.unicode.org에서 보시면 알겠지만,
계속 진화하고 있습니다. 그래서 오라클에서도 새로운 데이타베이스 버전이 나
올 수록 그 순간의 최신 버전의 유니코드를 AL32UTF8을 통해 지원하게 되는 것
입니다.

AL32UTF8은 따라서,
9.0.x : Unicode 3.0
9.2.x : 3.1
10.1.x : 3.2
10.2.x : 4.0

입니다.

AL32UTF8은 9i 이상에서만 식별이 되므로, 8i와 데이타베이스 링크를 사용해야
한다고 할 때에는 UTF8을 사용하는 것이 좋습니다. 아니면 적어도 NLS_LANG을
UTF8로 해 주어야 할 것입니다. 핵심은 구버전과의 호환에 주의해야 한다는 것
입니다. 그리고, National Character Set으로도 설정할 수 없습니다.

성능에서 서로 차이가 있다고는 볼 수 없습니다.





1. 일반적으로 UTF8이 AL16UTF16보다 느리다는 것은 맞습니다. 아무래도
Variable width charset이 Fixed-width charset보다 느릴 수 밖에요. 하지만 얼
마나 느린가에 대해서는 정확히 말씀드릴 수는 없습니다. 하지만 순수하게 한
글 데이타만 저장할 것이 아니라면 AL16UTF16의 경우 영문 데이타 처리에 공간
적 비용이 매우 큽니다. 그래서 일반적으로는 AL32UTF8 charset을 유니코드
charset으로 사용합니다.

2. Web page processing을 UTF8로 하신다는 것은 다국어 지원 클라이언트를 원
하시는 것으로 받아들여집니다. 당연히 데이타베이스는 유니코드 기반의 데이타
베이스를 사용하셔야 합니다. 한글만 처리할 경우에는 Web Client 자체가 유니
코드 기반일 필요는 없겠지요. 그렇다고 안 되는 것은 아닙니다.

3. 그것은 KO16KSC5601 charset이 순수 한글만 포함된 것이 아니라 한자 4880
자, Hiragana 83자, katakana 86자를 포함하고 있기 때문입니다.

nvarchar2컬럼에 데이터입력
4. TO_NCHAR 또는 N''data''를 이용하시면 되겠습니다.
INSERT INTO ... VALUES(TO_NCHAR(''Data''), N''Data'',..);



UTF8과 KO16KSC5601은 성능 이외의 중요한 차이점이 있습니다.

KO16KSC5601은 한글 완성형(KSC5601)을 지원하는 캐릭터셋으로 한글 2350자, 한
자 4880자, 히라카나와 카타카나 53자를 포함한 캐릭터셋입니다. 2바이트를 원
하신다면 차라리 KO16MSWIN949를 선택하셔야 합니다. 운영체제는 전혀 상관없습
니다. 유닉스에서도 KO16MSWIN949를 문제없이 사용할 수 있습니다.

UTF8을 사용하면 공간 활용도가 줄어들 것입니다. 하지만 한글을 정렬해야 할
작업이 많은 경우 오히려 높은 성능을 보여줄 수 있습니다.

KO16MSWIN949는 상대적으로 공간을 절약할 수 있습니다. 하지만 한글 정렬시
UNICODE_BINARY로 정렬해야 하며 정렬의 성능이 좋지 않을 수 있습니다.

실제 트랜잭션들이 과도하게 몰려 바쁘지 않은 이상 한 트랜잭션에서 느낄 수
있는 성능의 차이는 크지 않습니다.

데이타에서 한글과 영문의 빈도, 사용자 수를 조사하시어 시뮬레이션 해 보신
후 결정하시는 것이 좋을 것 같습니다.




혹 유사한 고민을 하시는 분들이다 멀티랭귀지/멀티캐릭터셑 프로젝트를 하시는
분들께 도움이 될까 하여 결과를 올립니다.

-
1. 우선 멀티 랭귀지/캐릭터 셑을 지원하기 위해 캐릭터셑들의 슈퍼셑인 유니코
드를 DB charset으로 설정하셔야 합니다.

2. 사용자와의 인터페이스 부분 (웹서버든 WAS이든) 에 default charset을 설정
하실 수 있으니 UTF-8등의 유니코드로 설정 하십시오.
이때 http header에 setContentType등을 활용하십시오.

3. jdbc connection은 thin dirver이면 그냥, OCI driver라면 NLS_LANG=.UTF-8
설정하십시오.

위 과정으로도 어떠한 변환 없이 다국어/다캐릭터셑 입출력이 가능합니다.


이제 사용자와의 인터페이스가 유니코드를 지원하지 않는 경우에 대해 이야기
해 보면,

1. 사용자의 캐릭터 셋 정보로 default charset을 설정합니다. (이 방법은 런타
임시에는 변경하기 힘드므로 권장되지 않음)

2. http header의 charset 부분을 사용자 캐릭터 셑으로 변경 하십시오.

3. 일부 웹서버의 경우 input tx를 위해 request에 setCharactersetEncoding으
로 사용자 캐릭터셋을 설정하십시오. (default charset을 설정하는 웹서버의 경
우 header의 contenttype내 charset보다 default charset을 우선합니다. 이런 경
우 set해주세요)

위 과정으로도 다국어/다캐릭터 처리를 해줄 수 있습니다.