반응형

/********************************************************************************************
-- Title : [10g] 한글을 지원하는 CharacterSet 비교 테이블
-- Reference : oracle.com/technetwork
-- Key word : 캐릭터셋 NLS nls characterset
********************************************************************************************/

한글을 지원하는 캐릭터셋 비교 테이블
  KO16KSC5601 KO16MSWIN949 UTF8 AL32UTF8
한글 지원상태 한글 2350자 KO16KSC5601 + 확장 8822자(총 11172자) 한글 11172자 한글 11172자
캐릭터셋/인코딩 버전 한글완성형 완성형코드포함
확장된 8822자는 MS Windows Codepage 949에 따라 배열
8.1.6 이전 : Unicode 2.1
8.1.7 이후: Unicode 3.0
9i Rel1: Unicode 3.0
9i Rel2 : Unicode 3.1
10g Rel1 : Unicode 3.2
1/0g Rel2 : Unicode 4.0
한글바이트 2바이트 2바이트 3바이트 3바이트
지원버전 7.x 8.0.6 이상 8.0 이후 9i Release 1 이상
Database Characterset으로 설정 가능 여부 가능 가능 가능 가능
National Characterset으로 설정 가능 여부 불가능 불가능 가능 불가능
한글정렬 단순 바이너리 정렬로  구현 가능 KOREAN_M 또는 UNICODE_BINARY 등 특수한 옵션 필요
(한글 정렬에 관한 설명 참조)
한글 정렬은 단순 바이너리 정렬로 가능. 한자 정렬은 KOREAN_M 옵션 필요  
장점 - 특별한 장점이 없음. 완성형 코드만을 입출력하는 것이 확실할 경우에는 높은 성능 - 2바이트로 모든 한글 저장/입출력 가능. 공간의 소모가 적으면서도 모든 한글을 입출력할 수 있다

- 현대 한글 11172자가 정확한 순서로 배열되어 정렬이 효과적
- 다른 언어들(중국어 태국어 등) 또한 같은 데이터베이스 인스턴스에 저장되어야 할 경우 UTF8 등의 유니코드 캐릭터셋 이외에 다른 대안이 있을 수 없음
- 한글 지원은 UTF8과 동일
단점 - 한글을 2350자밖에 지원하지 못한다는 치명적인 단점이 있어 미래에는 사용이 자제되어야 할 캐릭터셋 - 완성형과 호환을 하려다보니, 글자배열순서와 정렬 순서가 다르게 됨. 단순한 "ORDER BY" 절로는 제대로 한글 정렬을 할 수 없음 한글 한 캐릭터가 3바이트를 소모하게 되어 공간의 소모가 크고, 유니코드 인코딩/디코딩에 성능을 소모해야 한다  

반응형

+ Recent posts