사람은 세 부류로 나눌 수 있다.
첫째는 시각적인 언어를 표현의 준거로 삼아 말하는 사람이고, 둘째는 주로 청각적인 언어를 빌려서 말하는 사람이며, 셋째는 육감적인 언어를 많이 구사하는 사람이다.
시각파들은 <이것 봐요>라는 말을 자주 한다. 아주 당연한 일이다. 그들은 이미지를 빌려서 말하는 사람들이기 때문이다. 그들은 보여 주고 관찰하며 색깔을 통해 묘사한다. 또, 설명을 할 때는 <명백하다>, <불분명하다>, <투명하다>라는 식으로 말하고, <장밋빛 인생>이라든가 <불을 보듯 뻔하다>, <새파랗게 질리다>와 같은 표현을 즐겨 사용한다.
청각파들은 <들어 봐요>라는 말을 아주 자연스럽게 한다. 그들은 <쇠귀에 경 읽기>나 <경종을 울리다>, <나발불다>처럼 어떤 소리를 상기시키는 표현을 사용해서 말하고, <가락이 맞는다>라든가 <불협화음>, <귀가 솔깃하다>, <세상이 떠들썩하다> 같은 말들을 자주 쓴다.
육감파들은 <나는 그렇게 느껴. 너도 그렇게 느끼니?> 하는 식의 말을 아주 쉽게 한다. 그들은 느낌으로 말한다. <지긋지긋해>, <너무 예뻐서 깨물어 주고 싶어>, <썰렁하다>, <화끈하다>, <열에 받치다>, <열이 식다> 같은 것이 그들이 애용하는 말들이다.
자기와 대화를 나누는 상대방이 어떤 부류에 속하는지는 그 사람이 눈을 어떤 식으로 움직이는가를 보면 알 수 있다. 어떤 일에 대해 기억을 더듬어 보라고 요구했을 때, 눈을 들어 위쪽을 보는 사람은시각파이고, 눈길을 옆으로 돌리는 사람은 청각파이며, 자기 내부의 느낌에 호소하려는 듯 고개를 숙여 시선을 낮추는 사람은 육감파다.
대화의 상대방이 어떤 유형에 속하는 사람이든 각 유형의 언어적 특성을 알고 그 점을 참작해서 이야기를 한다면, 상대를 다루기가 한결 용이해진다.
한편, 상대방의 언어적 특성을 활용하는 방법에서 한 걸음 더 나아가, 상대의 신체 부위 가운데 한 곳을 골라 그를 조종하는 맥점(脈點)으로 이용하는 방법도 생각해 볼 수 있다.
예를 들어, <나는 자네가 이 일을 잘 해내리라고 믿네>와 같은 중요한 메시지를 전달하는 순간에, 상대방의 아래팔을 눌러 자극을 주는 것이다. 그러면, 매번 그의 아래팔을 다시 눌러 줄 때마다 그는 되풀이해서 자극을 받게 된다. 말하자면 감각의 기억을 활용하는 것이다. 한 가지 조심할 것은 그 방법을 뒤죽박죽으로 사용하면 전혀 효과를 볼 수 없다는 점이다.
예컨대, 어떤 심리 요법 의사가 자기 환자를 맞아들일 때, <이런, 가련한 친구 같으니, 보아하니 상태가 별로 나아지지 않은 게로군> 하고 그를 측은해 하면서 어깨를 툭툭 친다고 하자. 만일 그 의사가 환자와 헤어지는 순간에도 똑같은 동작을 되풀이한다면, 그가 아무리 훌륭한 치료를 행했다 한들 환자는 한순간에 다시 불안에 빠지고 말 것이다.
2014년 1월 15일 수요일
[펌] Oracle과 한글 그리고 UTF-8
Oracle과 한글 그리고 UTF-8
DBA가 프로젝트를 시작하면서 가장 먼저 결정해야 할 것은 Oracle Database Character Set이다.
오 라클 DBA로서 개발자나 현업 담당자들에게 UTF-8을 권장하지만, 강권하지 못하는 실정이다. 이유는 현업 담당자들은 기존에 거의 대부분 KO16KSC5601을 사용했거나 일부 사용자들은 US7ASCII를 사용하고 있었기 때문에 UTF-8을 사용할 경우 막연한 불안감이 있으며, 개발자들은 UTF-8로 갈 경우 기존에 가지고 있던 개발 프로그램의 문자열 처리 및 기타 여러가지 수정사항이 많이 발생하기 때문에 반대하는 경우가 허다하다.
그래서 오라클과 한글, 특별히 UTF-8을 중점적으로 Oracle Character Set에 관해 알아보자.
Oracle Database 한글판?
오라클 데이터베이스를 설치하려고 할 때, 명확한 이해를 못하는 사람들은 "한글판의 설치"를 강하게 주장하는 경우가 있다. 답답한 마음을 든다.
오라클은 M$-Windows처럼 한글판, 영문판 등으로 구분되지 않고, DB의성격 및 크기 그리고 추가적인 기능으로 구분된다. 즉 Oracle DBMS는 언어별 제품 구분이 없다는 야그다.
Oracle DBMS에서 다국어 지원
앞 서 언급했듯이 오라클 DBMS는 처음부터 다국어 지원을 목적으로 설계된 일종의 RDBMS 소프트웨어다. 이렇게 다국어를 지원하는 소프트웨어는 몇가지 규칙을 가지고 다국어를 지원하고 있으며, 오라클도 마찬가지로 나름대로 다국어 지원 규칙이 있다.
1. 영역(Territory)별 지원
" 영어"를 모국어로 사용하고 있는 나라들도 사용되는 날짜 표기 방법이 다르다. 즉 영국에서는 "일/월/연도"로 표기하는 반면, 미국에서는 "월/일/연도"로 표기한다. 물론 사용하는 통화기호 또한 "파운드"와 "달러"로 각가 다르다. 이 같이 동일 언어를 사용한다고 하더라도 서로 다른 지리적, 사회적 특성으로 말미암아 서로 차이점을 가지게 된다. 이러한 차이점을 반영하는 방법이다.
- 달력 설정 방법 : 어떤 나라는 한 주의 첫번째 요일을 일요일로, 다른 나라는 월요일로 생각함
- 날짜 포맷 : 같은 날짜를 표기하는데 각 지역마다 고유의 방식이 있음
- 통화 기호 : 각 지역마다 통화기호와 금액 표기 방식이 다름
- 숫자 그룹 : 소수점 기호나 숫자를 그룹핑하는 방법이 지역마다 다름
2. 언어(Language)적 지원
언어별로 달리 지원을 하는 특성은 다음과 같은 것이 있다.
- Character Set : 각 언어가 저장될 수 있는 Character Set을 대부분 지원함.
한국어의 경우 KO16KSC5601과 KO16MSWIN949가 있음
한국어의 경우 KO16KSC5601과 KO16MSWIN949가 있음
- 정렬 방식 : 각 언어별로 정렬하는 규칙이 다름
- 날짜 표기에 사용되는 기호 : 날짜를 표시할 때 사용하는 month, day, day of week, year 같은
정보를 그 나라에 맞게 번역하여 제공
정보를 그 나라에 맞게 번역하여 제공
- 에러메시지 및 UI번역 : 사용자들의 불편을 최소화하기 위해 각 언어별로 번역된 에러 메시지와
사용자 인터페이스를 제공(에러 메시지의 출력은 전적으로 OS의 언어와 관련이 있음)
사용자 인터페이스를 제공(에러 메시지의 출력은 전적으로 OS의 언어와 관련이 있음)
Oracle과 한국어
한글은 세종대왕께서 천지인을 바탕으로 창제하신 아주 훌륭한 문자다. 그러나 막상 IT업계 종사자들은 비 라틴계언어가 아닌 이상은 한글이건 중국어건, 일어건 다 처리하기 어렵고 짜증나는 언어임에는 틀림없다.
오라클에서 한글을 사용하고 싶을 때 가장 쉬운 방법은 오라클 DBMS를 설치할 때 실행언어에 한국어를 추가하면 아주 쉽게 끝낼 수 있다. 다만 너무 지나친 속도로 마우스 클릭만을 하지 않으며 된다.
설치 단게에서 "한국어"를 선택하면 한국에 관련된 일종의 언어팩과 같은 추가적인 기능이 더 설치된다.
- 번역된 메시지 : 오라클 DBMS와 함께 제공되는 애플리케이션 중, iSQL*Plus나 자바, ADF 기반의 웹 애플리케이션의 경우에는 "언어선택"과 관계없이 번역된 작업 환경이 제공된다. 하지만, SQL*Plus와 같은 기존 애플리케이션은 오라클의 번역 메시지 리소스에 의존하며 이들 파일은 각 언어별로 따로 제공된다. 만일 설치 때에 "한국어"를 선택하지 않으면 한국어 메시지 파일은 설치되지 않는다.
- 폰트 : 오라클 ADF(UIX 혹은 CABO) 기반의 애플리케이션의 경우, "확인", "취소" 등의 버튼이 이미지로 제공되는 경우가 많다. 이런 이미지들은 번역된 메시지를 바탕으로 UIX 엔진에 의해 동적으로 생성된다. 이 이미지가 제대로 생성되기 위해서는 반드시 특정 폰트를 필요로 하게 되는데, 이 폰트는 "한국어"를 선택하지 않을 경우 설치되지 않는다. 이 특정 폰트는 한국어, 중국어(간체, 번체) 그리고 일본어에 대해 각각 제공되므로, 만일 한국어 이외에 이들 언어도 지원해야 할 경우 필수적으로 그 언어들을 선택해야 할 것이다.
- 로케일 정보 : 번역 뿐만 아니라 오라클 DBMS가 다양한 로케일 정보를 가진 클라이언트들과 제대로 통신하기 위해서는 각 국가별, 언어별로 특색있는 로케일 정보를 지니고 있어야 한다. 이들은 날짜 형식("2050-04-14", "Jul 9, 2005" 등), 통화 코드($) 등의 정보를 포함하고 있다. 한국어에 관한 로케일 정보를 위해 반드시 "한국어"를 선택해야 한다.
즉, 오라클 DBMS 설치 과정 중 실행환경에서 선택하는 "한국어"와 오라클 DB에서 한국어 저장 및 출력은 아무 상관이 없다는 이야기다. 한국어의 저장과 출력은 Oracle DBMS 설치 과정중 Character set 선택과정에서 무엇을 선택했냐에 따라 결정되는 것이다.
US7ASCII
오 라클 DB를 사용하는 곳을 보면 아직도 US7ASCII을 Character Set으로 사용하는 곳이 많이 있는 곳으로 알고 있다. 언뜻 보기에는 US7ASCII도 한글을 지원하는 것처럼 보이지만, 사실은 한글이 저장되는 것이 아니고, 한글을이진코드 형태로 변환하여 저장 및 출력하는 형태다.
한글을 지원하는 Character Set
현재까지 오라클 DB에서 한글을 사용하려면 Character Set을 "KO16KSC5601", "KO16MSWIN949", "UTF8", "AL32UTF8"만 사용할 수 있다.
KO16KSC5601
한글 완성형 코드와 일치하며 일반적으로 많이 사용되는 2350자의 한글, 4888자의 한자와 히라카나, 카타카나, 그리고 영문 및 각종 기호들을 포함하고 있다.
KO16MSWIN949
Windows-949 Character Set은 MS사의 Windows Codepage 949번, 즉 한글 코드 페이지를 따른 코드셋이다. 이는 완성형(KO16KSC5601)을 그대로 포함하고 있으며, 추가로 현대 한글 조합으로 표현할 수 있는 모든 가짓수에 해당하는 8822자의 한글을 추가해 포함하고 있다. 그러니까 "Windows-949 Character Set은 KSC5601의 수퍼셋(SuperSet)"이 되며, 따라서 "KO16MSWIN949 또한 KO16KSC5601의 수퍼셋"이 된다.
UTF8/AL32UTF8
UTF8 은 유니코드를 구현한 Character Set 중에 가변결이 인코딩 방식을 택하고 있는 Character Set이다. 가변 길이를 위해 일종의 플래그 비트를 각 바이트마다 포함시켜야 하다보니, 한 글자를표현하는데 필요한 바이트의 길이가 최대 3바이트(AL32UTF의 경우 6바이트)까지 늘어날 수 있다.
한글지원 Character Set 비교표
KO16KSC5601 KO16MSWIN949 UTF8 AL32UTF8
한글지원 상태 2350자 11172자 11172자 11172자
캐릭터셋/인코딩 한글완성형 한글조합형 8.1.6이전:Unicode 2.1 9iR1 : Unicode 3.0
버전 8.1.7이후:Unicode 3.0 9iR2 : Unicode 3.1
10gR1 : Unicode 3.2
10gR2 : Unicode 4.0
한글바이트 2Bytes 2Bytes 3Bytes 3Bytes
지원버전 7.x 8.0.6 이상 8.0이상 9iR1이상
National Char- 불가능 불가능 가능 불가능
acterSet으로
설정 가능 여부
National CharacterSet
National CharacterSet은 유니코드를 지원하지 않는 CharacterSet을 가진 데이터베이스에서 유니코드를 지원하기 위해 부가적으로 설정할 수 있는 CharacterSet이다.
즉, 하나의 데이터베이스 인스턴스는 "CharacterSet"과 "National CharacterSet"을 가진다. 처음 시스템 구축 당시와는 달리, 한글 이외의 다른 언어를 급히 저장해야 할 필요성이 있는 경우 National CharacterSet을 적절히 활용할 수 있다.
National CharacterSet이 가능한 CharacterSet은 단 두가지로, UTF8과 AL16UTF16(기본값)이다.
Nation CharacterSet을 사용하기 위해서는 특정 타입으로 테이블읠 컬럼 또는 PL/SQL 변수를 선언해야 한다. CHAR와 VARCHAR2, CLOB에 대응되는 National CharacterSet 기반의 타입으로는 NCHAR, NVARCHAR2, NCLOB이 있다.
즉, KO16MSWIN949 데이터베이스에서 다음과 같이 테이블을 생성할 경우,
Create Table test_table (
varchar_value VARCHAR2(2000),
nvarchar_value NVARCHAR2(2000) );
"varchar_value" 컬럼에는 KO16MSWIN949에 속하는 글자들만 저장할 수 있는 반면, nvarchar_value 칼럼에는 유니코드에 속한 모든 글자들을 저장할 수 있다. 약간의 부가적인 코드가 필요할 뿐 실제 프로그래밍 방식은 거의 동일한다.
CharacterSet 선택의 원칙
- 한글 지원을 위해서는 반드시 위의 네가지 CharacterSet 중에 하나를 선택해야 함
- 한국에서만 사용하는 시스템이라면 KO16MSWIN949를 선택한다.
- 한국어뿐 아니라 중국어, 일본어, 러시아어 등 다양한 언어로 된 데이터를 저장해야 한다면
UTF8, AL32UTF8을 선택한다. 인코딩 변환으로 한국어 기반의 CharacterSet에 비해 속도의 저하가
있다고 알려져 있음
UTF8, AL32UTF8을 선택한다. 인코딩 변환으로 한국어 기반의 CharacterSet에 비해 속도의 저하가
있다고 알려져 있음
- 대부분이 한글이며, 일부 외국어가 필요하다면, 한국어 기반의 CharacterSet(KO16MSWIN949)을
사용하되, National CharacterSet을 이용한 칼럼에 외국어를 저장한다.
사용하되, National CharacterSet을 이용한 칼럼에 외국어를 저장한다.
NLS_LANG
오라클에서는 많은 환경변수 값을 사용하고 있다. 그렇지만 지금은 한글에 관한 이야기를 하고 있으므로 NLS_LANG만 가지고 설명한다.
오 라클 DB 서버와 클라이언트간 NLS_LANG 값을 동일하게 하여 사용하는 경우가 99%가량이다. 이렇게 사용하는 이유는 Oracle Client 프로그램을 이용하여 직접 오라클 DB에 접속하여 작업하는 경우가 대부분이기 때문이다.
그러나 NLS_LANG 변수의 값은 오라클 DB 환경변수 값이 아나라, 사용자 자신이 속해 있는 환경을 오라클 DB 서버에 알려주는 역할을 하는 환경변수이다.
NLS_LANG = [언어]_[영역].[캐릭터셋]
언어 : 현재 사용자가 사용하는 언어적 특성을 결정짓는 값
영역 : 현재 사용자가 위치한 영역의 특성을 결정짓는 값
캐릭터셋 : 현재 사용자의 시스템이 인식할 수 있는 캐릭터 셋의 값
만 약 Windows Client에서 한국어 환경을 사용하는 경우 NLS_LANG 값을 'KOREAN_KOREA.KO16MSWIN949"로, 유닉스 클라이언트에서 한국어를 입출력한다면 'KOREAN_KOREA.KO16KSC5601'로 NLS_LANG를 설정할 것이다.
오라클 서버 CharacterSet과 클라이언트 CharacterSet을 동일하게 설정해야 하는 경우
앞서 이야기 했지만 NLS_LANG 값은 클라이언트 값이기 때문에 오라클 DB 서버와 동일하게 설정할 필요는 없지만 작업 및 그 동안 관습에 따라 오라클 DB서버와 NLS_LANG 변수 값을 동일하게 설정하는 경우가 많다.
그러나 오라클에서 아래에 나열한 작업이 필요할 경우 꼭 오라클 DB와 NLS_LANG 값을 동일하게 하는 것을 권장하고 있다.
- 데이터베이스로부터 데이터를 export 받을 때
- export 받은 데이터베이스와 같은 CharacterSet을 가진 DB로 export된 파일을 import할 때
- 기타 다국어 지원 애플리케이션에서 목적에 따라 사용할 때
NLS_LANG 관련 주요 변수
- NLS_TERRITORY : 영역 설정 - NLS_LANG 변수 값에 의해 자동 설정
* 설정 방법 예> ALTER SESSION SET NLS_TERRITORY = 'KOREA'
- NLS_LANGUAGE : 언어 설정 - NLS_LANG 변수 값에 의해 자동 설정되는 초기화 변수
* 설정 방법 예> ALTER SESSION SET NLS_LANGUATE = 'KOREAN'
- NLS_LANG : 언어, 영역, 캐릭터셋 설정 - 기본 값은 'AMERICAN_AMERICA.US7ASCII'
* 설정 방법 예> OS 환경변수로 설정
- NLS_COMP : SQL에서의 비교 방식(<, >, =) 설정 - BINARY값으로 비교
* 설정 방법 예> ALTER SESSION SET NLS_COMP = ''
- NLS_SORT : 문자열 정렬방식 설정 - NLS_LANGUAGE 값에 따라 결정
* 설정 방법 예> ALTER SESSION SET NLS_SORT = 'KOREAN_M'
- NLS_TERRITORY 변수에 따라 그 값이 결정되는 변수
* NLS_CREDIT(대차대조표 '대변' 항목의 금액표기를 위한 기호. 보통 '공백' 문자)
* NLS_CURRENCY
* NLS_DATE_FORMAT
* NLS_DEBIT(대차대조표 '차변' 항목의 금액표기를 위한 기호. 보통 '마이너스' 문자)
* NLS_ISO_CURRENCY
* NLS_LIST_SEPARATOR(숫자를 가로로 나열할 때 각 숫자를 구분하는 기호로,
우리나라의 경우 콤마다)
우리나라의 경우 콤마다)
* NLS_MOMETARY_CHARACTERS(금액 표기시 금액을 읽기 쉽게 나누는 문자로
우리나라에서는 3자리마다 ","를 추가)
우리나라에서는 3자리마다 ","를 추가)
* NLS_NUMERIC_CHARACTERS(소수점 기호와 숫자 그룹핑을 위한 문자 설정.
우리나라에서는 '.,'이다(dot와 comma).
* NLS_TIMESTAMP_FORMAT
* NLS_TIMESTAMP_TZ_FORMAT
* NLS_DUAL_CURRENCY(유로화 변경 기간 동안의 혼란을 막기 위해 만들어진 매개변수.
9iR2와 그 이후로는 EU의 유로화 변경이 완료된 상태로 NLS_CURRENCY와 값이 동일하다.
다만 미래에 다른 지역에서도 통화기호의 변경이 일어나면 사용될 수 있음)
NLS_LANGUAGE 변수에 따라 그 값이 결정되는 변수
* NLS_DATE_LANGUAGE
* NLS_SORT
* NLS_
오라클 DB에서 한글을 사용하다보면 정렬에 관한 문제가 발생하는 경우가 있다. 특히 동양권(한국/일본) 언어에서는 자국에 원어이외에 한자를 사용하고 있으므로 인해 여러가지 문제가 발생하는 경우가 있다.
KO16KSC5601에서 한글 정렬
KO16KSC5601 에서는 한글 2350자의 바이너리 정렬 순서가 한글의 언어적 정렬 방식과 동일하다. 따라서, 단순히 Order by 명령만으로 정렬의 효과를 거둘 수 있다. 한자의 경우 한글 뒤에 한자의 음에 맞게 정렬이 된다.
이것은 단지 한글 2350자들과 한자 4888자의 정렬일뿐이며, 나머지 글자들에 대해서는 입출력도 불가능하다.
UTF8/AL32UTF8에서 한글 정렬
UTF8 데이터베이스의 경우, 한글만을 고려하면 별다른 정렬 옵션이 필요없다. 왜냐하면 한글 11172자의 정렬 순서와 바이트 코드 정렬 순서가 일치하기 때문이다.
그러나 한자를 포함한다면 한자->한글 식으로 정렬이 된다.
KO16MSWIN949에서 한글 정렬
KO16MSWIN949 는 KO16KSC5601에서 지원되지 않는 8822자의 한글을 추가적으로 지원한다는 점에서 KO16KSC5601의 대안으로 자주 이용되는 Character Set이다. 하지만, 총 11172자의 한글의 바이트 코드가 한글의 언어적 정렬 순서와 불일치 한다.
NLS_SORT
UTF8과 KO16MSWIN949에서는 원하는 형태의 정렬이 일어나지 않는다. 이럴 때 NLS_SORT 값을 활용하여 원하는 형태의 정렬을 구현할 수 있다.
NLS_SORT='KOREAN_M'
- 한글은 단순히 유니코드 바이트 정렬에 의존한다.
- 모든 한글은 한자에 우선한다.
- 한자는 발음 순서대로 정렬된다.
한마디로 KO16KSC5601에서 사용되던 정렬 방식으로 모든 한글과 한자를 정렬하겠다는 방법이다.
NLS_SORT='UNICODE_BINARY'
이 방법을 사용하면 각각의 문자에 대응하는 이진코드값을 기준으로 정렬된다. 이때는 한자->한글 순이다.
즉, 한글과 한자를 사용하는 경우에는 NLS_SORT='KOREAN_M'을 사용해야 한다.
이제부터 오라클의 Character Set을 변경하는 방법에 대해서 살펴보도록 하겠다. 다만 여기서 설명하는 방법으로 Character Set을 변경했을 경우 100% 데이터를 보장하지 않는다.
오라클 DB Character Set 변경 전에...
오 라클 DB Character Set을 변경하고자 한다면 먼저 혼자 판단하기 전에 오라클 DB Character Set변경에 총 책임을 질 수 있는 책임자, Application 개발자 및 운용자와 심사숙고하고 변경하기 전에 꼭!꼭!꼭! Full Backup을 받고 진행해야 한다.
오라클 DB Character Set 변경 종류
오라클 DB에 대한 Character Set을 변경한다는 것은 다음의 두 가지를 의미한다. 변경하는 방식이 무엇인지 정확하게 파악하고 작업을 시작해야 한다.
Case 1> Character Set Dictionary 정보 변경 + 데이터 불변
Character Set 변경시도 시점을 기준으로, DB에 저장되어 있는 데이터 자체는 전혀 변경하지 않은 채, Dictionary에 있는 Character Set 정보만을 변경하는 작업이다.
일 반적으로 Character Set에 맞게 데이터를 잘 저장시켜 온 DB에는 사용할 수 없는 방법이다. 예를 들어 KO16MSWIN949 Character Set을 가진 DB에 한글을 Windows-949의 코드페이지에 맞게 잘 저장하고 사용해왔다면 이 DB의 Dictionary 정보만을 UTF8로 바꿔서는 전혀 엉뚱한 결과를 얻게 되는 것이다. 주로 다음과 같은 상황에서 사용할 수 있다.
- 비어있는(Empty) DB Instance : DBCA(Database Configuration Assistants)를 이용해 DB Instance를 생성할 때, Character Set을 잘못 선택했다면 도중에 작업을 중단하는 방법도 있지만(사실 중단하기를 권장한다!), 생성을 마친 후 Character Set 정보를 변환함으로써 문제를 해결할 수 있는 경우가 있다. KO16MSWIN949로 생성해야 할 데이터베이스를 KO16KSC5601로 설정하여 생성했다면, 생성을 마친 후 간단한 절차를 거쳐 KO16MSWIN949로 변경할 수 있는 것이다.
- Character Set과는 전혀 엉뚱하고도 다른 Character Set으로 인코딩된 정보를 강제 저장해온 Instance : 이런 경우가 상당히 많은데, DB Character Set은 US7ASCII밖에 없는 것으로 생각을 했던 것일까? US7ASCII은 그 이름만 보아도 절대 한글을 저장할 수 없을 것 같은 Character Set인데, 여기에 한글 데이터를 버젓이 저장해온 시스템들이 상당히 많다. Character Set은 US7ASCII이지만, 실제로는 완성형+한글 원도우즈 코드 페이지(KO16MSWIN949)의 데이터를 저장해 온 경우, 데이터는 현재 상태에서 가공하지 않은 채, Dictionary에 있는 Character Set 정보만을 강제로 KO16MSWIN949로 변환하는 방식으로 문제를 해결할 수 있다.
"ALTER DATABASE CHARACTER SET" 명령어가 이에 해당한다.
Case 2> Character Set Dictionary 정보 변경 + 데이터 변경
Character Set의 변경과 함께 DB가 가지고 있는 데이터의 인코딩까지도 변경하는 마이그레이션 작업을 포함하는 경우로, Case 1>에 비해 상당히 긴 시간이 소요되는 방대한 작업이며, 그에 따라 위험성도 크다. 기존 DB의 백업은 물론 당연하며, 새로운 Character Set을 가진 새 DB Instance를 생성하여 그곳에 현재 DB로부터 데이터를 마이그레이션을 하는 것이 가장 안전하다. 이 경우 보통 exp/imp를 사용하여 해결할 수 있다. 현존하는 DB의 데이터를 직접 변경하려고 할 경우를 대비해 오라클에서는 CSSCAN이라는 툴을 제공하고 있다.
ALTER DATABASE 명령을 이용한 Dictionary 변경
Case 1>에 해당하는 것으로 데이터에 대한 어떠한 검토나 수정은 없이 Dictionary의 Character Set 정보만을 교체하는 작업이다. KO16KSC5601을 KO16MSWIN949로 변경할 때 유용하다. 그리고 한글만을 저장해 온 US7ASCII DB 또한 이 방식으로 KO16MSWIN949로 변경할 수 있다.
SQL > Shutdown Immediate;
SQL > Startup Mount;
SQL > Alter System Enable Restricted Session;
SQL > Alter System Set Job_Queue_Processes=0;
SQL > Alter System Set Aq_Tm_Processes=0;
SQL > Alter Database Open;
SQL > Alter Database Character Set KO16MSWIN949;
SQL > Shutdown Immediate;
이 방식을 사용하려면 반드시 새로운 Character Set은 기존 Character Set의 SupterSet이어야 한다. 그렇지 않으면 기존 데이터의 안전이 보장될 수 없기 때문이다.
기존 Character Set 새로운 Character Set 변경 가능 여부
US7ASCII KO16KSC5601/KO16MSWIN949/UTF8/AL32UTF8 가능
KO16KSC5601 KO16MSWIN949 가능
KO16MSWIN949 UTF8 불가능
UTF8 AL32UTF8 가능
이 때까지 언급한 한글 문제를 한번에 해결할 수 있는 방법은 없을까? 이러한 문제를 해결하기 위한 고심의 산물이 바로 Unicode이다.
그렇다고 해서 Unicode가 만병통치약은 아님을 분명히 하고 시작을 하자.
CCS와 CES
Coded Character Set(CCS)은 각각의 문자에 대하여 비트로 표현할 수 있는 정수값에 각각의 문자 하나씩을 할당하는 방식을 말하며 한국에서는 KSC-XXXX 또는 ISO-XXXX로 표현하는 Character Set이 대표적인 예이다.
Character Encoding Schema(CES)는 각각의 문자에 대하여 16진수(Octet) 하나씩 할당하는 방식으로 CCS방식보다 많은 문자를 표현할 수 있다는 장점을 가지고 있다. 대표적인 CES는 UTF-8이다.
KO16MSWIN949( Code Page 949)
일 명 CP949로 불리우는 KO16MSWIN949는 MS가 기존에 사용하던 KSC5601에서 표현할 수 있는 한글 수 2350개 제한된 영역을 확장하여 추가적인 글자를 지원하는 Character Set이다. 일반적으로 조합형으로 알려져 있으나 실제는 MS에서는 확장완성형이라는 이름으로 발표했으며, Win98이후에 MS에 기본 코드로 사용되고 있다.
Unicode
Any platform, any program, any language라는 슬로건으로 모든 문자에 대하여 고유 번호(Code)가 할당된 것을 말하며, 이는 모든 나라의 언어를 하나의 CCS로 정의해 놓았으며, 이러한 CCS를 표현하는 여러 개의 CES가 존재한다는 개념이다.
- General Scripts Area(0000~1FFF) : Latin 계열 문자와 중동, 태국 문자 등의 할당 영역
- Symbol Area(2000~27BF) : 마침표, 느낌표와 같은 문자 기호와 숫자 등의 할당 영역
- CJK Phonetics and Symbols Area(3000~33FF) : 한국, 중국, 일본(CJK)에서 사용하는 음성/기호문자 할당영역
- CJK Ideographs Area(4E00~9FFF) : 한국, 중국, 일본(CJK)에서 사용하는 한자를 할당하는 영역
- Hangul Syllables Area(AC00~D7A3) : 한글 11172자를 할당하는 영역
- Surrogates Area(D800~DFFF) : 차후 사용목적으로 비어 있는 영역
- Private Use Area(E000~F8FF) : 사용자 및 공급자가 마음대로 사용할 수 있는 영역
- Compatibility Area and Specials (F900~FFFF) : 기존 Unicode안에 존재하는 값과 또 다른 값을 가지는 글자들을 할당하는 영역(일부 한자 포함)
Unicode와 한글 그리고 UTF 계열에 관해 살펴보자.
한글과 Unicode
기 존에 KSC5601에 문제점이 많았었는지 아니면 비 Latin 계열 문자의 설움인지 잘 모르지만, 한국은 처음부터 Unicode 표준 제정에 참가 하였다. 그 결과 Unicode에 독립적으로 한글만 표현할 수 있는 영역이 있을 정도다.
모든 표준이 그렇듯이 지금 Unicode 버전은 3.0이다.
- Unicode 1.X : KSC5601에 정의되어 있는 글자만 표현가능
- Unicode 2.X : 새로운 한글 영역에 한글 정의
- Unicode 3.X : Unicode 2.X 이후 한글부분에서는 변화된 내용없음
Unicode에서 한글 자모음은 1100~11FF에 240글자가 정의되어 있으며, 이는 훈민정음 이후 없어진 모든 글자들을 포함하고 있다. 그리고 이 부분에는 한글의 초성/중성/종성이 모두 포함되어 있다.
Unicode 에서 한글 음절은 한글영역인 AC00~D7A3에 한글자모음으로 정의된 조합형 코드인 초성(19개) X 중성(21개) X 종성(27개+1개(받침 없음)) = 11172개의 완성형 한글이 가나다 순으로 정의되어 있으며, 이 방식은 자모 조합과 자모 분리가 용이하여 모든 현대 한글 및 한글 고어도 표현이 가능하다.
Unicode 에서 한자는 CJK 상형문자 영역인 4E00~9FFF에 중국->일본->중국->한국 순으로 발음 기준으로 정의되어 있으며, CJK 상형문자 영역에 없는 한자는 CJK Compatibility Area adn Specials(F900~FA2D)에 별도 정의되어 있다.
Unicode CES
Unicode는 CCS이며 이런 Unicode를 표현하는 CES가 여러 개 존재한다. 대표적인 UTF-8도 Unicode를 표현하는 CES중 하나이다.
- UCS 2 : Unicode를 표현하는 CES에 표준이며 ISO/IEC10646의 CCS의 모든 문자를 2Bytes로
인코딩하여 검색, display, 구문해석에 용이한 특징이 있다.
- UTF-8 : ASCII 문자는 동일한 값에 1Byte로 표현, 유럽 및 기타 1Byte 글자는 2Bytes로 표현,
한국, 중국, 일본 한자 등은 3Bytes로 표현
KO16KSC5601(?)
보통 오라클을 설치하는 경우 KO16KSC5601을 많이 선택한다. 그러나 이것이 무엇을 의미하는지는 모르고 그냥 그렇게 설치하니까 설치하는 경우가 많다.
Character Set 명명 규칙을 보면 그 속에 담긴 모든 것을 알 수 있다.
Character Set 명명 규칙은 Language Code + Encoding Byte + Code Encoding Scheme 형태로 구성되어 있다.
즉, KO는 Language Code, 16은 Encoding Byte, KSC5601은 CES를 의미한다.
이 런 KO16KSC5601외 Oracle에서 사용하는 한글관련 Character Set은 KO16MSWIN949(CP949 Encoding을 사용하며 8.0.6이상 부터 사용함), KO16KSCCS(한글 조합형), KO16DBCS(IBM Mainframe EBCDIC문자)를 사용할 수 있다.
그리고 Uincode 관련 Character Set은 UTF-8, AL32UTF8, AL32UTF16등이 있다.
피드 구독하기:
글 (Atom)