Tag: johab

컴퓨터 속에서 맨날 한글을 봐오고 있으면서도 막상 한글 코드에 대해서 관심 있어 하는 프로그래머는 그리 많지 않은 듯 싶다. 그리고 관심을 가진다고 해도 잘 정리된 문서가 없는 듯 싶어서 내가 아는 내용을 살짝 정리해 봅니다.
우선 한글은 조합형, 완성형, 확장 완성형, iso2022-kr, unicode 등으로 표현이 가능하며… 조합형, 완성형, 확장 완성형, iso2022-kr 등은 symbol table 과 한자 테이블 또한 가지고 있지만 여기서 관련된 내용은 거의 얘기하지 않을 겁니다.

1. 조합형 (Johab)

   ASC II 범위에 있는 글자는 그대로 프린트하고 한글인 경우 MSB 를 1로 세팅하고 나머지 비트를 초성(5bit) / 중성(5bit) / 종성(5bit) 을 표현하는데 사용한다. 이론 상으로 한글 11172 자를 모두 표현해낼 수 있으며 한글 입력을 처리하기가 아주 쉽다. 다만 Microsoft 에서 완성형을 선택함에 따라 잊혀진 인코딩이 되어가고 있다.

2. 완성형 (EucKR)

   ksx1001 에 정의되어 있으며 역시나 ASC II 범위의 글자는 그대로 프린트 한다. 한글의 경우 연속된 두 개의 바이트를 이용해서 표현하게 되며 첫번째 바이트와 두번째 바이트 모두 0xA1~0xFE 사이의 값을 가진다.
   한글은 2350 자 밖에 지원하지 않지만 MS windows 에서 선택함에 따라 널리 사용되고 있다.

3. 확장완성형 (Unified Hangul Code)

   Microsoft 에서 EucKR 에 몇 가지 글자를 더 추가한 인코딩으로 UHC, cp949 등으로도 불린다. 빈 공간에 글자를 추가해 넣었기 때문에 바이너리 값 그대로 정렬을 시도할 경우 한글의 가나다라 순서대로 정렬되지 않는 문제가 있다.
   EucKR 과 마찬가지로 한글을 표현하는데는 2바이트를 사용하며 첫번째 바이트는 0x81~FE 사이 두번째 바이트는 0x41~5A, 0x61~7A, 0x81~FE 영역을 차지한다.

4. iso2022-kr

   EucKR 을 7bit 만 사용하며 표현하는 방식으로 RFC1557 에 정의되어 있다. Designator Sequence (0x1B 24 29 43), SO (0x0E), SI (0x0F) 등을 이용해 EucKR 을 7bit 로 변환시킨다.
   Designator sequence 는 non ASC character 를 만나기 전에 아무 때나 한 번 출력하면 된다. non asc character들을 출력할 때는 ‘SO char&0x7F char&0x7F char&0x7F SI’와 같은 식으로 SO를 먼저 하나 출력하고, msb가 제거된 non sac character 값들을 모두 출력한 뒤 SI를 출력하면 된다. 이런 과정을 반복하면 EucKR 은 iso2022-KR 로 변환된다.
   그 과정을 pseudo code 로 표현하자면 (위에 설명이 좀 복잡하게 보이는데 실제로 보면 간단하다.)

   C

   print 0x1B 0x24 0x29 0x43 // Designator Sequence stats = asc while( char = get_next_char() ){ if( stats == asc ){ if( char & 0x80 ){ print 0x0E // SO stats = non_asc } } else{ if( !(char & 0x80) ){ print 0x0F // SI stats = asc } else char &= 0x7F; } print char }

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

   print 0x1B 0x24 0x29 0x43 // Designator Sequence stats = asc while( char = get_next_char() ){     if( stats == asc ){         if( char & 0x80 ){             print 0x0E // SO             stats = non_asc         }     }     else{         if( !(char & 0x80) ){             print 0x0F // SI             stats = asc         }         else             char &= 0x7F;     }     print char }

   (위의 pseudo code 에서는 Designator Sequence 를 맨 앞에 출력을 했지만 iconv 등에서는 처음으로 non asc character 를 만났을 때 출력하고 있다.)

위의 네가지 인코딩 이 그동안 많이 쓰여왔던 인코딩 들인데 국제화 시대인 지금은 오로지 한글만을 표현할 수 있는 저런 인코딩으로는 뭔가 부족하다. 그렇기 때문에 유니코드 콘소시움에서는 여러가지 언어를 함께 표현할 수 있도록 unicode 라는 글자집합(character set)을 만들어 냈으며, 유니코드를 표현하는 5가지의 encoding 을 제공하고 있다. (ucs2, ucs4, utf-7, utf-8, utf-16)

1. ucs2

   2바이트 고정형 인코딩, unicode 와 4.0 버젼과 동일하다. Endian 관련해서 Big Endian 과 Little Endian 으로 표현이 가능하다.

2. ucs4

   4바이트 고정형 인코딩. 길이를 제외하곤 ucs2 와 거의 동일하다.

3. utf-7

   unicode 의 mail safe version. RFC1642 에 정의되어 있다. BASE64 와 비슷한 방식을 통해 unicode 를 7bit 로 표현하게 된다.

4. utf-8

   가변형 인코딩으로 1바이트영역은 Asc II 와 100% 호환된다. 0x00 이 사용되지 않으므로 전통적으로 C 언어에서 사용해온 null terminated 방식을 사용하는데 문제가 없고 2바이트 이상을 사용하는 경우 특수한 규칙을 가지고 있기 때문에 validation 이 가능하다.

5. utf-16

   ucs2 와 ucs4 를 적절하게 혼합해서 사용하는 방식으로 BMP (Basic Multilingual Plane) 에 들어있는 글자는 2 바이트로 표현하게 되고 그 외의 글자들은 4 바이트를 이용해서 표현하게 된다.

utf-7 과 utf-8 을 제외하고는 byte order 가 중요시 되기 때문에 BOM(Byte Order Mark) 를 문서 맨 앞에 삽입해야 한다. 그렇기 때문에 Unicode 로 작성된 텍스트 파일의 경우 BOM 을 이용해 어떤 인코딩을 사용하는 지지 알아내는게 가능하다. (utf-8 을 위한 BOM 도 존재하지만 utf-8 의 경우 Byte Order 가 정해져 있기 때문에 BOM 을 의무적으로 삽입할 필요는 없다.)

대강 ucs2, ucs4, utf-8, utf-16, utf-32 의 특징을 정리하면 위의 표와 같다. UTF-8 의 경우엔 ASC II 와 호환이 되기 때문에 영어권 언어들에서 별다른 조작 없이도 문제를 일으키지 않게 되므로 널리 쓰이고 있다. UTF-8 과 UCS2 사이의 변환은 아래와 간단한 규칙을 통해 이루어지게된다.

1. 0x00~0x7F 까지는 그냥 표시한다.
2. 0x80~07FF 까지는 B110xxxxx 10xxxxxx (2바이트)
3. 0x0800-FFFF 까지는 B1110xxxx 10xxxxxx 10xxxxxx (3바이트)
4. 이후는 UCS4 영역이고 위와 같은 방식으로 4바이트까지 확장됩니다.

보다시피 ASC II 는 그대로 표현하고 있습니다. 그리고 2바이트 이상을 사용하는 문자에서는 2진수 기준으로 앞에 붙어있는 1의 개수가 그 글자를 표시하는데 사용된 바이트 수를 나타내며, 2번째 바이트부터는 맨 앞에 10 을 붙여줌으로 이건 글자의 시작이 아니라는 걸 표시하게 됩니다. 위의 두 규칙을 지키면서 unicode 를 2진수로 바꾸어 xx 로 표시된 영역에 차례로 배치하게되면 ucs -> utf-8 변환은 끝이 납니다. 한글은 UTF-8 로 표현하게 될 경우 한 글자 당 3 바이트 씩을 차지하게 됩니다.
그리고 이 유니코드에서 한글이 차지하는 영역은 아래와 같습니다.

1. U+1100: 조합형 영역

   첫가끝 코드라는 이름으로도 불리고 있으며 초성(첫), 중성(가운데), 종성(끝)이 각기 다른 영역에 배치되어 있다. 이 영역에 있는 글자들을 이용하면 한글 고어까지도 표현이 가능해진다.
   한글 한 글자를 표현하는데 많은 저장공간이 필요하다는 점과, iconv 에서 첫가끝 영역 -> Euc-KR, iso2022-kr, UHC 로의 변환이 불가능한 점 등이 약간의 문제라고 생각됨.

2. U+3130: 한글 자모 영역

   ㄱ,ㄴ,ㄷ,ㄹ, … , ㅏ,ㅑ,ㅓ,ㅕ, … 등의 자음과 모음이 배치되어 있는 영역

3. U+AC00: 완성형 영역

   가각… 같이 이미 완성되어 있는 한글 케릭터가 11172 자 배치되어 있다.

Link:

• http://mytears.org/resources/doc/Hangul_Code/
• http://www.jinsuk.pe.kr/Unicode/Unicode_intro-kr.html
• http://ko.wikipedia.org/wiki/UTF-8
• http://ko.wikipedia.org/wiki/UTF-16
• http://unicode.org
• http://www.unicode.org/charts/PDF/U1100.pdf
• http://www.unicode.org/charts/PDF/U3100.pdf
• http://www.unicode.org/charts/PDF/UAC00.pdf