컴퓨터 속에서 맨날 한글을 봐오고 있으면서도 막상 한글 코드에 대해서 관심 있어 하는 프로그래머는 그리 많지 않은 듯 싶다. 그리고 관심을 가진다고 해도 잘 정리된 문서가 없는 듯 싶어서 내가 아는 내용을 살짝 정리해 봅니다.
우선 한글은 조합형, 완성형, 확장 완성형, iso2022-kr, unicode 등으로 표현이 가능하며… 조합형, 완성형, 확장 완성형, iso2022-kr 등은 symbol table 과 한자 테이블 또한 가지고 있지만 여기서 관련된 내용은 거의 얘기하지 않을 겁니다.
-
조합형 (Johab)
ASC II 범위에 있는 글자는 그대로 프린트하고 한글인 경우 MSB 를 1로 세팅하고 나머지 비트를 초성(5bit) / 중성(5bit) / 종성(5bit) 을 표현하는데 사용한다. 이론 상으로 한글 11172 자를 모두 표현해낼 수 있으며 한글 입력을 처리하기가 아주 쉽다. 다만 Microsoft 에서 완성형을 선택함에 따라 잊혀진 인코딩이 되어가고 있다.
-
완성형 (EucKR)
ksx1001 에 정의되어 있으며 역시나 ASC II 범위의 글자는 그대로 프린트 한다. 한글의 경우 연속된 두 개의 바이트를 이용해서 표현하게 되며 첫번째 바이트와 두번째 바이트 모두 0xA1~0xFE 사이의 값을 가진다.
한글은 2350 자 밖에 지원하지 않지만 MS windows 에서 선택함에 따라 널리 사용되고 있다.
-
확장완성형 (Unified Hangul Code)
Microsoft 에서 EucKR 에 몇 가지 글자를 더 추가한 인코딩으로 UHC, cp949 등으로도 불린다. 빈 공간에 글자를 추가해 넣었기 때문에 바이너리 값 그대로 정렬을 시도할 경우 한글의 가나다라 순서대로 정렬되지 않는 문제가 있다.
EucKR 과 마찬가지로 한글을 표현하는데는 2바이트를 사용하며 첫번째 바이트는 0×81~FE 사이 두번째 바이트는 0×41~5A, 0×61~7A, 0×81~FE 영역을 차지한다.
-
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)
-
ucs2
2바이트 고정형 인코딩, unicode 와 4.0 버젼과 동일하다. Endian 관련해서 Big Endian 과 Little Endian 으로 표현이 가능하다.
-
ucs4
4바이트 고정형 인코딩. 길이를 제외하곤 ucs2 와 거의 동일하다.
-
utf-7
unicode 의 mail safe version. RFC1642 에 정의되어 있다. BASE64 와 비슷한 방식을 통해 unicode 를 7bit 로 표현하게 된다.
-
utf-8
가변형 인코딩으로 1바이트영역은 Asc II 와 100% 호환된다. 0×00 이 사용되지 않으므로 전통적으로 C 언어에서 사용해온 null terminated 방식을 사용하는데 문제가 없고 2바이트 이상을 사용하는 경우 특수한 규칙을 가지고 있기 때문에 validation 이 가능하다.
-
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 사이의 변환은 아래와 간단한 규칙을 통해 이루어지게된다.
- 0×00~0×7F 까지는 그냥 표시한다.
- 0×80~07FF 까지는 B110xxxxx 10xxxxxx (2바이트)
- 0×0800-FFFF 까지는 B1110xxxx 10xxxxxx 10xxxxxx (3바이트)
- 이후는 UCS4 영역이고 위와 같은 방식으로 4바이트까지 확장됩니다.
보다시피 ASC II 는 그대로 표현하고 있습니다. 그리고 2바이트 이상을 사용하는 문자에서는 2진수 기준으로 앞에 붙어있는 1의 개수가 그 글자를 표시하는데 사용된 바이트 수를 나타내며, 2번째 바이트부터는 맨 앞에 10 을 붙여줌으로 이건 글자의 시작이 아니라는 걸 표시하게 됩니다. 위의 두 규칙을 지키면서 unicode 를 2진수로 바꾸어 xx 로 표시된 영역에 차례로 배치하게되면 ucs -> utf-8 변환은 끝이 납니다. 한글은 UTF-8 로 표현하게 될 경우 한 글자 당 3 바이트 씩을 차지하게 됩니다.
그리고 이 유니코드에서 한글이 차지하는 영역은 아래와 같습니다.
-
U+1100: 조합형 영역
첫가끝 코드라는 이름으로도 불리고 있으며 초성(첫), 중성(가운데), 종성(끝)이 각기 다른 영역에 배치되어 있다. 이 영역에 있는 글자들을 이용하면 한글 고어까지도 표현이 가능해진다.
한글 한 글자를 표현하는데 많은 저장공간이 필요하다는 점과, iconv 에서 첫가끝 영역 -> Euc-KR, iso2022-kr, UHC 로의 변환이 불가능한 점 등이 약간의 문제라고 생각됨.
-
U+3130: 한글 자모 영역
ㄱ,ㄴ,ㄷ,ㄹ, … , ㅏ,ㅑ,ㅓ,ㅕ, … 등의 자음과 모음이 배치되어 있는 영역
-
U+AC00: 완성형 영역
가각… 같이 이미 완성되어 있는 한글 케릭터가 11172 자 배치되어 있다.
Link: