다음 이전 차례

1. 유닉스상의 한글처리

유닉스에서 한글을 처리할 수 있는 방법에는 여러가지 방법이 있습니다. 크게는 국제화(I18N, internationalization)이라는 방법과 지역화(L10N, localization)이라는 방법이 존재합니다. 국제화는 해당 소프트웨어(OS를 포함)을 여러 국가와 언어, 문화의 차이에 대응할 수 있도록 바꾸는 일이고, 지역화라는 것은 특정 국가, 지역, 언어, 문화 관습에 맞도록 프로그램을 바꾸는 일을 의미합니다. 보통 이런 문제는 크게 언어와 연관이 됩니다만, 한 국가에서 여러 언어를 사용하는 경우도 있고, 여러 나라에서 한 언어를 사용하는 경우도 있으며, 하나의 언어라도 지역적인 특성에 따라 차이가 날 수도 있으므로 반드시 그러한 것은 아닙니다.

유닉스 OS의 국제화를 실현하기 위해 여러 표준을 제정하는 기구들이 노력을 하였습니다. 이런 표준 중 하나가 로케일(locale)이라 부르는 것입니다. 유닉스 시스템의 로케일은, 사용자와 명령의 수행 환경을 제어할 수 있는 환경변수와 C라이브러리의 집합을 제공하여 프로그램의 별다른 수정 없이 여러 언어와 지역, 그리고 문화의 차이를 보완할 수 있습니다.

한글의 경우, 지역의 문제는 그리 크지 않습니다. 하지만 이를 처리하는 데에는 상당한 노력이 필요합니다. 이는 크게

등의 문제로 나누어지게 됩니다. 이 문제와 관련하여, 프로그램상의 다국어 메시지 지원도 문제가 될 수 있습니다.

1.1 한글의 전자적인 표현

한글의 전자적인 표현은, 한글을 컴퓨터 안에서 어떤 방식으로 저장하는가에 따른 문제입니다. 보통 한글은 2바이트 코드로 나타내는 것이 일반적인데, 유닉스 상에서 가장 많이 사용하는 방식은 완성형(KSC5601)코드입니다. 완성형 코드는 한글의 모든 조합 가능한 글자들을 표현할 수 없다는 단점이 있지만, 유닉스에서 사용하는 EUC(Extended Unix Charset)코드에 잘 부합합니다. 조합형의 경우 2바이트 중 두번째 코드가 일반적인 제어문자와 보통 문자의 영역과 충돌하는 관계로 유닉스에서 사용하기는 적합하지 않습니다. 보통 많이 쓰이는 인코딩 방식으로는 다음과 같은 것이 있습니다.

이 두가지 코드는 모두 완성형 코드를 나타낼 수 있다는 점에서는 동일하지만, 비트의 표현 방식이 다릅니다. EUC-KR은 우리가 보통 생각하는 MSB가 1로 세트된 완성형 코드이고, ISO-2022-KR은 일반적으로 한글 전자우편 전송에 사용하는 방식으로, MSB를 0으로 사용하지만 이 경우 기존의 영문자 영역(US-ASCII)와 겹치는 관계로 한글을 나타내는 경우에는 앞뒤로 구분할 수 있는 제어문자를 붙여주게 됩니다. 최근에는 ISO에서 제정한 유니코드에 한글의 조합 가능한 모든 글자가 포함되어 있고, Windows NT나 Java등에서 유니코드를 지원하고 있으므로, 앞으로는 한글의 모든 글자를 표현하기 위한 인코딩 방법으로 조합형보다는 유니코드가 쓰이게 될 것이라 생각합니다.

1.2 한글의 입력

한글 입력은 어느 환경에서 한글을 보아야 하는지에 따라 달라집니다. 텍스트 기반의 전용 터미널을 사용하는 경우 출력을 위해서는 터미널 자체가 한글을 입출력할 수 있는 기능이 있어야 하며, 그래픽을 사용할 수 있는 경우에는 별도로 그려 주어야 하는 기능이 있어야 합니다. 한글 입력은 보통 자판의 문제로 생각되는데, 2벌식과 3벌식이 있습니다. 이는 국제화의 경우에도 별도로 정해진 규정은 없으며, 대부분의 경우 필요한 소프트웨어에 한글을 입력할 수 있도록 입력 부분을 가로채는 방식으로 이루어집니다. 이런 방법을 사용한 것이 PC 콘솔에서는 han이라는 프로그램이며, X윈도우에서는 HanX와 X용 한글 입력기로 나타납니다.

han은 원래 일본어를 PC콘솔에서 나타나게 하기 위한 프로그램인 kon(Kanji ON console)에 한글 입력기능을 덧붙인 것입니다. kon은 기본적으로 일본어 뿐 아니라 한글 출력 기능도 가지고 있었습니다.

HanX는 X윈도우의 기반이 되는 X11라이브러리 자체를 조작하여 입출력 부분에 한글 입출력 루틴을 집어넣은 것입니다. 이를 공유 라이브러리 방식으로 활용하면 기존의 프로그램을 바이너리 상태로 그대로 한글 입출력이 되도록 바꿀 수 있습니다만(MS윈도우의 한글화 방식과 비슷한 점이 있습니다), X윈도우의 국제화를 위해 제공하는 국제화된 입출력 방식과는 관계가 없기 때문에 표준을 무시한다는 점이 있으며, 국제화된 입력 방식과 충돌의 우려가 있다는 것이 단점입니다.

X용 한글 입력기의 필요성은 오래전부터 제기되어 왔습니다. X11R5에서 제대로 된 형태로 나타난 국제화 방식은, X11R6에서 표준으로 정착되어 X11라이브러리의 한 축을 이루게 되었습니다. X11R5에서는 국제화에 대한 규정만 있었을 뿐, 구현 방법은 각자에게 맡겨두었기 때문에 크게 Xsi와 Ximp라는 두가지 방법이 존재하였습니다. 이 두가지 방법은 국제화된 입력기 - 영어권이 아닌 언어로 X11에서 입력을 하고자 하는 경우 - 에 대한 두가지 프로토콜을 제공을 하였습니다. 이 문제는 X11R6에서 하나의 국제화된 표준을 지키는 것으로 해결되었고, Ximp에 바탕을 둔(그러나 다른) XIM프로토콜이 만들어졌습니다. XIM은 X윈도우에서 다국어 입력을 위한 X서버와의 프로토콜을 지키는 클라이언트(X입력기)를 만들기 위한 기반을 제공합니다. 약 1년 전부터 '벼루'와 'KIMS', 'hanIM'등이 만들어져 한글 입력에 도움을 주고 있습니다. X에서 한글을 입력해야 하는 가장 빈번한 경우는 Netscape의 입력창입니다. 따라서 입력기의 가장 큰 문제는 Netscape에서 자유로운 한글 입력이 되어야 한다는 것인데, 아직 이 문제를 만족스럽게 해결한 입력기는 없는 것으로 보입니다.

별도로, hanterm이나 hanemacs와 같은 프로그램은 직접 프로그램 자체를 수정하여(이 경우에는 xterm와 GNU emacs) 한글 입출력 기능을 내장한 예입니다. 이는 아마도 X11에서 비교적 자유로운 글꼴의 입출력이 가능하였기 때문이라고 생각합니다. 이들은 모든 한글을 표현하기 위하여 별도로 이야기 글꼴에 바탕을 둔 조합형 글꼴을 바탕으로 두고 있습니다.


다음 이전 차례