Linux 프로그래밍할 때, qt 기반 위에서 항상 한글처리가 골치였다.
즉, euc-kr과 utf-8 인코딩 방식의 차이때문에 한글이 깨지곤 했는데,
오늘 1.0 클래식 업그레이드 하면서 다시금 언급된 euc-kr과 utf-8.
그 인코딩 방식의 차이를 알아보고자 자료를 구해봤다.
EUC는 Extended Unix Code의 약자이고, 이 말이 AT&T Bell Lab.1에서 유닉스와 관련해서 유래한 것이고, 한국어 유닉스 환경을 규정한 KS X 2901에서 다루고 있기는 하지만, 그 인코딩 방법은 철저하게 ISO 2022 표준을 좇은 것으로 특정 플랫폼에 얽매이는 것이 아닙니다.
이른바 '완성형'이라고 불리우는 것이 바로 EUC-KR로 Unix, Mac OS, Windows, MS-DOS에서 공히 사용합니다.
EUC-KR에서는 [0x00, 0x1f]와 [0x80, 0x9f]의 두 제어 문자 영역을 보전하면서 GL (Graphic Left : [0x20, 0x7e])과 GR (Graphic Right: [0xa0,0xfe])에 두 개의 부호화된 문자 집합(coded character set)인 ISO 646:IRV (US-ASCII) / ISO 646:KR (KS X 1003)과 KS X 1001:1998을 각각 매핑한 것입니다.3 ISO 646:IRV 4와 KS X 1003의 차이는 0x5c (GL에 invoke한 경우의 코드값)에 가는 글자가 역슬래시이냐 원화 기호이냐에 있습니다.
KS X 1001과 ISO 646 두 부호화된 문자 집합을 인코딩하는 다른 방법에는 ISO-2022-KR (메일 인코딩으로 1990년대 말까지 쓰였던), X11 Compound Text Encoding, Emacs-Mule의 인코딩 등이 있습니다. 이 모두는 한때 그 역할을 훌륭히 수행했지만, CP949, 조합 등과 함께 하루속히 폐기하고 유니코드 기반인 UTF-8, UTF-16 등으로 전환해야 합니다. 그 중요한 이유 중 하나는 오직 유니코드 / ISO 10646만이 한국어를 온전하게 표현할 수 있는 방법을 제공하기 때문입니다.
오늘날 유니코드를 파일에 저장하는 방식은 UTF-8이 가장 일반적이다. UTF-8은 MBCS(ISO-2022)와 비슷하지만 더욱 정교한 방법으로 31비트의 유니코드를 1~6개의 바이트에 나누어 저장하는 방식이다. 첫번째 바이트를 읽는 것 만으로 몇 개의 바이트로 구성된 것인지 알 수 있기 때문에 상당히 정교하다. 그리고 하위 16비트만 표현할 때는 최대 3바이트로 충분하다. UTF-8에서 상위 아스키 코드 영역은 1바이트로 표현될 수 있고 한글은 대개 3바이트를 차지한다.
마이크로소프트는 텍스트 파일의 맨 앞에 UCS-2/4 및 endian을 표시하는 BOM(Byte-Order Mark)라는 특정한 코드를 넣어서 구분하자고 주장하였으나 Unix와 같은 운영체제에는 잘 맞지 않는 방식이었다. Windows NT 4.0 이후로 MS는 UCS-2 형식의 파일을 기본적으로 사용할 수 있었으나 그리 많이 이용되지는 않았고, 최근에 UTF-8이 널리 사용되면서 MS도 UTF-8을 기본적으로 지원하고 있다.
UTF-8은 바이트 단위로 읽혀질 수 있기 때문에 기존의 ISO-2022을 기준으로 작성된 응용프로그램들과 호환성이 높다. 예컨데 UCS-2 문자열은 unsigned short 배열에 저장되어야 하지만, UTF-8 문자열은 기존의 응용프로그램 처럼 char 배열에 저장될 수 있다.
