컴퓨터에서의 한글 처리 (4) 유니코드, UTF-8, 글자수 vs 바이트수

유니코드 체계로 넘어가면서도 초기에는 다소 혼란스런 체계가 만들어졌나보다. UCS-2 라는 방식인 것 같은데 유니코드 체계의 기본개념인 코드포인트라는 것을 도입한다. 그리고 컴 시스템마다 다른 하드웨어 내부에서의 2바이트(16비트)의 처리 순서(endian? 예를 들면 X86 계열은 하위바이트 먼저, 68000 계열은 그냥 상위바이트부터 순차적으로 처리) 를 그대로 인정하겠다는 취지에 따라 문자열 선두에 BOM 이라는 것을 붙여서 유니코드임을 알리는데 이 부분이 엔디언 처리에 따라 FF FE 혹은 FE FF 순으로 나타내었다. 앞서의 포스트에서 보았던 unicode (little endian), unicode big endian 코딩에 따른 첫 두바이트가 이에 매칭한다. 이는 상당히 혼란을 가져오기 쉽다. 게다가 초기 유니코드는 코드포인트를 2바이트로 제한했었나보다. 덕분에 표현 가능한 글자수가 총 65536 (2의 16승; 2바이트) 글자로 제한된다. 한글, 한자만 합쳐도 아마도 이 글자수로는 다 커버가 안 될 것이다. 

이를 해결하기 위해 나온것이 UTF-16 방식이라 한다. 여기서는 surrogate 라는 개념이 등장했다는데 잘 이해도 되지 않고, 별로 이해하고 싶지도 않다. 어쨌거나 덕분에 전 세계 국가의 문자를 하나의 체계로 나타낼 수 있는 장점이 있는 반면, 7비트만으로도 충분한 영어권 문자도 무조건 2바이트 (한 바이트는 몽땅 0으로 세팅) 로 처리하다보니 데이터 용량이 커진다는 부담이 있었나 보다. 역시 여전히 초기 엔디언 개념을 그대로 유지한 덕에 노트패드에서 보는 바와 같이 little endian UTF-16 (옵션에서는 unicode 라고 보여준다) 와 big endian UTF-16 (unicode big endian) 이 함께 존재한다. (제대로 이해했는지는 모르겠지만 자료를 따라가다 보니 이 방식은 한 문자를 4바이트로 표기하는 것 같다. 헌데 노트패드에서 저장된 것은 2바이트 같아 보임. 잘 모르겠음 ????)

위 방식의 메모리의 낭비를 줄이고 기존 ASCII 만의 체계와도 호환을 위해 제안된 것이 오늘날 표준적으로 쓰이는 UTF-8 이라 한다. 역시 기술적인 자세한 내용은 다 이해하고 싶지는 않다. 어쨌거나 이 방식을 따르면 EUC-KR 과 CP-949 에서 존재하던 문자들이 1-3 바이트로 가변으로 표현된다는 사실... 

아~ 무진장 혼란하다. 이제는 글자 길이 바이트수로 따지는 방식의 코딩에서 벗어나야 할 시점이다. 운이 좋았는지 나빴는지 본인이 테스트한 문장 ("ABC한글") 에서는 영어는 1바이트, 한글은 3바이트 였다. 어쨌거나 한글은 2바이트라는 오해는 빨리 벗어나야...

한동안 이 문제의 혼동으로 예전 2바이트 체계에로 C 코드를 작성하고 문자열 길이를 바이트 수로 세면 왜 동일한 문자열이 Visual Basic 에서는 길이를 달리 보여주는지 매우 이상하게 여겼었다. 이제는 이해가 간다. VB 같은 경우 한글이던 영어던 실제의 글자수 (바이트 수가 아닌) 을 세는 것이라는...