[10g] 한글을 지원하는 CharacterSet 비교 테이블

/********************************************************************************************
-- 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바이트를 소모하게 되어 공간의 소모가 크고, 유니코드 인코딩/디코딩에 성능을 소모해야 한다