Diff for "EUC-KR, 문자셋, 인코딩, MIME, ..."

EUC-KR, 문자셋, 인코딩, MIME, ...

August 25, 2004

하나. MIME 문자셋 이름 한동안 메일이나 HTML의 MIME content-type에 사용되는 charset 이름을 두고 논쟁이 있었습니다. 관례적으로 MIME에 통용되던 EUC-KR을 사용하지 않고, 마이크로소프트 사가 ks_c_5601-1987을 한글 frontpage와 Outlook Express에서 기본 문자셋으로 사용하면서부터였습니다. 그 당시에 브라우저와 메일 시장을 장악하고 있던 넷스케이프 사 제품은 한글 지원에 오류가 있기도 했구요.

어쨌든 현재 표준화된 문자셋 목록은 다음에 있습니다. 이 문자셋은 RFC 2278에 정의된 IANA Charset Registration Procedures를 거쳐 변경될 수도 있습니다.

http://www.iana.org/assignments/character-sets

여기에 보면 MIME으로 권장되는 한글 문자셋은 EUC-KR과 ISO-2022-KR로 되어 있습니다.

iso-2022-kr은 7비트로 한글을 인코딩하는 표준적인 방법이므로, 8비트 방식이 일반화된 현재의 메일이나 HTML 등에서는 EUC-KR이 가장 적합한 MIME 문자셋이 되는 셈입니다.

둘. 문자셋과 인코딩 혹은 코드 페이지 문자셋(character set)과 문자셋 인코딩(character set encoding)은 약간 혼란을 가져올 수 있는 용어입니다. 또 코드 페이지(code page)라는 표현도 많이 사용되고 있습니다. 이들은 모두 유사한 것을 가리킵니다. 엄밀하게 보면 UTF-8이나, UTF-16 같은 경우 문자 코드 값들은 동일하므로, 코드 페이지나 문자셋이 다르다고 말하기보다는 (변환) 인코딩이 다르다고 표현하는 것이 더 적절할 것 같습니다만, 대부분 통용되고 있습니다. EUC-KR과 ISO-2022-KR의 경우도 인코딩이 다르다고 표현하는 것이 좀더 의미적으로 적합한 것 같구요. 하지만, 일반적으로 문자셋이라고 표현할 때에는 인코딩까지 모두 포함하는 뜻으로 사용됩니다. 다음에 관련 정보를 찾아볼 수 있습니다.

http://www.i18nguy.com/unicode/codepages.html

셋. 윈도우 통합 완성형과 한글 문자셋, 그리고 UTF-8 EUC-KR의 경우 KSC5601과 유사하게 완성형 한글 문자셋을 나타내고 있으므로, 표현할 수 있는 한글 문자 갯수는 2천여 글자밖에 안됩니다. 똠방각하를 표현할 수 없다는 거죠. 그런데도 불구하고 메일이나 웹 브라우저에서 MIME에는 EUC-KR이나 ksc5601로 표현하고 똠방각하 글자를 표현할 수 있다는 것은 엄밀하게 볼 때 잘못된 것이라고 볼 수 있습니다. 사실은 마이크로소프트 윈도우 내에서 정한 통합 완성형 문자셋으로 보여주고 있는 것이니까요. 이렇게 표준이 아닌 확장 문자셋일 경우 x- 로 시작하는 문자셋을 사용해야 합니다. 최근 모질라에서는 통합 완성형 문자셋을 x-windows-949라고 표현하고 있는데, MIME의 설정 방법에 비춰보면 아주 적합한 표현이라고 할 수 있습니다.

자바의 경우 내부적인 인코딩 이름으로 MS949를 사용하고 있습니다. 물론 이것은 mime charset으로 사용하면 안되는 자바 String encoding 이름입니다. Java Mail API에서는 mime에 사용되는 charset과 자바 내부 charset을 서로 변환하는 유틸리티 클래스를 제공합니다. javax.mail.internet.MimeUtility 클래스가 그 역할을 하구요, 변환 테이블은 자바 메일 API를 포함하는 mail.jar 파일 안에 META-INF/javamail.charset.map 이라는 텍스트 파일 안에 들어가게 됩니다. 이 파일을 수정하면 mime charset -> java charset 혹은 java charset -> mime charset을 추가나 변경할 수 있습니다. (악용(?)하는 방법도 있습니다. java charset은 MS949로 하고, mime charset은 euc-kr로 하면... 통합 완성형 글자들이 깨어지는 현상을 막을 수 있지요...)

어쨌든, EUC-KR이나 KSC5601은 한글 문자셋으로는 별로 적합하지 않습니다. 우리가 사용하는 말을 제대로 표현하지 못하는 2천여자로 인터넷에서 한글 생활을 제대로 향유할 수는 없겠지요. 그렇다면 대안은 뭘까요? 사실 UTF-8일 수밖에 없긴 합니다. 통합 완성형은 기존 완성형과의 호환성을 위해 코드 체계 자체가 한글의 사전 순서도 지켜주지 않는 반쪽짜리 코드 체계입니다. 그리고 MIME에서 표현할 수 있는 charset이 아직 제대로 정해지지도 않았습니다. 하지만, UTF-8은 비효율적이기도 합니다. 한글 문자 하나를 표현하는 데 3 바이트가 사용됩니다. us-ascii 영역을 1바이트로 표현하여 호환하고자 하다보니 다른 문자 영역에서는 더 많은 바이트가 사용되기 때문이지요. 그렇다고 UTF-16을 사용하는 것은 us-ascii마저 2바이트로 표현하니 낭비가 심하긴 마찬가지겠지요.

현실은 더 문제가 심합니다. 웹 브라우저나 메일 클라이언트가 99% 윈도우 운영체제에서 실행되다 보니, 통합 완성형 코드가 대부분 메일이나 HTML 문서에 사용됩니다. 나름대로 생각을 가진 사람들은 UTF-8을 사용하기도 하지만 말입니다.

정통부나 전산원에서는 어떻게 생각하는지 궁금합니다. 그냥 유니코드(UTF8, UTF16)로 세상이 바뀔 건데 그 동안 적당히 뮝기적거리면 되리라고 생각하시는지... 그것도 하나의 대안이긴 하지요.. ㅠ_ㅠ;;

어쨌든 세상이 UTF8로 바뀌기 전에는 잘못된 MIME 문자셋과 통합 완성형 코드의 야릇한 동거가 계속될 수밖에 없습니다.

Posted by Yoon Kyung Koo at August 25, 2004 03:11 PM

Comments

GMail을 사용하는데 한글 깨지는 것 때문에 EUC-KR과 UTF-8의 차이점을 알기 위해 여기저기 둘러보다 여기까지 왔네요.
좋은 글 보고 갑니다.
그리고 출처 밝히고 제 블로그에 올려둘까 생각중인데 혹시나 맘에 안 드신다면 연락주십시오.
Posted by: 이범기 at August 28, 2004 01:36 PM