출처 : http://jake9999.tistory.com/10
2009년 4월 27일 문영일
프로그래밍을 할 때 운영체재, 프로그래밍 언어에서 저장되는 방법, 웹페이지 통신 방법, DB에 기록되는 방법등이 서로 다른 코드페이지를 사용하게 되어 한글을 처리하는데 많은 불편함이 있습니다. 구조에 대한 복잡함은 설명하지 않을 것이며 코드 집합에 대해 자신이 없는 분들은 알아두시면 좋을 듯 하여 정리하였습니다.
1. 유니코드
1.1 유니코드 개요
- 유니코드(UCS:Unicode Character System)의 탄생 배경
두 단체가 다중 언어 문자셋을 만들려고 시도하였습니다. 국제 표준기구의 IS-10646 프로젝트와 소프트웨어 제조사들의 컨소시움으로 구성된 유니코드 프로젝트 였습니다. 다행히 1991년 두 그룹은 단일 코드 테이블을 만들기 위해 함꼐 작업했습니다. 현재도 각자 기준으로 독립적으로 공표하며 유니코드 1.1은 과거 ISO-10646-1:1993과 대응하였고, 유니코드 3.0은 현재 ISO-10646-1:2000에 대응합니다.
1.2 유니코드 집합
- ISO-10646 (UCS)
국제 기구 ISO-10646에서 진행하는 프로젝트
전세계 모든 문제 세트의 상위에 존재하는 문자셋으로 어떤 정보도 손실되지 않음을 보장합니다.
공식적으로 31비트 문자체계입니다. U+라는 접두어를 사용합니다.
a. ISO-10646-1 (BMP영역)
UCS의 16비트 영역이며 다국 언어용 영역인 BMP(Basic Multilingual Plane)입니다.
Plane 0 영역으로도 불리우며 전세계의 많이 쓰이는 문자들을 모두 모았습니다.
UCS 문자 U+0000 부터 U+007F는 US-ASCII(ISO 646 IRV) 입니다.
UCS 문자 U+0000 부터 U+00FF는 ISO 8859-1(Latin-1) 입니다.
ISO-10646-1:1993 은 유니코드 1.1과 같습니다.
ISO-10646-1:2000 은 현재 유니코드 3.0과 같습니다.
b. ISO-10646-2 (BMP외부 영역)
UCS의 21비트 영역까지는 역사적 혹은 과학적 목적으로 단지 전문가들만이 사용하는
영역이며 약 100만개를 조금 넘고 있으며 21비트 이상의 영역은 추가 예정이 없을 정도로
방대하며 아직 완성되지 않은채 계속 수년에 걸쳐 추가 진행되고 있습니다.
1.3. 유니코드 인코딩
- UCS-2
ISO-10646-1의 코드를 2바이트로 표현하며 이는 유닉스 시스템에서 심각한 문제가 있습니다.
- UCS-4
ISO-10646-1의 코드를 4바이트로 표현하며 이는 유닉스 시스템에서 심각한 문제가 있습니다.
- UTF-8
U+0000 ~ U+007F 까지의 ASCII 호환 문자는 1바이트로 처리합니다. UTF-8 인코딩을 사용하는 방법이 대세입니다.
BMP 영역의 문자는 3바이트 이내로 표현될 수 있으며, BMP 영역 외부는 6바이트까지 표현됩니다.
1바이트 문자 : 0xxxxxxx
2바이트 문자 : 110xxxxx 10xxxxxx
3바이트 문자 : 1110xxxx 10xxxxxx 10xxxxxx
4바이트 문자 : 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
5바이트 문자 : 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
6바이트 문자 : 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
- UTF-16
BMP 영역은 그대로 16비트로 인코딩이 되며 그 이상은 32비트로 인코딩이 됩니다.
BMP 영역은 UCS-2와 같습니다.
- UTF-32
UCS-4와 같습니다.
- ASC-II
7비트로 문자를 표현합니다.
- ISO-8859
8비트로 문자를 표현합니다. 라틴문자열등 지원
2. KS 문자
2.1. KS 문자 개요
KS 문자코드는 KS X 1001이 유니코드를 제외하고는 현존 유일합니다.
2.2 한국 문자(KS X 1001) 집합
- KS X 1001 (KS C 5601)
현재 한국 산업규격으로 옛 이름은 KS C 5601이며 2004년에 마지막 개정되었습니다.
2바이트를 사용하여 x2121 ~ x7efe까지 8836 문자의 표현을 규정합니다.
KS X 1001에 모든 현대 한글을 표현할 수 있는 방법이 존재하는데도 대부분의 프로그램들이
구현하지 않고 있으며, 구현한다 하여도 코드 순서대로 정렬했을 때 한글이 제대로 정렬되지
않고 처리도 쉽지 않기 때문에 거의 사용되지 않습니다. 따라서 KS X 1001은 사실상 2350자의
한글만 지원하기 때문에 모든 현대 한글을 제대로 표현할 수 없고 또한 2350자 바깥의 한글을
처리하는 방법이 프로그램마다 여러 가지로 나뉘면서 서로 다른 프로그램 사이에서 인코딩의
호환성이 보장되지 않는 문제가 생기기도 합니다.
2.3 KS 문자 인코딩
- EUC-KR(완성형)
KS X 1001의 한글 채움 문자를 사용하여 규격의 문자 집합에 포함되지 않은 한글을 표현하는
확장방법이 있지만 대부분의 경우 이 방법은 EUC-KR에서 사용되지 않고 대신 CP949와 같은
다른 방법을 사용하여 KS X 1001 바깥의 현대 한글을 표현합니다.
- CP949(MS윈도우)
마이크로소프트 한글 윈도우에서 사용되는 코드페이지입니다. 본래는 KS C 5601의 완성형
한글을 표현한 코드페이지였으나, 윈도 95부터는 확장 완성형 혹은 통합형 한글 코드
(Unified Hangul Code)라는 명칭으로 확장되어 모든 현대 한글을 수용하게 되었습니다.
마이크로소프트에서는 이 인코딩을 기반 문자 집합 이름인 "ks_c_5601-1987"로 사용하고 있다.
CP949 인코딩은 EUC-KR의 확장이며, 하위 호환성이 있고 한글 글자 마디 8,822자를 추가하였습니다.
- ISO-2022-KR
과거 인터넷 메일에서 쓰던 문자 인코딩.
이상으로 유니코드 및 KS 코드에 대해 살펴 보았습니다. 각 개발 시스템(Language, WAS, WEB, DB)에서 한글 사용에 대해 여러 가지 형태로 깨지는 현상들이 발생하고 멀티플랫폼 및 복잡한 환경에서의 개발자들은 이에 대한 해결을 위해 노력하고 있지만 많은 분들이 쉬운일이 아님을 절감하였을 겁니다. 각자의 시스템 및 개발 환경이 모두 다르므로 인코딩에 대하여 기초를 튼튼하게 한 후, 문제에 대한 해결을 찾는 다면 더욱 빠르게 해결해 나갈 수 있습니다. 차후에 이에 대한 글을 한 번 더 쓰고자 합니다.
오타 : 2009년 4월 30일 - UTF-8 항목에 오타가 있어서 교정하였습니다.
- 끝 -
'Linux > Android' 카테고리의 다른 글
ADB를 바로 연결할수 있는 putty (1) | 2011.01.22 |
---|---|
안드로이드 - 트레이스뷰 프로파일링 (Traceview Profiling) (1) | 2011.01.17 |
logcat 사용법 정리 && 로그 보면서 파일로 저장하기 & (0) | 2010.11.07 |
libmpfr.so.1 컴파일 에러 없애기 (0) | 2010.09.30 |
KSC5601 <-> UNICODE 변환 코드 (테이블 이용) (0) | 2009.06.11 |