5. 다국어 지원#
이 장에서는 Altibase가 지원하는 다국어 지원 구조 및 다국어 지원을 위한 환경 설정과 고려사항 등을 살펴본다.
개요#
다국어 지원을 한다는 것은 DBMS가 서로 다른 국가의 문자들을 저장하고 처리하는 것을 뜻한다. 즉, 하나의 DBMS로 한국어, 중국어, 일본어 등 서로 다른 문자를 사용하는 클라이언트에 대한 처리를 가능하게 한다.
문자 집합(Character-Set)#
어떤 특정 문자 집합을 숫자 값으로 나타낸 것을 의미한다. 아래 표는 하나의 문자를 UTF-8, UTF-16 BE, UTF-16 LE 캐릭터셋으로 인코딩할 때 각각 처리하는 값을 나타낸 표이다. 이와 같이 동일한 문자더라도 캐릭터셋을 변환하면 다르게 표현된다.
문자 | UTF-8 | UTF-16 BE | UTF-16 LE |
---|---|---|---|
A | 41 | 00 41 | 41 00 |
Ő | C3 B6 | 00 F6 | F6 00 |
NLS(National Language Support)#
특정 언어 환경에서 데이터베이스를 사용할 수 있도록 고안된 것이다. NLS를 지정하면 사용자의 애플리케이션에서 지정한 캐릭터셋으로 DBMS의 데이터를 읽거나 쓸 수 있다.
다국어 지원 구조#
다국어 지원은 데이터베이스의 캐릭터셋과 클라이언트 캐랙터셋 간의 변환에 의해 이뤄진다.
다국어 지원과 관련한 서버-클라이언트 관계를 다음 4가지로 분류하여 살펴본다.
-
동일한 캐릭터셋을 가진 데이터베이스와 클라이언트
-
상이한 캐릭터셋을 가진 데이터베이스와 클라이언트
-
상이한 캐릭터셋을 가진 데이터베이스와 다수의 클라이언트
-
유니코드 데이터 타입 지원
동일한 캐릭터셋을 가진 데이터베이스와 클라이언트#
데이터베이스와 클라이언트 간의 캐릭터셋이 서로 동일한 경우를 나타낸다.

위의 그림과 같이 데이터베이스도 KSC5601, 클라이언트도 KSC5601인 경우에는 캐릭터셋 간의 변환이 일어나지 않는다.
상이한 캐릭터셋을 가진 데이터베이스와 클라이언트#
데이터베이스와 클라이언트 간의 캐릭터셋이 서로 다른 경우에는 캐릭터셋 변환이 일어난다. 따라서 아래 그림과 같이 변환에 대한 손실이 있을 수 있다.

문자 변환에 따른 손실을 방지하려면 서버의 캐릭터셋은 클라이언트의 캐릭터셋을 포함하는 캐릭터셋이 되는 것이 유리하다.
즉 그림과 같이 문자 변환시 발생할 수 있는 손실을 방지하려면 데이터베이스의 캐릭터셋은 MS949가 되거나 이를 포함하는 UTF8로 설정해야 한다.
상이한 캐릭터셋을 가진 데이터베이스와 다수의 클라이언트#
다수의 클라이언트가 서로 다른 캐릭터셋을 가지는 경우 서버는 각각의 클라이언트 캐릭터셋을 모두 포함하는 캐릭터셋으로 지정해야 문자 변환에 따른 손실을 방지할 수 있다.

위의 그림은 하나의 데이터베이스와 연결된 각각의 클라이언트가 일본어, 중국어, 한국어 등을 사용하는 시스템 구성을 나타낸 것이다. 하나의 서버와 각각의 언어를 사용하고 있는 다수의 클라이언트 간의 문자 변환에 따른 손실을 막기 위하여 클라이언트들에서 사용되는 언어가 포함되는 캐릭터셋 UTF8을 데이터베이스 캐릭터셋으로 지정한다.
유니코드 데이터 타입 지원#
데이터베이스와 클라이언트가 각각 어떤 캐릭터셋으로 설정되었는지 상관없이 유니코드 데이터를 지원하는 NCHAR 또는 NVARCHAR 데이터 타입을 사용하여 다국어를 지원할 수 있다.
다국어 지원을 위한 캐릭터셋 분류#
데이터베이스 캐릭터셋#
데이터베이스에 저장되는 데이터의 캐릭터셋을 의미한다.
SQL 표준이 ASCII 캐릭터셋이므로 이를 포함하는 캐릭터셋은 데이터베이스 캐릭터셋으로 사용 가능하다. 단, UTF16은 ASCII 캐릭터셋을 포함하지 않기 때문에 데이터베이스 캐릭터셋에서 제외된다.
지정 방법#
데이터베이스 생성 시, CREATE DATABASE 구문에서 지정할 수 있다.
지원하는 캐릭터 셋#
Altibase는 데이터베이스 캐릭터셋으로 다음 8가지 캐릭터셋을 지원한다. 이들 캐릭터셋은 모두 ASCII 캐릭터셋을 포함한다.
-
US7ASCII
-
KO16KSC5601
-
MS949
-
BIG5
-
GB231280
-
MS936 (타 제품의 GBK, ZHS16GBK, CP936 등과 동일한 캐릭터 셋임)
-
UTF8
-
SHIFTJIS
-
MS932 (타 제품의 CP932 동일한 캐릭터 셋임)
-
EUCJP
내셔널 캐릭터셋#
NCHAR, NVARCHAR 데이터 타입에서 사용되는 캐릭터셋으로, 유니코드 기반의 문자를 저장할 수 있다.
지정 방법#
데이터베이스 생성 시, CREATE DATABASE 구문에서 지정할 수 있다.
지원하는 캐릭터 셋#
Altibase는 내셔널 캐릭터셋으로 다음 2가지 캐릭터셋을 지원한다.
-
UTF8
-
UTF16 (Big Endian)
클라이언트 캐릭터셋#
데이터를 검색할 때 사용자에게 보여주는 클라이언트의 캐릭터셋이다.
서버로부터 전송된 데이터는 모두 클라이언트에서 지정한 캐릭터셋으로 변환되어 사용자에게 보여준다.
지정 방법#
환경변수 ALTIBASE_NLS_USE에서 지정할 수 있다.
지원하는 캐릭터 셋#
-
US7ASCII (기본값)
-
KO16KSC5601
-
MS949
-
BIG5
-
GB231280
-
MS936
-
UTF8
-
UTF16 (Big Endian)
-
SHIFTJIS
-
MS932
-
EUCJP
유니코드를 이용한 다국어 지원#
유니코드란 어떤 언어로 된 정보도 단일 캐릭터셋으로 저장할 수 있는 국제적으로 부호화된 캐릭터셋을 말한다. 또한 유니코드는 플랫폼, 프로그램 언어에 관계 없이 모든 문자는 유일한 값을 가진다.
따라서 여러 나라의 언어를 동시에 저장하고자 할 경우에 유용하게 사용할 수 있는 코드이다.
유니코드 인코딩#
유니코드 인코딩은 유니코드를 컴퓨터에 저장하기 위하여 바이트에 맵핑하는 방식이다.
Altibase는 코드 체계 또는 문자 집합을 표현하기 위해 UTF-8 또는 UTF-16과 같은 인코딩 방식을 사용한다.
유니코드의 저장#
데이터베이스에 유니코드 문자를 저장하는 방법으로 다음 2가지가 있다.
-
데이터베이스를 생성할 때 유니코드 캐릭터셋으로 데이터베이스를 생성하는 방법
-
NCHAR 또는 NVARCHAR 칼럼을 이용하는 방법
데이터베이스 캐릭터셋은 UTF8이고, 내셔널 캐릭터셋은 UTF16인 경우에는, 유니코드 문자를 저장하는 2가지 방법을 같이 사용할 수 있다.
유니코드 데이터베이스#
데이터베이스 생성 시, 데이터베이스 캐릭터셋을 UTF8로 설정하여 유니코드를 지원하는 데이터베이스를 생성하면, CHAR, VARCHAR 칼럼에 유니코드 데이터를 저장할 수 있다.
사용할 수 있는 캐릭터 셋#
- UTF8
유니코드 데이터베이스가 필요한 경우#
-
SQL 문장이나 저장 프로시저에 유니코드 데이터를 포함하고 있는 경우
-
언제 어느 칼럼에 다국어 데이터가 들어올지 모르는 경우
유니코드 데이터 타입#
데이터베이스 캐릭터셋을 UTF8이 아닌 다른 캐릭터 셋으로 설정하여 데이터베이스를 생성했을 때에도 유니코드 데이터 타입인 NCHAR 또는 NVARCHAR 데이터 타입에 유니코드 문자를 저장할 수 있다.
사용할 수 있는 캐릭터 셋#
-
UTF8
-
UTF16
유니코드 데이터 타입이 필요한 경우#
-
유니코드 데이터베이스가 아닌데 다국어 데이터를 저장할 칼럼이 필요한 경우
-
대부분 같은 언어의 데이터이지만, 일부 데이터가 다국어로 저장할 칼럼이 있는 경우
다국어 데이터베이스를 위한 환경 설정#
다국어를 지원하는 데이터베이스 환경을 구축하기 위해 아래와 같은 방법으로 설정해야 한다.
-
서버를 가장 많이 사용하는 클라이언트의 언어를 고려하여 데이터베이스 생성시 캐릭터셋을 지정한다.
-
클라이언트 캐릭터셋에 맞는 NLS를 지정한다.
-
기타 환경변수 및 프로퍼티를 지정한다.
환경변수 설정#
클라이언트에서 아래의 환경변수를 설정한다.
-
ALTIBASE_NLS_USE
-
ALTIBASE_NLS_NCHAR_LITERAL_REPLACE
ALTIBASE_NLS_USE#
클라이언트의 캐릭터셋을 아래와 같이 지정할 수 있다. 서버로부터 전송된 데이터는 모두 클라이언트에서 지정한 캐릭터셋으로 변환되어 사용자에게 보여준다.
-
US7ASCII (기본값)
-
KO16KSC5601
-
MS949
-
BIG5
-
GB231280
-
MS936
-
UTF8
-
SHIFTJIS
-
MS932
-
EUCJP
ALTIBASE_NLS_NCHAR_LITERAL_REPLACE#
이 환경 변수의 값이 1(TRUE)로 설정되어 있을 때, SQL문 내의 "N" 문자가 앞에 붙어있는 NCHAR 리터럴은 클라이언트에서 데이터베이스 캐릭터셋으로 변환되지 않고 서버로 그대로 전송되어 서버에서 내셔널 캐릭터셋으로 변환된다. 이 환경 변수의 기본값은 0(FALSE)이다.
일반적으로 실행된 SQL문은 클라이언트에서 데이터베이스 캐릭터셋으로 변환되어 서버로 전송된다. 이 일반적인 방식으로는 데이터베이스 캐릭터 셋이 US7ASCII인 데이터베이스에 NCHAR 칼럼을 만들어도 해당 칼럼에 US7ASCII 캐릭터셋을 벗어나는 데이터를 넣지 못한다.
예를 들어 클라이언트 캐릭터셋이 KO16KSC5601이고, 데이터베이스 캐릭터셋이 US7ASCII인 경우, INSERT 구문을 실행하면 클라이언트 쪽에서 INSERT 구문 전체를 클라이언트 캐릭터셋 KO16KSC5601에서 데이터베이스 캐릭터셋 US7ASCII으로 변환한다. 이 때 아래의 예문과 같이 '안'이라는 문자는 US7ASCII로 변환될 수가 없기 때문에 US7ASCII 캐릭터 셋의 대체 문자(replacement character)인 '?'로 변환, 서버로 전송되어 테이블에 저장된다.
iSQL> CREATE TABLE t1 ( i1 NVARCHAR(10) );
Create success.
iSQL> INSERT INTO t1 VALUES ( '안' );
1 row inserted.
iSQL> SELECT * FROM t1;
I1
--------------------
?
따라서 데이터베이스 캐릭터셋을 벗어나는 캐릭터를 NCHAR 칼럼에 저장할 수 있는 방법이 필요하다. 그 방법 중 하나가 아래와 같이 환경 변수를 설정하고, NCHAR 리터럴을 사용하는 것이다.
$ export ALTIBASE_NLS_NCHAR_LITERAL_REPLACE=1
...
iSQL> CREATE TABLE t1 ( i1 NVARCHAR(10) );
Create success.
iSQL> INSERT INTO t1 VALUES ( N'안' );
1 row inserted.
iSQL> SELECT * FROM t1;
I1
--------------------
안
위와 같이 ALTIBASE_NLS_NCHAR_LITERAL_REPLACE 환경 변수를 1(TRUE)로 설정하면, SQL문 내의 "N"문자가 앞에 붙어있는 NCHAR 리터럴은 클라이언트에서 데이터베이스 캐릭터셋으로 변환되지 않는다. 대신에 이 리터럴은 그대로 서버로 전송되어 서버에서 내셔널 캐릭터셋으로 변환된다.
예제#
다음은 기본 데이터베이스 캐릭터셋을 KSC5601로 사용하고, 내셔널 캐릭터셋은 UTF16으로 사용하는 환경을 구축하는 과정을 설명한다.
데이터베이스 생성#
iSQL(sysdba)> CREATE DATABASE mydb INITSIZE=10M NOARCHIVELOG CHARACTER SET KSC5601 NATIONAL CHARACTER SET UTF16;
DB Info (Page Size = 32768)
(Page Count = 257)
(Total DB Size = 8421376)
(DB File Size = 1073741824)
Creating MMDB FILES [SUCCESS]
Creating Catalog Tables [SUCCESS]
Creating DRDB FILES [SUCCESS]
[SM] Rebuilding Indices [Total Count:0] [SUCCESS]
DB Writing Completed. All Done.
Create success.
클라이언트 환경 설정#
클라이언트에서 KSC5601을 사용하는 경우 다음과 같이 환경변수를 설정한다.
$ export ALTIBASE_NLS_USE=KSC5601
만약 클라이언트에서 ASCII를 사용할 때에는 다음과 같이 환경변수를 설정한다.
$ export ALTIBASE_NLS_USE=ASCII
기타 환경 변수 및 프로퍼티 설정#
사용 환경에 따라 아래의 환경변수 및 프로퍼티를 지정한다.
-
환경변수
ALTIBASE_NLS_NCHAR_LITERAL_REPLACE
-
프로퍼티
NLS_COMP 또는 NLS_NCHAR_CONV_EXCP
데이터베이스 캐릭터셋 선택 시 고려사항#
데이터베이스 캐릭터셋을 결정할 때 문자 변환시 발생할 수 있는 손실 및 변환 비용, 식별자 등을 고려하여 선택해야 한다.
사용범위#
식별자(Identifier)#
칼럼 이름, 스키마 객체, 주석 등은 데이터베이스 캐릭터셋으로 데이터베이스에 저장된다. 그러나 그 외의 식별자는 US7ASCII 이외의 캐릭터셋으로 사용할 수 없다.
식별자별로 사용할 수 있는 캐릭터셋을 구분하면 다음과 같다.
식별자 이름 | 사용 가능한 캐릭터셋 |
---|---|
칼럼 이름 | 데이터베이스 캐릭터셋 |
스키마 객체 | 데이터베이스 캐릭터셋 |
주석 | 데이터베이스 캐릭터셋 |
데이터베이스 링크 이름 | 데이터베이스 캐릭터셋 |
데이터베이스 이름 | US7ASCII |
파일 이름 (데이터 파일, 로그 파일 등) | US7ASCII |
디렉토리 이름 | US7ASCII |
키워드 | US7ASCII |
테이블스페이스 이름 | US7ASCII |
[표 5‑1] 식별자별 사용 가능한 캐릭터셋
저장되는 SQL문#
저장 프로시저나 트리거 생성 구문 같은 SQL문은 데이터베이스 캐릭터셋으로 메타 테이블에 저장된다.
제약 사항#
데이터베이스 캐릭터셋이 상이한 데이터베이스와의 이중화는 불가능하다.
문자 변환시 영향#
데이터베이스 캐릭터셋이 클라이언트 캐릭터셋과 다르면 변환이 발생한다. 이러한 문자 변환시 데이터 손실이 잠재적으로 일어날 수 있을 뿐 아니라 성능 저하에도 영향을 줄 수 있다.
데이터 손실#
표현할 수 있는 범위가 큰 캐릭터셋에서 작은 캐릭터셋으로 변환이 일어날 경우, 데이터 손실이 발생한다.
이처럼 변환 대상인 문자가 변환할 문자가 없을 때 대체 문자(US7ASCII 캐릭터셋의 경우 '?' 문자)로 변환하게 된다.
변환 비용#
모든 클라이언트의 캐릭터셋이 동일한 캐릭터셋을 사용하고, 같은 캐릭터셋으로 데이터베이스의 캐릭터셋을 설정하여 데이터베이스를 생성하였다면 문자 변환은 일어나지 않는다.
하지만 클라이언트가 각각 서로 다른 캐릭터셋을 사용하여 데이터베이스 캐릭터셋을 클라이언트들의 수퍼셋으로 캐릭터셋을 지정했다면, 캐릭터셋의 변환이 발생한다.