표준 C lib.에 있는 API만으로는 사실 국제화 프로그램을 짜기가 쉽지 않지요. (손수 많은 일을 해야 하니까요.) 그래서, ICU도 있고, glib나 Windows, Mac OS X에서 제공하는 다른 라이브러리 에 여러 API들이 더해졌고요.

KS X 1001:1998(KS C 5601-1992)에 보조 인코딩으로 들어 있는 조합형은 지원하는 한자와 심볼이 KS X 1001:1998의 ‘기본 문자 집합’에 들어 있는 것과 같습니다. 물론, 1980년대 중후반에 쓰던 여러 가지 ‘조합형의 변형’들 가운데에는 한자와 심볼의 수가 더 적은 것도 있었을 수도 있습니다.

참, ISO 2022 체계에 부합하는 EUC-KR이 그렇지 않은 조합이나 UHC보다 더 나은 점은 하나의 옥텟으로 나타내지는 글자와 2개의 옥텟으로 나타내지는 글자가 겹치는 옥텟을 쓰지 않아서 문자열 중에 어느 옥텟을 하나 주었을 때 그로부터 글자 경계를 알아내기가 비교적 쉽습니다. 조합이나 UHC는 2번째 옥텟이 하나의 옥텟으로 나타내지는 글자와 같은 값을 지니는 경우가 있어서 좀더 복잡한 과정을 거쳐야 합니다. 이런 EUC-KR의 장점은 UTF-8의 장점 중 일부와 같습니다. 물론, UTF-8은 EUC-KR이 지니지 않은 또다른 장점도 지녔습니다. (순전히 코드 배치 관점에서만 본다고 해도)

CJKV I.P가 출판된 게 2000년 초인 것으로 기억합니다. ISO/IEC에서 ISO 10646을 개정하면서 U+10FFFF 다음에 글자를 배정하지 않기로 선언한 것은 아마 더 뒤였습니다. 그렇게 해야 Unicode와 ISO 10646이 포함하는 글자나 글자 위치에서 현재에나 미래에도 완전히 동기될 수 있으니까요. 그에 따라 UTF-8을 규정한 IETF RFC도 새롭게 나왔습니다. (UTF-8은 물론 Unicode 표준에서도 규정합니다.)

x-Windows-949/UHC/통합 완성형이 현대 한글 완성 음절 전부를 모두 다 포함한다는 사실은 CJKV I.P.에도 나왔고, 그 책이 아니라도 꽤 알려진 사실인데 어째서 착각을 하셨을까요? :-) http://ftp.unicode.org에서 MS codepage와 Unicode의 대응표를 보아도 알 수 있고요. 그 파일을 받아다가 ‘grep -v “^#’ | grep -i SYLLABLE | wc -l’ … 11172라고 나오지요 :-)

p.s) utf-8 바이트 수 관련해선 cjkv information processing 에는 6바이트 라고 적혀 있고, 인터넷에서 찾았던 다른 자료에는 또 다르게 적혀 있어서 그냥 책에 있는 내용대로 적었던 것인데, 그 책이 출판된 이후로 바뀐 것이었나보네요. :)

UTF-8은 최대 6바이트가 아니라 최대 4바이트입니다. ISO 10646에서 처음에 2^16짜리 multilingual plane을 2^15개 만들어서 2^31자를 담을 수 있도록 할 계획이었지만, Unicode와 통합 과정에서 plane 수를 17개로 줄여서 담을 수 있는 글자의 총 수가 2^20 + 2^16자로 줄었습니다. (그래서, 유니코드 코드 포인트를 나타낼 때에 “20.1 비트”가 필요하다고 합니다.) 따라서, UTF-8 역시 U+10FFFF 이후의 부분을 나타낼 필요가 없기 때문에 최대 길이가 4바이트로 줄었습니다.

EUC-KR=완성형이란 등식도 약간 어폐가 있습니다. EUC-KR이나 ISO-2022-KR은 모두 ISO 2022 체계에서 나온 KS X 1001과 US-ASCII/ISO 646:KR/KS X 1003을 묶어서 표현하기 위한 인코딩 방법입니다. EUC-KR이 널리 쓰이게 된 것은 MS DOS에서 채택한 탓도 없다고 할 수 없지만, 한국 표준 당국이 ISO 2022 체계에 부합하지 않아서 Unix에서 사용하기에 문제가 많은 조합형을 꺼린 탓도 매우 큽니다. 참, 아직 조합형을 그리워하시는 분도 계실지 모르지만, 유니코드가 널리 쓰이는 지금에 와서 과거의 조합형을 쓸 이유는 눈꼽만치도 없습니다. (단, 조합형은 KS X 1001:1998 – KS C 5601-1992-에 보조 인코딩으로 들어 있습니다.)

또, UTF-16을 UCS-2와 UCS-4를 혼합해서 쓰는 방식이라고 하는 것은 오해의 소지가 너무 많습니다. BMP의 영역 가운데 1024개씩을 high surrogate(0xD800 – 0xDBFF)와 low surrogate(0xDC00 – 0xDFFF) 영역으로 따로 할당한 후 , 이 두 영역에서 각각 뽑은 16비트 코드 유니트 2개(각각이 16bit니까 둘을 더하면 32bit=4바이트겠지요)를 조합해서(이 조합을 surrogate pair라고 합니다) BMP 영역 밖의총 2^20개의 글자(즉, U+10000에서 U+10FFFF)를 표현합니다. 각 surrogate 영역이 1024=2^10이니까 둘을 조합하면 2^20자를 표현할 수 있겠지요. UCV(Unicode Code Value)에서 UTF-16으로 변환하는 식은 다음과 같습니다.

high surrogate = (ucv – 0×10000) >> 10 + 0xD800
low surrogate = (ucv – 0×10000) & 0×03ff + 0xDC00

(위 식은 좀더 optimize할 수 있습니다. 예를 들어,
http://lxr.mozilla.org/se...ing/public/nsCharTraits.h
를 보세요.)

예를 들어, U+10400 (Desert Alphabet의 첫번째 글자)는 UTF-32BE에서는 “00 01 04 00″이지만, UTF-16BE에서는 ‘D8 01 DC 00″입니다.

유니코드 관련 용어에 대해 좀더 명확하게 알고 싶으시면 Unicode.org의 glossary를 읽어 보시기 바랍니다.

예전에 대강 써놓고… 다듬는다는게… 귀차니즘으로 인해 -_-;; 이렇게 방치되고 있군요…

하튼 제가 다시 생각해본다고 조합형이 현재 그다지 쓰이고 있지 않다는 사실이 뒤집히지는 않을거 같군요… 담 번엔 익명이 아니라 이름정도는 남겨주셨음 하는군요…

저도 알려주세요!!