그림: 대표적인 지역화 프로그램인 hanterm과 대표적인 국제화 프로그램인 Netscape
[ Home | Freetime works | FreeBSD | KFUG ]
프로그램세계 1999년 3월호이 문제는 이전부터 유닉스 사용자에게 큰 불편함을 가져다 주는 것이었고, 이미 리눅스 등 이 사용되기 이전에 워크스테이션 유닉스 사용자들에 의해 여러 가지 해결 방법이 나오고 있었고, 유닉스가 소프트웨어의 국제화와 지역화를 위한 여러가지 기본 구조를 채택함에 따 라 표준화된 또는 널리 사용되고 있는 이 틀을 따르게 프로그래밍하는 것도 중요한 일이 되 었다.
이 연재에서는 현재 공개 유닉스에서 사용할 수 있는 여러가지 프로그램들을 중점으로 하 여, 자유로운 한글 사용을 위한 소프트웨어들과 이들의 구조에 대해 알아보도록 한다. 이번 회에서는 이에 따른 기초 지식에 대해 알아보자.
PC에서 사용할 수 있는 MS-DOS의 경우, 이런 문제를 해결하기 위해서 여러가지 방법이 제시되었다.
전자의 경우에는 여러가지 한글 카드가 존재했고, 후자의 경우 한글 도깨비 등의 여러가지 램상주 소프트웨어나 한글 MS-DOS등의 운영체제 수준의 해결책이 존재하지만, 하드웨어 카드나 별도 소프트웨어의 경우 컴퓨터의 속도가 빨라지고 한글 MS-DOS등이 나오면서 점 차 사라지게 되었다. 이후 90년대 이후 윈도가 나오면서, 영문 윈도에서 한글 사용을 위해 한메 한글등의 소프트웨어가 사용되기도 하였지만, 이것도 이후 한글판 윈도가 별도로 나오 게 되면서 곧 사라지게 되었다. 최근에는 윈도 95, 98, NT가 모두 한글화된 버전이 나오게 되었고, 이들 운영체제는 모두 별도 소프트웨어의 필요가 없이 기본적으로 한글 입출력(화 면 뿐만이 아니라 프린터 출력까지)이 가능하게 되어 대부분의 윈도 사용자는 최근에는 한 글 문제에 대해 별다른 문제점을 느끼지 못한다.
그러나 유닉스의 경우에는 기본적으로 한글화에 대한 필요성이 PC기반의 윈도에 비해 상대 적으로 적었다. 이는 기본적으로 서버에 터미널을 연결해 사용하던 워크스테이션의 사용 방 식과, GUI가 사용자 요구에 맞게 크게 발전하지 못했던 탓이기도 하였으며, 이들 워크스테 이션이나 서버에서 직접 한글 입출력을 해야 했던 경우는 거의 없었고 내부적으로 파일 저 장이나 데이터베이스 등의 문제만 해결하면 충분하였기 때문이다. 이런 데이터의 저장 문제 는 입출력 문제 대신 한글 코드의 문제로 이어지게 된다. 최근에는 기존의 PC에서 윈도나 OS/2 이외의 유닉스 계열 운영체제들이 데스크탑 사용자에게 점점 많이 사용되고 있다. 리 눅스나 FreeBSD, 넓게는 BeOS등이 그런 것으로, 이들은 기존 유닉스에서 제공하는 서버의 기능 이외에도 기존 유닉스의 분야가 아니었던 데스크탑에서의 GUI어플리케이션의 필요에 따라 사용자에게 친근한 여러가지 배려를 하고 있다.
유닉스의 국제화/지역화의 개념은 이와 별도로 소프트웨어가 영어권 이외의 국가에서 널리 사용됨에 따라 자연스럽게 나타나는 현상이지만, 최근의 GUI어플리케이션의 추세와 맞물려 서로 긴밀한 관계를 갖고 있다. 아무리 내부 시스템에서 올바르게 다국어 처리를 하더라도 이를 화면에 보여주지 않으면 데스크탑 소프트웨어로 사용되기에는 여러운 점이 많기 때문 이다.
그림: 대표적인 지역화 프로그램인 hanterm과 대표적인 국제화 프로그램인 Netscape
이중 우리는 대부분의 경우 1)과 2)만 해결되면, 그중에서도 데이터의 별도 입력이 필요없 는 소프트웨어의 경우 2)만 해결되면 이 프로그램에서 한글 사용이 가능하다고 말한다. 그 러나 실제로 더 구체적으로 들어가게 되면 3), 4), 5), 6)의 분야도 중요하며, 이는 어플리 케이션의 자연스러운 사용에 크게 도움을 준다. 예를 들면 익스플로러나 넷스케이프의 경우 영문판도 한글 윈도에서 무리없이 작동하지만 한글 메뉴나 도움말이 나오는 한글판이 더 친 숙하고 사용하기에 편리하지 않은가? 특히 인터넷 상의 데이터 전송 (데이터베이스, 전자우 편, 뉴스 등)에서는 3)의 문제가 크게 중요하다. 소프트웨어의 국제화 로케일 모델에서는 위 모든 분야에 대해 일반적으로 사용할 수 있는 인터페이스를 제공한다. 입력을 위한 다국어 입력기의 모델과, 출력을 위한 다국어 출력 API, 표준화된 해당 언어의 인코딩 방법, 문자 열 정렬표나 시간, 통화표시의 방법 등이다. 메시지 출력의 경우 일반적으로는 잘 사용하지 않으므로 널리 사용되는 인터페이스는 없지만, 각 유닉스들은 그 유래에 따라 여러가지 인 터페이스를 사용하고 있다. XPG4의 catopen()이나 POSIX의 gettext()가 그것으로, 오픈 소 스 소프트웨어에서는 최근에 GNU gettext를 사용한 소프트웨어가 많아지고 있다.
글자셋(character set) 글자셋은 컴퓨터에 직접 저장하는 비트 열이 아니라, 해당 언어로 표현할 수 있는 글자들의 집합이다. 우리글의 경우 완성형 코드(KSC5601-1987)에서는 2350자의 한글 문자와 4888자의 한자 등으로 구성되며, ASCII의 경우 영문 알파벳과 기호 로 구성된다. 해당 글자가 실제로 어떤 값으로 저장될 지는 모른다(말 그대로 집합일 뿐이 다).
인코딩(encoding) 글자셋을 실제로 어떤 방법으로 컴퓨터에서 저장할 지를 나타낸다. 예 를 들면 "가"에 해당하는 값은 인코딩 방법에 따라서 0x24 0x21(ISO-2022-KR)로 나타낼 수도 있고, 0xa4 0xa1(EUC-KR)으로 나타낼 수도 있다. 인코딩은 글자셋의 각 원소를 실제 의 코드값으로 대응하는 함수에 해당한다고 생각할 수 있다.
우리말에도 국제 표준(ISO-2022)을 따르지 않는 조합형과 국제 표준을 따르는 완성형이 있듯이, 각 나라도 그러한 인코딩 방법을 가질 수 있다. 예를 들면 MS의 일본어 제품에서 는 SJIS(Shift JIS)라는 방법을 사용하지만, 이는 국제 표준에는 맞지 않음에도 널리 사용되 고 있다.
한글 조합형 코드는 현대어의 거의 모든 글자를 표현할 수 있고 한글 창제 원리에 부합한 다는 장점으로 많은 사람들이 지지했지만, 완성형 코드의 출현 이후 거의 사용되지 않고 있 다. 아직도 많은 사람들이 조합형 코드의 사용을 바라지만, 이것이 1992년 표준의 하나로 제정되었음에도 불구하고 현재는 거의 대응 어플리케이션이 개발되지 않고 있다. 조합형에 는 각 컴퓨터 회사별로 서로 비표준의 인코딩이 존재했지만 일반적으로 조합형이라면 "상용 조합형"이라는 것을 의미한다.
KSC5601 완성형은 통일된 한글 코드를 만들고자 하는 노력의 산물로, ISO의 정보 교환 규격을 만족한다는 장점이 있지만 우리가 확장할 수 있는 코드 영역이 제한된 관계로 모든 한글 코드 대신 많이 쓰이는 빈도순 대로의 글자를 포함하게 되었다. 이는 현대어의 한글도 제대로 표현하지 못한다는 비난과, 창제 원리에 어긋난다는 비난을 많이 받았지만, 현재로 서는 표준으로 굳어진 상태이다. 완성형의 의의라면 이는 공인받은 한국어의 가장 널리 알 려진 인코딩으로, 외국에서도 아시아 언어판 소프트웨어를 만드는 사람들은 대부분 잘 알고 있다. 특히 유닉스에서의 로케일 모델은 한글의 경우 기본적으로 EUC-KR를 지원하고, 전 자우편 교환에 사용하는 ISO-2022-KR인코딩의 경우도 완성형 문자셋으로 표현된다. 통합완성형(UHC, Unified Hangul Codeset)은 마이크로소프트에서 한글 윈도 95가 나올때 발표한 것으로, 기존의 코드페이지 949(EUC-KR의 마이크로소프트식 용어)를 확장하여 조 합형에서 사용할 수 있는 나머지 한글 글자 8000여자를 EUC표준의 영역 외에 배치한 것이 다. 발표시 많은 논란이 있어서 지금은 거의 사용하지 않고 윈도의 내부에 감추어진 상태이 다.
EUC-KR ASCII인코딩에서 백슬래시를 원화 기호(\)로대체한 KSC5636과 KSC5601-1987 문자셋을 MSB가 1인 영역에 대응시킨 것을(정식으로 말하자면 GL이나 GR플레인등의 ISO의 용어들이 나오므로 생략하도록 하자. 우리가 알고 있는 일반적인 완성 형 코드 - 한글을 나타내는 각 바이트의 MSB가 1인 - 를 생각하면 된다) 동시에 말한다. EUC-KR로 작성된 문서라면 단순히 한글과 영어가 섞인 텍스트라고 생각하면 된다. EUC는 2바이트 이상의 멀티바이트 인코딩을 표현하기 위한 방법의 하나로, Extended UNIX Codeset의 약자이다. 사실 EUC-KR이란 인코딩이 정의된 곳은 ISO-2022-KR이 소개된 RFC 1557인데, 이후 실제적으로 유닉스에서 널리 사용되는 이름이 되었고, 전자우편 등에 서 완성형 한글 코드와 영문을 포함한 인코딩 이름으로 사용되고 있다.
KSC5601은 현재 KSX1001로 바뀌었다.
유니코드는 모든 문자를 하나의 2바이트 문자로 표현하고자 하는 노력의 산물이다. 실제적 으로는 32비트 코드인 ISO-10646의 기본 다국어 평면(Basic Multilingual Plane, BMP)이 다. ISO-10646은 32비트 코드인데, 이중에서 위쪽 16비트는 0이고 아래 16비트만을 사용 하는 것을 BMP라 부르고, 이를 아래 2바이트만으로 표현해서 유니코드라고 부른다. 현재 유니코드 2.1이 나와 있는데, 한글의 측면 만으로 살펴보면 버전에 따라 약간 다른점이 있 다.
유니코드는 단순히 문자셋에 해당한다. 이를 실제로 컴퓨터에 저장하기 위해서는 여러가지 인코딩을 사용하는데, 2바이트 그대로 사용하는 (32비트 모두를 사용하기 위한 약간의 확장 이 들어있다) UCS-2, ASCII나 ISO-8859-1등의 1바이트 인코딩과 호환을 이루기 위한 UTF-8, 7비트 문자셋과 호환성을 갖기 위한 UTF-7인코딩 들이 있다(생소한 이름들이지만 최근의 익스플로러 4.x나 넷스케이프 4.x의 인코딩 메뉴에서 볼 수 있는 것들이다). 최근의 여러 운영체제(Windows, Unix)등에서 모두 표준으로 사용하고 있거나 지원 예정에 있다. 리눅스나 FreeBSD에서는 지원 계획은 있으나, 아직 완벽하게 사용할 수는 없다. 솔라리스 의 경우 2.6이상부터 UTF-8인코딩 등을 지원한다. 유니코드의 경우 모든 나라 언어를 동시 에 표시할 수 있으므로, 한국어도 UTF-8인코딩을 사용할 수 있고 일본어도 UTF-8인코딩을 사용할 수 있다.
유니코드와 ISO-2022 유니코드의 장점이라면 모든 언어의 모든 글자를 포함한다는 것이 지만, 실제적인 사용에 있어서는 여러가지 단점이 있다. 그중 하나는 해당 글자는 알 수 있 어도 언어를 구별할 수 없다는 점과 (한자의 경우 현재 어느나라 언어의 한자인지 구별할 수 없다) 따라서 하나의 글꼴로 모든 코드의 문자를 표현할 수 없다는 점이다(같은 코드라 도 한중일 글꼴에서는 모양이 모두 다를 수 있다). ISO-2022는 멀티바이트 인코딩이고 인 코딩과 코드셋 제어를 위한 에스케이프 시퀀스를 사용하여 텍스트 내에서 현재의 상태(인코 딩과 문자셋)를 유지한다. 이는 처리는 복잡하지만 어느 나라 언어라도 안전하게 나타낼 수 있다는 것을 의미한다. 이런 이유로 인해 유니코드에 반대하는 사람들도 많이 있다.
유니코드라고 하면 무조건 한글자가 2바이트라 아는 경우도 많은데, 인코딩 방법에 따라 1-6바이트까지의 멀티바이트 인코등으로 표현할 수 있다. 이는 기존 ASCII와 ISO-8859-1 코드와의 호환성을 유지하기 위한 것이다. 운영체제와 언어 코드에 대해서 중요한 것은, 운 영체제가 내부적으로 어떤 코드를 사용하는지에 관계없이 사용자에게는 표준적인 코드로 보 여주면 된다는 것이다. 예를 들어 현재 완성형이 실질적인 표준인 상황에서, 운영체제가 내 부적으로 한글 코드를 표현하는데 조합형을 사용하든, 유니코드를 사용하든 최종적으로 사 용자에게는 완성형 한글을 다룰 수 있는 기능을 제공하면 된다는 것이다. 통합 완성형이 소 개되었을때 많은 논란이 되었던 것은 운영체제가 내부적으로 통합 완성형을 사용하고 이를 겉으로 드러내지 않아서 결과적으로 이를 사용한 어플리케이션 작성 자체를 가능하게 한다 는 것이었는데, 사실 최근의 프로그램 작성의 경우 간단한 문자열 비교의 경우에도 라이브 러리의 API를 사용하므로, 숫자 순으로 정렬이 되지 않는 통합 완성형의 경우에도 적절한 문자열 비교 API를 제공한다면 내부 구현에 상관없이 원하는 프로그램을 작성할 수 있다.
이는 입출력과는 관계없이 완성형 한글 코드를 저장하기 위한 것이다. US-ASCII코드는 한 바이트의 MSB를 사용하지 않으므로, MSB의 유무로 한글인지를 구별하게 되는 일반적인 완성형 코드에서는 MSB를 잘라내는 프로그램의 경우 한글과 아스키 문자를 구별할 수 없 게 된다. 이는 영어권 위주의 프로그램에서 많이 발생하는데, MSB를 문자와는 별도의 목적 으로 사용하거나 의도적으로 잘라내는 경우에는 데이터의 원활한 저장을 위해 MSB를 보존 하도록 해야 한다. 즉 C코드의 경우라면
newc = c & 0x7f;와 같은 코드가 있다면 이를 없애야 한다. 만일 MSB를 별도의 목적(데이터의 시작과 끝을 구분하거나 글자에 별도의 정보를 주기 위한)으로 사용한다면 이를 따로 분리할 수 있는 다 른 방법을 강구해야 하며, 이는 보다 어렵다. 또 하나의 예는 char자료형을 사용하는 경우인데, 기본적으로 char라고 하면 signed char 이므로, MSB가 있는 코드의 경우에는 음수로 나타나게 된다. 만일 다음과 같은 코드가 있 다면,
char c;
c=get_one_char();
if (c>0) {
...
}
c에서 한글의 일부를 읽었다면 이는 음수로 취급되어 위 문장을 제대로 수행할수 없게 된
다. 이를 해결할 수 있는 방법으로는 문자형을 사용할 때 int형이나 unsigned char형을 사
용하는 것이 있다.
이런 문제는 독일어나 프랑스어 등의 서유럽어를 나타내는 ISO-8859-1코드에서도 동일하 게 적용되는 것이다. 따라서 이들 언어를 지원하는 프로그램에서는 이런 배려가 이미 되어 있다. 알짜 리눅스의 경우 한글 매뉴얼 페이지를 나타내기 위해 사용하는 groff에서 -Tlatin1옵션을 주어서 8비트 문자가 모두 통과되도록 하는데, 실제적으로 이는 ISO-8859-1 문자셋을 사용하라는 옵션이며, ISO-8859-1의 한 글자가 나타내는 범위가 이 는 EUC-KR에서 나타낼 수 있는 범위를 모두 포함하므로 우리가 한글 매뉴얼 페이지를 볼 때에는 큰 문제가 발생하지 않는 것이다. 하지만 groff 자체에는 한글을 위한 배려가 되어 있지 않으므로 프린터 출력이나 텍스트 이외의 다른 포맷으로 출력할 경우에는 잘 되지 않 을 것이다. 다른 용어로 이런 것을 표현하면 8-bit clean이라고 하는데, MSB를 자르지 않 고 그대로 전달한다는 의미이며, 어떤 언어 코드를 저장하기 위해서는 기본적으로 지켜야 할 원칙 중의 하나이다. 대부분의 데이터 저장에 관련된 어플리케이션의 경우 8-bit clean 을 지원하는 것만으로도 충분한 경우가 많다. Tcl과 같은 언어의 경우 버전 8.1 이전에는 언어 인코딩에 대한 지원 없이 단순히 8-bit clean만을 지원하였다.
이 방법은 가장 간단한 것이지만, 글자 단위의 구분이 불가능하여 한 글자의 중간을 잘라내 게 될 가능성도 있고, 글자 단위의 문자열 비교도 불가능하게된다.
글자 단위로 동작하고자 하는 것을 추가하기 위해서는 간단한 알고리즘을 사용하면 된다. 완성형 한글 코드의 경우 일반적인 US-ASCII(0x20-0x7e) 이외에 0xa1-0xfe사이에 있는 글자가 나오면 한글 코드로 인정하면 된다. 다만 문자열 중간에서 한글 범위에 있는 글자를 만났을 경우, 이것이 한글의 첫번째 바이트인지 두번째 바이트인지를 판정하기 위해서는 문 자열의 앞뒤를 조사해야 하며, 가장 좋고 확실한 방법은 문자열의 처음부터 한글자 한글자 세어나가는 것이다. 대략 다음과 같은 코드가 된다. 실제 가질 수 있는 상태는 이보다 많음 에 주의하기 바란다.
int han_state=ENG; /* ENG, HAN1, HAN2, NONE */
if (c >= 0x20 && c <= 0x7e) {
... ASCII ...
} else if (c >= 0xa1 && c <= 0xfe) {
if (han_state == ENG){
... 한글 첫 번째 바이트 ...
han_state=HAN1;
} else if (han_state == HAN1}{
... 한글 두 번째 바이트 ...
han_state=HAN2;
}
} else {
... 어느것도 아님 ...
han_state=NONE;
}
이는 영문 입출력 기능밖에 없는 프로그램에 자체적인 한글 입출력 기능을 추가하는 것이 다. 일반적으로 2/3벌식 한글 오토마타를 사용한 입력 기능과 한글 출력 기능을 추가하게 된다. 대표적인 예는 xterm에 한글 입출력 기능을 추가한 hanterm인데, hanterm은 리눅스 등장 이전부터 유닉스 사용자를 위한 한글 터미널로 개발된 것이다. hanterm은 이후 발전 을 거듭하여 조합, 완성, UTF-8까지 지원하는 터미널 에뮬레이터가 되었으며, 내부적으로 사용된 코드는 han, hanemacs, hanX 등 여러 가지 한글 관련 프로그램에 영향을 미치게 되었다. hanterm-xf라는 것이 최근에 별도로 개발되고 있는데, 이는 거의 모든 플랫폼에서 컴파일되는 hanterm과는 달리 리눅스나 FreeBSD등의 X11R6플랫폼에 중점을 맞추고, 선문 자 보호 기능등을 추가한 것이다.
독자적인 입출력 기능의 추가는 프로그램을 사용하는 사람이 별도의 조건을 갖추지 않아도 (한국어 로케일이나 입력 서버 등) 된다는 장점이 있지만, 하나의 프로그램을 한글화 할때 마다 입력 오토마타나 출력에 필요한 루틴을 일일이 추가한다는 것은 중복된 작업이 된다.
메시지 번역은 프로그램에 하드 코딩된 메뉴나 오류 메시지들을 찾아내어 이를 한글로 번역 하는 것이다. 아직도 많은 프로그램들은 자신의 코드 안에 출력하는 메시지들을 포함하고 있는데, 이 메시지들을 번역하는 것으로 사용자는 보다 친숙한 환경 아래에 놓일 수 있다. 메시지 번역에서 유의할 것은, 어떤 문장을 번역할 것인가와 어떻게 번역해야 할 것인가의 문제를 생각해야 한다. 전자의 예를 든다면
"From: cjh@wdb.co.kr"
이란 문구가 C코드에 있다고 하면, 이를 보고 이것이 RFC822 전자우편 헤더에 들어갈 말 인지 그대로 번역해도 되는 말인지에 대해 원래 어플리케이션의 의도를 생각하고 번역해야 한다. 위 문구가 전자우편이나 뉴스의 헤더에 들어갈 것이라면 From:을 "송신:"으로 번역해 서는 안된다. 후자의 경우는 다음 예를 생각해 보면 알 수 있다.
"%d of %d"
우리말의 어순과 영어의 어순은 다르지만, C스타일의 코드에서는 이를 필요에 따라 바꾸어 줄 방법이 없다. 위 문장이 "%d개 중의 %d개"라고 번역되어야 한다면, 두 %d의 순서를 바 꾸어 주어야 할 필요성이 생긴다. 현재는 이를 해결할 방법은 메시지가 아닌 나머지 코드 자체를 수정하는 방법이 있겠지만, 매우 번거롭고 불필요한 작업을 하게 되므로 되도록 순 서를 유지하면서 우리말로 표현하는 방법을 생각해 보는 것이 좋겠다.
최근 유닉스와 NT등 운영체제에는 다국어 환경을 위한 배려가 되어 있다. 운영체제마다 용 어는 조금씩 다르지만 대략적인 내용은 비슷하며, 대부분의 경우 외국에서 개발된 프로그램 이라도 일본어나 한국어, 중국어 등을 지원할 수 있는 프레임웍이 갖추어져 있는 경우가 대 부분이다. 유닉스에서는 C라이브러리의 로케일 인터페이스를 기초로 하여 X 윈도우 시스템 의 국제화가 X11R5때부터 적용되어 있고, 이는 한국어를 포함하므로 어플리케이션을 작성 하는 사용자는 이를 어떻게 초기화하고 사용하는지에 대해서 알아보면 된다. 그러나 유닉스 의 경우 X11시스템에서는 국제화 기능을 지원하고 있지만 콘솔 어플리케이션이나 C라이브 러리에서의 국제화 기능은 아직 한중일 언어와 같은 멀티바이트 인코딩을 제대로 지원하지 않으므로(리눅스의 경우 glibc 2.2에서 제대로 지원할 예정이고, 현재 glibc 2.0이나 glibc 2.1과 같이 사용하는 추가 패키지가 나온 상태이다) 이에 대해서는 충분히 주의해야 한다. 일반적으로 유닉스의 국제화 환경의 경우 C 로케일 인터페이스에서 문화의 차이, 언어, 인 코딩 등을 포함하고, X11에서는 이에 기반한 다국어 입력기와 출력 인터페이스를 제공한다. 윈도와 조금 다른 것은 프린터 출력은 이런 기능의 혜택을 받지 못하므로, 한글 문자를 프 린터에 출력하는 방법에 대해서는 별도로 생각해 보아야 한다.
프로그램의 코드와 메시지를 분리하는 것은 국제화 프로그램 작성에 있어서 꼭 필요한 것이 다. 이는 해당 국어 사용자에게 쉽게 읽을 수 있는 인터페이스를 제공하게 되며, 코드와 메 시지의 분리는 프로그램 개발자는 프로그램 개발에 전념할 수 있고 메시지 번역자는 자국 언어를 위해 주어진 메시지 파일을 번역하기만 하면 된다는 장점이 있다.
일반적인 프로그램의 경우 catopen()이나 xgettext()등의 C라이브러리 인터페이스가 제공되 는데, 최근에는 GNU gettext가 개발되면서 이를 바탕으로 한 프로그램들이 많이 생겨났고, 각국에서 이들 프로그램의 메시지를 번역하기 위한 번역 팀이 발족되어 활동하고 있다. X11 프로그램의 경우 리소스 데이터베이스에 메시지를 포함할 수 있으므로, 번역자는 프로 그램과는 상관없이 리소스 파일에 있는 메시지만을 번역하고 이를 해당 로케일용의 리소스 디렉토리에 넣어 두면 자신의 언어 환경 안에서 해당 메시지를 보도록 할 수 있다.
이는 꼭 필요하지 않거나, 지역화의 범주에 넣을 수 있는 것이다. 코드 변환의 경우는 우리 의 경우 hcode나 hmconv등의 프로그램이 있지만 이는 지역화 범주에 들어갈 수 있는 프 로그램이고, GNU recode와 같이 다국어 인코딩을 동시에 지원하는 국제화된 프로그램도 있다.
지역화 범주에 들어가는 것들은 앞서 이야기한 한글 패치의 여러 가지 방법 중 하나를 적용 한 것이라 볼 수 있다. 아래에 속하는 어플리케이션은 적어도 8-bit clean하도록 하는 것 이상으로, 비교적 한글을 잘 배려하는 어플리케이션들이다.
앞으로는 입출력 기능을 중심으로 이들 어플리케이션 중 중요하다고 생각되는 것에 대해서 자세히 살펴보도록 하겠다. 이 글에서 나온 대부분의 기술적 배경에 대한 설명은 Hangul and Internet FAQ에 있다.
$Id: index.shtml,v 1.1.1.1 2001/05/23 03:11:35 cjh Exp $
[ Home | Freetime works | FreeBSD | KFUG ]