유니코드 역사

 유닉스 형태의 운영체제에서 한글을 사용하려면 꼭 겪어야 되는 문제이고,

 이를 다시 윈도우로 가져갔을 때.. 또 다시 겪게 되는 문제점입니다.

 이 문자 표현 방식이라는 게 내용도 상당히 많고, 파고 들어가면 많은 만큼 헷갈리게 됩니다.
 이도 그럴 것이, 나라마다 문자 표현 방식이 다른데 오죽하겠습니까?
 지금 제가 말할 것도 모두 한글, 영어 뿐.. 중국어, 일어, 유럽어 등.. 많은 언어 체계가 있겠지요.

 저도 최근 이러한 문제의 궁금증을 해결해보고자 많은 레퍼런스를 참고하였습니다.

 보면 볼 수록 헷갈리고... 정리도 안 되고...  하지만 대략 감(!?)은 잡혔으니 그 감을 이 기회에

 풀어 놓을까 합니다.

 

 그럼 재미있는 컴퓨터 문자 표현 방식 이야기를 시작해볼까요...?

 

 호랑이가 담배를 피던 시절.. 우리는 ASCII 라는 문자 집합을 사용하였습니다.

 이 ASCII 문자 집합은  가히 혁명적이라 할 수 있었지요.
 사실 ASCII 전의 문자 집합은 저도 잘 모릅니다.

 여하튼, ASCII 문자 집합은 희대의 충격이었으며, 나중에 다른 국가들의 절망이기도 하였지요.

 ASCII 문자는 Byte = Character 의 등호아래 1Byte면 알파벳, 숫자, 특수문자,
 제어기호를 표현할 수 있었습니다. 1Byte = 256 개의 문자가 표현가능하지요.
 왜? 0x00 ~ 0xFF 까지니깐 말입니다.

 헌데, 그것도 문자열의 끝을 사용하는 0x00 을 사용하면서 실제로는 255개가 되고 맙니다.

 여기서 끝이냐? 이도 반을 나눠서 128 밖에 되질 않지요. 그럼 나머지 128개는?

 그나마 머리 좋으신 분들이 나중에 ASCII로 표현 불가능한 문자가 생기지 않을까 생각해서

 예약을 해두셨습니다.  정확히 예약은 아니고 정의되지 않았지요.

 

 그리고, 몇 해가 지나 사용하지 않은 128개를 사용하고 싶어하는 사람들이
 생겨나기 시작했지요. 그럴 수 밖에 없지요. 사람이 영어만으로 살 수 없지 않나요?
 밥 말고 반찬도 먹어야지요..-_-; 그래서! 기존 ASCII 가 1Byte = B+00000000 이라면
 128(B+10000000) 이상부터 사용하기 시작한거죠.

 여기에서 바로 코드페이지(Code page)라는 게 등장하게 됩니다.

 코드 페이지란 문자 인코딩 테이블(0~255까지의 정수를 표현하는 비트들이 문자와
 맵핑 된 도표)인데 최초의 IBM 에서 나온 437 말고도 MS사에서 만든 949 도 있습니다.

 이들은 모두 CPXXX 형태로 쓰이는데 CP437, CP949 형태로 말이죠.
 이 코드 페이지란게 생기자 슬슬 문자가 발단이 되기 시작합니다.
 왜냐? 코드 페이지를 알아야 문자를 표현할 수가 있으니깐 말이죠.

 

 이쯤되면 슬슬 의문이 들기 시작 할 겁니다. 1Byte에서 ASCII 문자 128개 빼고..
 나머지 128개는? 나머지 128개로 영어 외의 문자를 표현하라고? 말이나 됩니까?
 당연히 안 됩니다. 그래서 이러한 한계를 돌파하고자 Byte를 앞에 하나 더 붙여서
 다른 문자를 표현하게 됩니다. 이를 두고서 전문적으로 DBCS(Double Bytes
 Character Set)이라 불리게 되지요.

 

 이쯤에서 똑똑한 집단이 두 곳이 들고 일어나게 됩니다. 바로 유니코드를 외치는
 유니코드 콘소시움과 ISO 였습니다. 이 두 곳에서는 말 많고 탈 많은 문자 표현 체계를
 통합하려는 움직임이 있었습니다. 근데 사공이 많으면 배가 산으로 간다고..
 이 두 곳에서 서로 다른 통합 체계를 만들어 냈으니 결국 ISO는 10646 표준이었고,
 유니코드 콘소시움에선 유니코드(Unicode)를 들고 나왔드랬죠.

 사실 이는 세계가 요구하는 바가 아니기에 이 두 곳은 서로 협력하고 공통적인 테이블을
 만들기로 합니다. 그렇다고 이 두 곳 모두 통합 된 것은 아니었고, 그들대로 표준을 내놓
 은 것이죠.(지긴 싫다는 얘기?) 따라서 이 둘은 거의 모둔 문자들이 같은 위치, 명칭을
 사용하게 됩니다. 위치와 명칭이 상당히 중요하죠.

 위치에서 따라서 테이블이 바뀌게 되니 너무나 다행인거 아닙니까?

 제 말은 결국 여기서 유니코드(Unicode)가 나오게 되었고, 사람들은 이제 2Byte면
 모든 문자를 표현할 수 있다고 믿게 됩니다. 추후 믿음은 곧 깨지게 되는데 말이죠^^?

 2Byte면 16비트 입니다. B+0000000000000000(8bit * 2) 만큼 저장 공간에 한 문자를
 표현할 수 있게 되니 결국 65536개가 아니겠습니까?
 물론 여기서 0x00(NULL)은 빼서 65535가 되고 말지만요.

 근데 왜 믿음은 깨지게 되냐구요? 바로 멋진 아키텍쳐들 덕분이지요.
 이들이 서로 또 멀티 바이트를 다룰 때, 또는 통신할 때, Endian(Byte-Order) 문제를
 발생시킨 장본인들 이니까요.

 그럼, 문자열의 Endian 방식을 명시해줘야 하는데 어라? 그럼 2Byte로 모자르지 않을까요?

 모자르지요. 당연합니다. 모든 국가의 사람들이 제 블로그에 와서 글을 적고 간다면 제가
 모두 제대로 볼 수 있을까요? 그 당시엔 아니었던 거죠. 그래서 Unicode 가 커질 필요가
 있었습니다. 좀더 새로운 것이 나오는 게 아니라 확장이라고 봐야겠지요.^^

 

 자꾸 Unicode 얘기를 하는데 이는 유니코드 컨소시엄에서 내놓은 표준이구요.
 저 위에 ISO 10646-1에도 UCS(Universal Character Set) 라는 인코딩 방식이 있었습니다.

 잠깐 이 UCS에 대해서 소개해 드리자면 이론상으론 110만개 이상의 코드가 존재합니다. +_+

 하지만 UCS-2 에서는 기본 다국어 평면(BMP(Basic, Multilingual Plane)
 또는 Plane 0)만이 사용됩니다.

 기본 다국어 평면 만으로도 한글 및 한자 등 유니코드에서 지원하는 대부분의
 문자들이 지원 가능합니다.

 문제는 우리 같은 일반 평민이 아니라 언어를 연구하는 과학자들 때문에 어떻게 보면 문제가
 발생하죠. 참고로 BMP는 2Byte 입니다. BMP 영역 외에는 보조 다국어 평면,
 상형 문자 평면 등이 있는데요. 이들은 모두 과학자들이 연구하는 특수한 형태를 위해
 나둔 것이죠. 또 다른 것이 UCS-4 가 한 문자를 표현하기 위해서 4Byte를 사용하는 것인데요.

 UCS-2 와 UCS-4 의 차이점은 한 문자를 2Byte로 표현하느냐 4Byte로 표현하느냐 입니다.

 아참.. UCS-2에서 한글은 3Byte 라는 점.. 알아두시구요.

 근데 UCS가 Unicode에 뭍혔냐구요?
 그건 아닌 듯 싶습니다. 아니죠. 뭍혔다고 봐야 하나요..-_-;;

 현재 모든 Unicode는 그 역사에 UCS가 있다는 건 아셔야 할듯 싶습니다.^^

 UCS가 정의된 ISO 10646이 나오고서도 우리나라에서도 1995년도에 KS X 1005를 
 공표했으니깐 말이죠.

 이 정도면 UCS에 대한 얘기는 그만 묻어두고요. 다시 본론으로 들어갈까요?

 

 생각을 해보세요. 가장 처음엔 1Byte 였는데 2Byte, 3, 4Byte 로 문자를 표현하니
 열 받는 건 누구? 미국이나 영국 아닐까요?
 얘네들은 처음부터 아무 불편없이 사용하고 있었는데 자꾸 딴 나라들이

 태글을 걸잖아요. 최대 4배의 저장공간이 추가적으로 필요하게 생겼는데 열 받을 만도 하죠..

 그래서 문자 혁명인 UTF-8 이 생겨나게 되었습니다. 왜 혁명이냐..!!!

 ASCII 문자를 그대로 UTF-8 에서도 1Byte로 저장할 수 있거든요~
 그러면서도 그 이상 필요한 문자코드는 첫 비트에 1을 붙이고,
 이 숫자 1의 연속성의 개수가 이 문자가 나타내는데 사용되어진

 바이트 수가 되어 모든 문자를 표현할 수 있었던 것이지요.

 자세히 얘기하면 멀티 바이트 경우 뒤의 비트가 혼동의 소지가 있기 때문에 
 뒷 바이트의 첫 비트 역시 1로 표현하였습니다.
 더 자세한 사항은 밑에 관련 레퍼런스를 보면 저 보다 훨씬 자세히 정확히 설명

 해두었기 때문에 거기로 넘기도록 하겠습니다. 이런 인코딩 방식(UTF-8)은 코드의 
 크기만 키우면 새로운 문자를 계속 만들어 낼 수도 있지 않을까요?
 현재 한 글자 최대 인코딩 크기는 6Byte 까지 있다고 합니다.

 

 근데 UTF-8 말고도 UTF-7 도 있고 UTF-16도 있습니다. UTF-7은 거의 묻혀지는
 분위기이고 UTF-16은 MS사의 정책으로 인해 사랑받고 있지요. 
 UTF-16은 BMP 영역에 속하는 문자들은 그대로 2Byte를 사용하고

 그 이상은 4Byte로 인코딩 됩니다. 이 4Byte도 내부적으로 두 개의 16Bit
 문자(High, Low)로 변환되어 한 쌍이 하나의 문자를 나타내게 되는 것이구요.

 MS사에 의해 사랑받는 다는 말은 현재 Windows 내부의 문자열 처리는 모두
 UTF-16으로 이루어져 있다는 것이죠. 저~~~ 위에 CP949는 그럼 뭐냐구요?
 CP949는 Windows 95에서 처음 사용되었는 걸로 아는데( MS에서 없는 CP949를
 만들어 낸 것입니다.) 일단 CP949년 현재 제가 사용하는 XP 기준으로도 CMD 나 메모장에서는

 기본 인코딩 방식으로 지정 돼 있구요. 이는 위에서 말한 내부처리와는 다릅니다. CMD나
 메모장은 하나의 어플리케이션이니깐 말이죠(화면에 표시되는 방식은 CP949, CE는 UCS-2
 방식이라고 하네요).

 신기한 건 뭔지 아십니까? 리눅스 같은 경우는 하나의 배포판 CD를 가지고 있으면

 로케일 설정만 바꾸면 어느 나라 언어든지 사용할 수 있잖아요.
 근데 윈도우는 해당 버전의 Windows를 새로 사야되지요. 구하든지..-_-;
 결국 언어 별로 CD를 따로 생산해내고 있다는 겁니다. 왜! 그럴까요 -_-?

 

 결론은 UTF-8이 좋다는 얘기인데.. 왜냐하면 이 UTF-8 같은 경우 ASCII 문자를 그대로
 수용하고 있거든요.

 1바이트를 쓴느 이유가 그거에서지요. 이 때문에 UTF-8 을 ASCII로 인코딩 해도
 전혀 문제는 없습니다. 단지 내부적으로 ASCII 코드 앞에 0x00 을 삽입시킴으로써
 UTF-8로 변환이 가능하죠. 결국 이를 두고 하위 호환성을 가진다고 말합니다.
 UCS-2도 그러하고 UCS-4도 그러하긴 합니다만..ㅋ

 그리고 웹 상(전 세계 사람들이 어디든 항해할 수 있는!! 바로 그곳!!)에서는 더욱이
 UTF-8로 되면 무척 좋겠지요. 그래서 요즘 웹 페이지들이 모두 UTF-8로 변환되고 있는
 추세이기도 하구요.

 

 이 정도 읽으셨다면 몇 가지 정보를 알려드리고 마치도록 하지요.

 먼저, 위에 문자 집합(Character Set)과 문자 인코딩(Character Encoding)이란 용어를
 사용하였는데 이 둘을 명확히 하지 않으면 상당히 헷갈리게 됩니다.
 제가 충일이 글에 인코딩 셋이라고 명시한 이유는 이 둘을 모두 가리켜서 하는 말이고도 하구요.

 먼저 문자 집합에 대해 말씀드리지요.
 문자 집합은  쉽게 문자에 번호를 매긴 테이블이라 할 수 있습니다.

 하나의 체계를 나타내는 것이지요. 따라서 문자 인코딩과는 구분이 되구요. 
 하나의 문자집합은 여러 개의 문자 인코딩을 가질 수가 있겠지요.  ASCII, KS X 1001,
 Unicode 가 문자 집합이 되는 것입니다.

 

 문자 인코딩은 말이지요. 이 문자 집합을 컴퓨터에 저장하거나 통신에 사용될 목적으로 
 바이트 형태로 변환을 시켜야 하는데 말이죠. 이때 문자 코드를 바이트 형태로 나타내는
 방식을 인코딩이라 합니다. 그러니, 이들은 문자 집합과는 구분이 되겠지요.
 종류도 EUC-KR, CP949, UCS, UTF 등이 있는 것이지요.

 결과적으로 UCS, UTF 모두 Unicode 이더랍니다~.

 

 방금 EUC-KR 이 나왔는데요. 이도 무시할 수 없이 자주 볼 수 있는 문자 인코딩 방법입니다.

 EUC(Extended Unix Code: 확장 유닉스 코드) 라고 해서 10월 중순에 kldp에서 cp949와 함께
 논쟁이 되었던 방식이기도 하지요.
 EUC-KR에서는 영어는 KS X 1003(옛 이름:KSC 5636,여기에 ASCII 문자에 대한 표준이
 기술되어 있음) 한글은 KS X 1001(옛 이름:KSC 5601)을 사용하는데요.
 이러면 영어는 1Byte, 한글은 2Byte를 사용해서 표현됩니다.

 근데 아이러니한게 여기서도 문제가 발생하거든요. 바로 한글의 최대의 문제점
 조합형VS완성형이란 문제이죠.

 이  EUC-KR 이란 놈이 완성형인데 완성형이다 보니 한글을 2350자 밖에 표현을 못했습니다.

 그럼 요즘 유행하는 통신문자(아햏햏,뷁) 등도 지원 못하게 되구요.
 포스코 건설의 더샾(The #)도 지원 못하게 됩니다. 완성형의 최대의 문제점이지요. 
 이러한 문제점을 가지고 있는 KS X 1001 이었지만

 결과적으로 EUC-KR 인코딩이 이 방식을 사용하고 있습죠..

 헌데, 이 EUC-KR 이란 놈을 가지고, MS 사에서 CP949 형태로 탈바꿈 했다는 것입니다.

 그래서 Windows에서 EUC-KR 란걸 들어 본적이 없을 겁니다. 당연히 MS에서 Unix가
 들어간 걸 사용할리 만무하지요. 이에 추가해서 이 CP949 란 놈이 완성형 한글이긴 한데
 자기네들이 임의로 조합형 글자를 몇개 집어넣었죠. 그 추가한게.. 대략 8천여자쯤 될겁니다.
 그리곤 이름을 확장 완성형이라고 언급하였죠.

 근데 대략 KS X 1001과 호환성을 가져야 되니깐 기존 코드는 그대로 놔두고 추가적인
 코드를 앞과 뒤에 추가시켰다는 것이지요. 한 마디로, 코드가 문자와 제대로 형식을 갖추고
 매칭이 안 됐다는 것입니다.

 그래서 그 문자 테이블을 정렬 시키게 되면 순서가 뒤죽박죽 되게 돼 버리고 말지요.

 뭐 그랬드랬습니다. 참으로 역사가 깊고 아햏햏 하지 않을 수가 없습니다.

 

 굳이  EUC-KR도 2350 자 이외의 글을 쓸 순 있다고 합니다. KS X 1001 부록3에
 나와있다고 하네요. 하지만 이를 MS가 지원하지를 않았으니 말짱 도루묵이 돼 버린 것이죠.

 제가 여기에서 말씀 드린 건 빙산의 이각 밖에 되지 않습니다.

 내부적으로 인코딩 기술 방식도 언급해야 하고, 다른 코드 논의 사항도 상당히 다양하고
 많습니다. 이들은 각 자가 필요할 때 공부하는 게 좋을 거 같군요. 
 아래에 도움이 될만한 링크 사이트를 많이 달아뒀습니다.

 저도 어차피 레퍼런스를 보고 공부한거고(제가 이걸 스스로 알 리는 없지 않습니까?)
 더 자세한 내용도 있을 것입니다. 물론 제 내용 중에 일 부분이 틀린 것일 수도 있겠지요. ^^;;

 

 유닉스/리눅스 사용자를 위한 UTF-8 및 유니코드 관련

 http://unix.co.kr/HOWTO/UTF8-Unicode-KLDP/UTF8-Unicode-KLDP.html#toc15

 위키백과, Wikipedia

 http://ko.wikipedia.org/wiki/

 문자집합, 인코딩 그리고 유니코드

 http://sparcs.kaist.ac.kr/seminar/pcpenpal-20080117-1.pdf

 많은 Gooooooooooooooooooooooooooogle 문서들

 http://google.com

 EUC-KR, UTF8 에 대한 가벼운 논쟁

 http://kldp.org/node/98856