UTF-8 (UCS Transformation Format)

[펌] - http://eminency.egloos.com/2966956

---------------------------------------------------------------------------------

UTF-8 (UCS Transformation Format)

오늘의 포스팅은 그 유명한, 그러면서도 사실 그 실체는 모르는 사람이 대부분인 UTF-8에 대한 것입니다.
언제나 그렇지만 뭐 저라고 잘 알면서 쓰겠습니까 -_-;;; 저같은 경우는 지난 회사에서 GSM폰 관련 작업을 하다보니 어렴풋이 감을 잡게 되었고 '조엘 온 소프트웨어'를 보면서 그나마 원리 정도는 이해하게 되었습니다만...
실제로 관련 코딩을 해봤다고 말하기는 좀 그렇군요. 하지만 차후에는 하게 될 겁니다. 현재 회사의 DB 제품이 Character Encoding을 지원 안하기 때문입니다...-_-
(관심 있으신 분은, 그리고 개발 관련 업종이시라면 '조엘 온 소프트웨어'를 꼭 읽어보시기 바랍니다)

아마 UTF-8을 들어는 봤는데 뭔지 모르는 사람들의 대부분은 인터넷 익스플로러의 'URL을 항상 UTF-8을 보냄' 옵션때문에 알게 되었을 가능성이 많습니다.
지식인에 찾아봤더니 아래와 같은 답변이 있더군요.

UTF-8은 UCS Transformation Format의 약자입니다..

UCS 는 유니코드이구요..

따라서 유니코드로 인코딩하는 방식입니다..

예로 '가'라는 글자는 UTF-8로 인코딩되면 16진수 EAB080으로 바뀝니다.

URL을 UTF-8 형식으로 변환하는 것을 의미합니다..

저 옵션이 켜진 상태에서 웹상에 한글이나 특수문자가 끼어 있으면 이를 UTF-8로 변환했을 때 인식하지 못하게 됩니다.

따라서 우리나라는 한글을 많이 쓰니 저 옵션을 꺼놓는게 좋습니다.

그야말로 최홍만 발레하고 언더테이커 회전목마 타는 소리라 할 수 있습니다, 네...-_-
일반의 인식이 저렇기 때문에 발전이 없다고 봐야 할 지...

아주 옛날... 컴퓨터 켤 줄만 알아도 '신기한 놈' 취급을 받던 8비트 시절에는 당연히도 한글에 대한 지원이 거의 전무했습니다. 컴퓨터 따라 따로 노는게 현실이었지요.
컴퓨터를 만든 미국 분들께서는 지네 나라 일도 바쁜데 한글까지 챙겨주실 여유도 없었고... 그러다 보니 7비트로 영어와 특수문자가 표현 가능한 ASCII 코드를 제정하고 나몰라라 했습니다.

하지만 컴퓨터의 기본적인 기록 단위는 바이트이기 때문에 1바이트 중 ASCII를 제외한 나머지 128개의 공간은 비어있었던 거지요, ASCII를 만든 사람들이 비영어권 사람들을 생각해서 비워놓았는지는 몰라도 이 공간을 활용해 한글을 표현하기로 우리 나라 사람들은 생각했던 것입니다. 문제는 전세계 사람들이 다 똑같은 생각을 했던 거지만요.
즉, 한글로 만들어진 파일이 다른 나라 컴퓨터에서 열면 그 나라 글자로 나오는(그것도 문법은 안 맞는) 일이 생길 수 밖에 없었던 문제를 안고 있었던 것입니다.

게다가 논외로, 한글 표현 방식조차도 하나로 통일되지 못하는 상황이었으니 그야말로 '인코딩의 춘추전국시대'라고 해도 과언이 아니었습니다. N바이트 방식, 3바이트 방식, 7비트 2바이트 방식(맞나?) 등등이 쏟아져 나왔고... 인코딩 방식이라고 하긴 뭐하지만 나중에는 어쨌든 완성형이냐 조합형이냐를 두고 또 말이 많아졌습니다.
완성형은 국어사전에 나오는 2350자 정도만을 표현하는 방식이었고, 조합형은 초중종성을 조합해서 표현할 수 있기 때문에 한글로 가능한 모든 글자에 대한 표현이 가능했지만 완성형에 비해 메모리를 많이 차지한다는 단점이 있었습니다.

어쨌든 조합형이냐 완성형이냐를 두고 싸우던 와중에 -사실 중요한 건 한글만이 아니었음에도 말이죠- 유니코드에 신경쓸 겨를이 어디 있었겠습니까...-_-
유니코드를 만드신 분들이야 말로 참 대단한 생각을 하신 거죠, '전 세계의, 아니 미래에 나올 글자들까지도 모두 코드화 하자!' -_-;;;

그래서 유니코드는... 코드입니다(먼 소리냐..-_-).
코딩할 때의 그 코드가 아니라 글자 하나하나에 1,2,3,4,... 식으로 번호(코드)를 매기는 것이 간단하게 말하면 바로 유니코드의 개념입니다. 숫자는 끝이 없으므로 미래에 새로운 문자가 생겨도 유니코드에 새로 등록만 시키면 되는 것이죠(그러므로 유니코드는 2바이트라는 것도 사실은 잘못된 것입니다).

다시 말하면 유니코드는 개념이자 철학에 불과하며 모든 글자를 포함하는 글자들의 코드 집합니다.
저 위에 지식인 답변에 '웹상에 한글이나 특수문자가 끼어 있으면 이를 UTF-8로 변환했을 때 인식하지 못하게 됩니다.'라고 쓴 것이 왜 틀렸는지 이제 아시겠습니까? 그 바로 위에 '예로 '가'라는 글자는 UTF-8로 인코딩되면 16진수 EAB080으로 바뀝니다.' 라고 써놓고는 저런 답변을 달다니 모순을 깨닫지 못한 모양입니다.

그럼 UTF-8은 무엇인가 하면, 유니코드는 말 그대로 코드 맵핑일 뿐 이를 그대로 소스 코드상에 구현하기에는 무리가 있습니다. ASCII 코드와의 호환성도 그렇지만 무작정 두 바이트로 표시한다 하더라도(이것이 UCS-2입니다) 메모리 낭비도 심해집니다.
그래서 나온 뛰어난 인코딩 방식이 UTF-8입니다. UTF-8은 바이트 길이가 문자에 따라 다양해 질 수 있습니다. 가장 좋은 점은 1바이트일 경우는 ASCII 코드와 동일하다는 것입니다. 덕택에 C-like 스트링에서는 문자열의 끝을 표시하기 위해 '\0'을 쓰더라도 문제가 없습니다. UCS-2 같은 경우는 무조건 두 바이트니 이것조차 '\0\0'으로 표시해야 하는 난감함이 있지요.

UTF-8에서 한 바이트로 표시될 수 있는 문자는 ASCII와 호환되므로 당연히 최상위 비트가 0이 됩니다.
두 바이트로 표현되는 문자면(유니코드 0x80~0x7FF) 첫 바이트는 110xxxxx의 형태의 비트가 됩니다.
세 바이트로 표현되는 문자면(유니코드 0x800~0xFFFF) 첫 바이트는 1110xxxx의 형태의 비트가 됩니다.
네 바이트로 표현되는 문자면(유니코드 0x80000~0x10FFFF) 첫 바이트는 11110xxx의 형태의 비트가 됩니다.
그리고 두 바이트 이상의 문자 중 첫 바이트 외의 문자는 모두 10yyyyyy 형태가 됩니다.

이 방법으로 알레프()를 UTF-8로 인코딩해 보겠습니다(알레프는 히브리어 문자의 첫 글자입니다..-_-).
알레프는 유니코드로 0x5D0, 즉 U+05D0의 코드를 가집니다. 5D0은 위의 범위에 따르면 두 바이트로 표현될 수 있습니다(110xxxxx, 10yyyyyy의 형태).
0x5D0은 이진수로 바꾸면 101 1101 0000의 11비트로 나타낼 수 있죠? 5개의 x와 6개의 y에 순서대로 써 주면 됩니다. 즉 11010111, 1010000이 UTF-8로 인코딩 된 알레프가 되는 것입니다.

사실 유니코드를 UTF-8로 표현하는 것은 실제 코딩에서는 크게 활용도가 없을 지도 모릅니다. UCS-2와 UTF-8을 같이 다루는 경우는(GSM폰을 제외하곤) 저는 사실 본 적이 없습니다.

그럼 다시 지식인으로 돌아가서... UTF-8에도 당연히 한글이 포함되는데(심지어 고어까지도요!) 그 옵션을 끄라는 이유는 과연 무엇일까요?
이유는 당연히 공인인증서에 죽어라고 MS만 좋은(좋았던) Active X를 쓰는 것 만큼이나 웹 페이지나 서버에는 죽어라고 UTF-8을 지원 안하는 이유가 있습니다.

한글은 자모나 받침 같은 경우는 영역이 좀 다르지만 일반적인 글자들은 AC00–D7AF영역에 위치합니다. UTF-8으로 코딩할 경우 위의 정의에 따라 무조건 세 바이트씩을 차지하게 됩니다(히브리어가 한글보다 앞에 있는게 억울할 수도 있겠군요...-_-). 서버들이 채택하는 일반적인 한글 인코딩 방식인 EUC-KR은 두 바이트를 차지하니 일단 공간 낭비 때문일 수도 있겠군요. 물론 EUC-KR은 다른 나라 언어와 호환이 되지 않습니다. 그리고 EUC-KR은 앞에서 말했던 완성형 한글 코드입니다. '뷁'같은 글자는 표시되지 않습니다...-_-;;;

UTF-8을 꺼야 되는 이유는 다시 말하면 어쨌든 UTF-8을 지원하지 않는 서버가 대부분이라는 얘기가 되죠. 디렉토리 명이 한글일 경우 'http://eminency.pe.kr/기타'라는 주소가 UTF-8 옵션이 켜져 있으면 'http://eminency.pe.kr/%ea%b8%b0%ed%83%80'의 형태로 가게 됩니다.
후자의 경우 UTF-8 코드로 해석하고 변환되어(지원하는 서버의 경우) 제대로 디렉토리명을 찾아주겠지만 그렇지 않은 서버라면 곤란해집니다...
그래서 저 옵션을 꺼주는 경우는 거의 한글이름으로 된 파일을 웹 브라우저로 억세스하는 경우가 많습니다.

지금까지 읽어 보셨으면(제가 설명을 잘 했다면) 이제 한글이 무조건 2바이트도 아니며, UTF-8이 대충 무엇이며 '한글이 되게 하려면 UTF-8 옵션을 끄세요'란 말이 얼마나 말도 안되는 얘긴지 아셨을 것입니다.
그리고 다시 말하면 컴퓨터의 모든 텍스트는 인코딩의 종류를 가져야 한다는 것도요. '일반 텍스트'란 말은 없습니다(조엘 온 소프트웨어에 나오는 말입니다).

그럼 소프트웨어에서 UTF-8을 지원한다는 것이 무엇을 의미하는지도 아시겠습니까? 사실 이는 소프트웨어의 국제화(internationalization, 줄여서 i18n이라고도 합니다. 사이에 글자가 18개라서...-_-)를 위해서는 중요한 요소입니다.
에러 메시지나 헬프 메시지가 UTF-8로 표시된다면 그것도 UTF-8이 지원된다고도 할 수 있겠지만... 더 중요한 것은 소프트웨어에 저장되는 데이터의 인코딩 방식이라고 할 수도 있습니다.
뛰어난 SCM 소프트웨어인 Subversion의 경우 EUC-KR 서버에서 한글 메시지로 커밋하고 UTF-8 서버에서 svn log를 해 보면 메시지가 잘 보입니다. 이런 경우라면 정말 지원이 잘 되어 있는셈이죠.

데이터베이스 같은 경우 또한 char 타입이나 text타입이라면 글자가 저장되는 타입이기 때문에 결코 인코딩을 무시해서는 안됩니다. 무시하고 살아도 한국에서 소프트웨어를 팔아먹는 데에는 큰 문제가 없을 지도 모르지만요. 하지만 우리 나라 사람들은 워낙 우리만 알고 살아서 그런지 이런 인식이 그다지 없긴 하지요. UTF-8을 쓰려고 혼자 맘먹으면 혼자만 불편해지는 경우가 많게 됩니다(윈도 말고 리눅스... 혹은 서버 운영이라든가...).

어쩌면 이런 것도 파시즘 & 국수주의가 아닐까도 생각해 봅니다.
그저 국내 기업 보호만을 일삼다보니 국산차는 외국에서보다 한국에서 비싸고 품질은 떨어지는 기현상을 낳는게 아닐까요. 윈도 비스타 때문에 다시 불거지는 Active X도 마찬가지인 거 같고요.

# by eminency | 2007-01-30 01:34 | Programming Story