본문 바로가기

폰트

유니코드, 지구의 모든 언어를 하나의 체계 속에 담으려는 현재 진행형 프로젝트

사용자 삽입 이미지

유니코드를 만들기 시작한 것은 90년대 초반이지만 유니코드가 본격적으로 쓰이기 시작한 것은 얼마 되지 않습니다. (물론 유니코드 표준은 아직도 현재 진행형입니다.) 각자 자신의 코드페이지로 자국의 언어와 영어를 사용하는 데 문제가 없었던 시절과는 달리 전 지구적 네트워크 Internet의 보급이 보편화 되었기 때문이죠.
예전 글에서 한국어는 CP949를 쓴다는 이야기를 기억하실 것 입니다. 여기에서 CP는 Code Page의 약자로 각국의 언어에서 첫 128비트를 제외한 남는 영역에 자신의 국가에서 사용하는 언어를 적절하게 배치 해 언어를 지원하는 방식이었는데 대부분의 코드페이지는 단 한 나라의 언어만을 지원합니다.

만일 여러분이 웹에서 서비스를 운영한다고 할 때 한국어를 사용하는 사용자만을 대상으로 한다고 할 때는 CP949만을 지원해도 아무런 문제가 없지만 중국어나 일본어 러시아어를 사용하는 사용자는 글을 쓸 수 없거나 글은 쓴다 해도 페이지에 정상적으로 출력이 되지 않는 문제가 발생합니다.

지구상의 모든(혹은 전 우주라 할지라도) 언어를 하나의 포맷으로 통합하기 위한 표준. 이것이 바로 유니코드 입니다.

유니코드는 2바이트 문자일까?
심지어는 프로그래머중에서도 이런 잘못된 지식을 가지고 있는 이들을 심심치 않게 만납니다. 정답부터 말씀드리면 '아니오'입니다. 일단 단순히 생각해봐도 65,536개의 조합으로 전세계의 모든 언어를 담을 수는 없겠지요.
(한자만 4만여개) 하지만 처음엔 유니코드 연합에서도 이런 생각을 했나봅니다.그래서 유니코드는 16비트의 공간에 모든 문자를 집어넣으려고 합니다. 이 16비트 영역을 기본 다국어 평면 (BMP: Basic Multilingual Plane)이라고 부릅니다.

하지만 Unicode 3.0까지 진행되자 16비트에 전 세계의 모든 언어를 담는 것이 불가능하다는 것을 깨닫습니다. 유니코드 연합은 기본 다국어 평면에 2048글자를 대행코드라는 이름으로 따로 할당합니다. 이 것을 기본으로 보충 언어평면을 사용할 수 있게 합니다. 그리하여 유니코드는 기본 다국어 평면 1개와 보조 다국어 평면, 보조 상형문자 평면, 3차 상형문자 평면(현재 할당된 언어 없음),보조 특수 목적 평면을 가지는 구조로 성장합니다.

CP949에 해당하는 표준 한글은 1996년에 Unicode 2.0에서 모두 추가되었습니다. 한중일 통합한자는 가장 최근 버전인 Unicode 5.2에서 4149개가 추가되어 최종 74,386개의 한자가 등록되어 있습니다. 이 외에도 한글 고어와 한글 자모 원문자와 괄호 문자등이 포함되었습니다.

UTF-16
컴퓨터에서는 모든 것이 숫자로 저장됩니다. 여기 알파벳 A는 어떻게 표현될까요?
Ascii에서는 0x40으로, 유니코드에서는 U+0040으로 표시됩니다. 아 혹은 U+4000으로 표시되지요.
1바이트인 0x40을 2바이트로 확장하면서 두가지 표기법이 생겼습니다. 이 두가지 표기가 생기게 된 이유는 CPU의 처리방식에 관한 문제 때문인데 이 때문에 유니코드 문서에는 문서 맨앞에 특별한 코드가 붙게 됩니다.

FE FF - UTF16 Little Endian
FF FE - UTF16 Big Endian

둘 중 어느것을 사용해도 하나로만 통일하면 문제가 없을 것 같은데 쓸 데 없이 문제만 복잡해졌지요? 그래서 이 표준의 이름도 걸리버 여행기의 소인국 편에 나오는 달걀전쟁에서 유래되었습니다.

사용자 삽입 이미지

사진은 Big Endian http://www.bbc.co.uk/dna/h2g2/A592481



UTF-16은 기본 다국어 평면은 2바이트로 그 외의 다국어를 표현할 때는 4바이트로 표현하는 유니코드의 조합 원리와 가장 흡사한 포맷입니다. 그러나 영어권 국가들은 1바이트로 표현할 수 있는 데이터를 낭비한다는 측면과 기존 Ascii와 호환되지 않는다는 점(아마도 이것이 주된 이유였을 것으로 생각됩니다.)때문에 UTF-8이라는 새로운 포맷을 만들어 냅니다.

UTF-8
UTF-16의 가장 큰 문제점은 기존 Ascii로 읽을 경우 문자열 중간에 널문자(\0)이 들어있다는 점이었습니다. C계열 프로그램에서 널문자는 문자열의 종료를 의미하기 때문에 UTF-16은 기존 프로그램에서 심각한 문제를 일으켰습니다. 해서 유니코드와 기존 Ascii문자를 같이 사용할 수 있도록 UTF-8이 고안되었습니다. UTF-8은 Ascii와 호환이 되고 알파벳 표현부분에서 문자의 낭비가 없어 데이터량이 적은 장점으로 현재는 대부분의 웹페이지에서 표준으로 자리잡아 가고 있습니다.

UTF-32
유니코드의 고정길이형 이라고 볼 수 있습니다. 모든 글자를 4바이트 고정길이로 표현하기 때문에 데이터의 낭비가 심한 단점이 있으나 길이가 일정하여 문자처리가 쉬운 장점이 있습니다.(하지만 널리 사용되지는 않습니다.)

이 외에도...
SMTP메일과 같이 7비트를 사용하는 통신프로토콜을 지원하기 위한 UTF-7이나 UTF-16과 흡사한 UCS2 UTF-32와 흡사한 UCS4등등 많은 유니코드 규약들이 존재하지만 실행활에서 볼 수 없을 것이기 때문에 설명에 포함하지는 않았습니다. 만일 프로그램 개발을 한다면 UTF-16을 볼 기회가 있겠지만 앞으로 대부분의 유니코드 표준은 UTF-8로 통합되는 듯 합니다.

길고 지루한 내용 읽어주셔서 감사합니다. 다음에는 좀 더 재미있는 내용으로 찾아뵙도록 하겠습니다.

온한글 블로그 기자단 2기 강인규

ⓒ 온한글