내 맘대로 보는 세상 » johab http://b.mytears.org 평범한 일상 속의 보석찾기.. Sat, 19 Jun 2010 11:27:24 +0000 http://wordpress.org/?v=2.9.1 en hourly 1 컴퓨터 속의 한글 http://b.mytears.org/2005/01/101 http://b.mytears.org/2005/01/101#comments Mon, 24 Jan 2005 22:28:29 +0000 정태영 http://b.mytears.org/?p=101 컴퓨터 속에서 맨날 한글을 봐오고 있으면서도 막상 한글 코드에 대해서 관심 있어 하는 프로그래머는 그리 많지 않은 듯 싶다. 그리고 관심을 가진다고 해도 잘 정리된 문서가 없는 듯 싶어서 내가 아는 내용을 살짝 정리해 봅니다.

우선 한글은 조합형, 완성형, 확장 완성형, iso2022-kr, unicode 등으로 표현이 가능하며… 조합형, 완성형, 확장 완성형, iso2022-kr 등은 symbol table 과 한자 ...

Read the rest of this entry...

Related Posts

]]> 컴퓨터 속에서 맨날 한글을 봐오고 있으면서도 막상 한글 코드에 대해서 관심 있어 하는 프로그래머는 그리 많지 않은 듯 싶다. 그리고 관심을 가진다고 해도 잘 정리된 문서가 없는 듯 싶어서 내가 아는 내용을 살짝 정리해 봅니다.

우선 한글은 조합형, 완성형, 확장 완성형, 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바이트를 사용하며 첫번째 바이트는 0×81~FE 사이 두번째 바이트는 0×41~5A, 0×61~7A, 0×81~FE 영역을 차지한다.

  4. iso2022-kr

    EucKR 을 7bit 만 사용하며 표현하는 방식으로 RFC1557 에 정의되어 있다. Designator Sequence (0×1B 24 29 43), SO (0×0E), SI (0×0F) 등을 이용해 EucKR 을 7bit 로 변환시킨다.

    Designator sequence 는 non ASC character 를 만나기 전에 아무 때나 한 번만 나와주면 되며, non asc character 를 만나면 SO 를 출력 후 다시 asc character 를 만날 때까지 0×7F 와 AND 연산을 해서 출력한다. (MSB 를 reset) 그러다가 asc character 를 만나게 되면 SI 를 찍고 나서 다음 글자들을 프린트하면 된다. 이런 과정을 반복하면 EucKR 은 iso2022-KR 로 변환된다.

    그 과정을 pseudo code 로 표현하자면 (위에 설명이 좀 복잡하게 보이는데 실제로 보면 간단하다.)
    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% 호환된다. 0×00 이 사용되지 않으므로 전통적으로 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 을 의무적으로 삽입할 필요는 없다.)

Encoding UTF-8 UTF-16BE UTF-16LE UTF-32BE UTF-32LE
‘가’ EA B0 80 AC 00 00 AC 00 00 AC 00 00 AC 00 00
Smallest code point 0000 0000 0000 0000 0000
Largest code point 10FFFF 10FFFF 10FFFF 10FFFF 10FFFF
Code unit size 8 bits 16 bits 16 bits 32 bits 32 bits
Byte order N/A big-endian little-endian big-endian little-endian
Byte order mark EF BB BF FE FF FF FE 00 00 FE FF FF FE 00 00
Minimal bytes 1 2 2 4 4
Maximal bytes 4 4 4 4 4

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

  1. 0×00~0×7F 까지는 그냥 표시한다.
  2. 0×80~07FF 까지는 B110xxxxx 10xxxxxx (2바이트)
  3. 0×0800-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:

Related Posts

]]> http://b.mytears.org/2005/01/101/feed 22