유니코드(Unicode)에 대한 오해

[출처 : http://sizuha.egloos.com/2563282]

지구상에 존재하는 모든 문자를 전부 다 표현하겠다는 용감무식한 발상으로 만들어진, 궁극의 문자 코드 시스템! 뭐, 이제 유니코드를 모르는 분은 없겠죠.

그런데 유니코드에 대해서 몇가지 잘못 알고있는 경우가 종종 있더군요.

일단 가장 많이들 오해하는 부분이, 유니코드가 16 bit, 즉 2 Byte 문자라고 생각하고 있는 겁니다. 그래서 유니코드가 0 ~ 65535 까지의 코드로 모든 문자를 다 표현하고 있다고 생각하는데... 사실 현재 정의되어있는 유니코드값은 이미 65535를 초과하고 있습니다. (65535값을 넘어가는 유니코드 문자는 거의 쓰이지도 않기는 합니다만...)

이같은 오해는 한글이나 일본어, 중국어 등, 아시아권을 비롯한 비영어권 문자들이 2 Byte 문자체계를 가지고 있기 때문이기에, 당연히(?) 유니코드도 그러하겠지라고 생각하기 때문이기도 할 것이고, 유니코드의 코드와 인코딩의 개념이 다르다는 점을 알지 못하기 때문이라고도 생각됩니다.

유니코드 이전의 인코딩 방식에서는, 문자 코드를 그대로 메모리나 디스크상에 저장하기만 하면 되었습니다. 그러나 유니코드를 인코딩할 때는 이런 상식이 통하지 않습니다. 왜냐면 유니코드를 인코딩하는 방식은 여러가지가 있기 때문입니다.

예를들어, 한글의 "가"를 유니코드로 표현하면 U+AC00 입니다.
(유니코드를 표기할 때는 이처럼 16진수로 표시하며 앞에 U+라는 표시를 붙입니다) 

그럼 "가"라는 유니코드 문자를 파일로 저장해보기로 합니다. 어떻게 저장될까요?
아마도 이렇게 될거라 생각하겠죠?

   AC 00

하지만 WindowsXP에서 메모장을 열고 한번 저장해 보면, 전혀 다른 결과를 얻을 수 있습니다.

메모장에서 "가"를 쓰고,

"다른 이름으로 저장..."을 해서 인코딩 방식은 "유니코드"를 선택합니다.

저장된 파일을 UltraEdit 같은 Hex 에디터로 불러옵니다.

Windows XP에서 "가"를 유니코드로 저장하면 이렇게 나옵니다.

   FF FE 00 AC

"AC 00" 이 아니라 "00 AC"로 저장이 되는건 x86계열의 CPU가 정수를 처리할때 바이트 순서를 뒤집기 때문입니다. (문자 코드 역시, 결론적으로는 숫자로 표현되는 것이니까요) 이를 리틀 엔디언(Little Endian) 방식이라고 합니다. 반대로, 바이트 순서를 바꾸지 않고 "AC 00" 그대로 저장하는 방식을 빅 엔디언(Big Endian)이라고 합니다.

CPU에 따라서 정수를 리틀 엔디언으로 처리하는 것도 있고, 빅 엔디언으로 처리하는 것도 있습니다. 그래서 유니코드를 저장할 때도, CPU의 특성에 따라서 편한 방법으로 저장할 수 있게 했습니다. 즉, 유니코드를 저장하는 방식에서 벌써 두 가지가 생겨난 겁니다.

Windows XP에서 유니코드를 빅 엔디언 방식으로 저장해 보려면 이렇게 하면됩니다.

메모장에서, "다른 이름으로 저장..."

인코딩을 "유니코드(big endian)"으로 선택해서 저장

한글 "가"를 빅 엔디언 유니코드로 저장하면 이렇게 됩니다.

   FE FF AC 00

그런데 앞의 "FE FF"는 대관절 무엇일까요?
그러고 보니 앞의 리틀 엔디언에서는 "FF FE"가 붙어 있었죠?

이것은 바이트 순서 표시라는 겁니다. 프로그램에서 처음 2바이트를 읽어왔을 때, "FE FF"가 읽혀져야하는데 만일 "FF FE"로 읽혔다면, 바이트 순서를 바꿔서 읽어야 한다는 뜻이 됩니다.

가령 빅 엔디언으로 저장하면 바이트 순서가 바뀌지 않은채로 "FE FF"가 저장되므로 리틀 엔디언으로 읽어들이는 시스템에서는 "FF FE"로 받아들이게 된다는 거죠. 이걸 통해서 프로그램에서는 바이트 순서가 바뀌었다는 것을 알아차릴 수 있습니다. 말하자면 프로그램이 바이트 순서를 착각하지 않도록 하기 위한 일종의 배려지요.

하지만 이건 어디까지나 관습일 뿐이고, 표준사항이 아닙니다. 때문에 모든 유니코드로 인코딩된 문서에 다 저런 표시가 붙어있지는 않습니다.

하여간, 이와같이 유니코드를 2 Byte(16 bit) 단위로 저장하는 유니코드의 인코딩 방식을 UCS-2 혹은 UTF-16이라고 부릅니다. 하지면 이건 또 다시 빅 엔디언 방식과 리틀 엔디언 방식으로 나눠지게 되는 거죠.

그런데 UTF-16에는 또 한가지 문제가 있습니다.

모든 문자가 2 Byte로 인코딩되다 보니, 1 Byte 단위로 문자를 읽어대는 구식 영어문화권의 프로그램들(한마디로 ASCII 같은 것만 취급하는...)에서는 유니코드로 된 문서를 읽지 못한다는 겁니다. 비록 영어로만 쓰여진 유니코드 문서일지라도 말입니다!

그래서, 이 같은 과거 영어 문자체계와도 호환되는 기가막힌 유니코드 인코딩 방식이 생겼습니다. 우리는 이것을 UTF-8이라고 부릅니다!

UTF-8과 유니코드를 서로 다른게 아니라, 유니코드의 인코딩 방식중 하나일 뿐입니다.
UTF-8은 이름에서도 느껴지듯이 유니코드를 8 bit 단위로 끊어서 저장합니다.
(유니코드를 8 bit로 압축해서 표현한다는 의미가 아닙니다)

덕분에 영어 알파벳과 ASCII에서 사용되는 기본적인 기호 문자들은 ASCII에서 쓰이는 것과 똑같은 형태로 저장됩니다. 따라서 영문으로만 쓰여진 UTF-8 문서는 ASCII 문자를 쓰는 구식 시스템에서도 완벽하게 읽혀집니다!

대신, 한글이나 일본어, 중국어 같은 다른 언어의 문자들은 하나의 글자가 2,3개의 바이트 단위로 쪼개져서 저장되는 수모를 당하게 됩니다. 그래서 한글 "가"를 UTF-8로 저장하면...
(참고: Windows XP의 메모장은 UTF-8 인코딩도 지원됩니다)

   EA B0 80

이렇게 3개 바이트로 쪼개져서 저장됩니다.

어쨌거나, 영문만을 취급하는 시스템과도 호환성을 유지하면서, 다국어도 표현할 수 있고, 게다가 귀찮은 바이트 순서도 고려할 필요가 없는, 이렇게 멋진 인코딩 체계이기에, 웹에서 점차 UTF-8이 널리 쓰여지고 있는 것이죠.


결론

유니코드와 유니코드의 인코딩은 다른 개념이다.

웹은 점차 UTF-8로 표준화되고 있다.
웹 페이지를 만들 때, 왠만하면 EUC-KR보다는 UTF-8을 사용하라.

1 Byte가 한 문자, 혹은 2 Byte가 하나의 문자라는 생각은 버려라.


[참고 서적]

"조엘 온 소프트웨어", 조엘 스폴스키 (2005, 에이콘)

유니코드의 인코딩에 관해 좀 더 자세한 사항은 이 책을 참고해 보십시요.
이 외에도 많은 읽을 거리가 있는 책이니 한번 봐두시면 좋을 겁니다.

[출처 : http://sizuha.egloos.com/2563282]