인터넷 상에서의 한글 문제

이영득, 장일무

서울시 종로구 연건동 28

서울대학교 천연물과학연구소

E-mail : queen@yes.snu.ac.kr

URL : http://yes.snu.ac.kr/queen/

Abstract:

인터넷 상에서의 한글문제에 대한 개요와 한글문제를 일으키는 여러가지 소프트웨어 에 대하여 그 문제점들을 분석하고, 이를 해결하기 위한 방안을 모색해 본다. 특히 사용자 상호간의 통신 수단으로서의 메일에 대한 분석을 중점으로 하며, 기타 뉴스그룹에의 기사의 게시와 홈페이지 작성에 있어서의 문제점과 주의할 점에 대하여 논한다.

Keywords:

Hangul, Internet, Mail, News, WWW, EUC-KR, ISO-2022-KR, 한글, 인터넷, 메일, 뉴스

1. 들어가는 말

인터넷의 근간인 TCP/IP 프로토콜은 미국에서 시작되었으며, 따라서, 그 응용프로토콜의 하나인 메일을 전송하기 위한 SMTP(Simple Mail Transper Protocol)는 7비트의 문자만을 전송할 수 있도록 고안되었다. (ftp://ftp.krnic.net/rfc/rfc821.txt, STD 10) 따라서, 8비트의 길이를 가진 문자를 아무런 코드변환 인코딩과정없이 그대로 전송할 경우에는 최상위비트(MSB)가 잘리어 전혀 엉뚱한 영문 ASCII문자로 보여진다. 한글은 한 글자를 표현하기 위하여 2 byte의 길이가 필요하며, 따라서 연속적인 8bit로 이루어져 있다. 그러므로, 한글과 스페이스, 리턴문자를 포함한 영문이 혼재되어 있는 상태에서 SMTP를 거쳐 MSB가 사라진 한글 문장은 원래의 상태로도 복원이 불가능하다.

예) 안녕 → >H3g

10111110 11001000 10110011 11100111 → 0111110 1001000 0110011 1100111

이러한 상황은 비단 한글의 경우 뿐만 아니라, US-ASCII이외의 문자를 사용하는 모든 나라의 언어의 경우에도 해당된다. 유니코드가 정착되기 이전의 영어 이외의 언어는 동일한 8비트 영역의 코드를 가지고 있다. 또한 plain text의 US-ASCII문서의 전송만을 규정한 SMTP의 한계로 인하여, 응용프로그램으로 작성한 문서나, 스프레트 시트 문서, 기타 화상, 음성, 동화상 등의 멀티미디어 데이터 등은 연속된 8비트로 이루어진 바이너리 파일로서 이들 파일을 메일로 보내기 위해서는 7bit 텍스트로의 인코딩이 필요하다. 바이너리는 스페이스와 리턴이 첨부되어 있지 않다는 점에서 8bit 텍스트와는 구분이 된다.

SMTP의 이러한 한계를 극복하기 위하여, 본문 중의 8bit 텍스트의 전송을 허용한 ESMTP가 제안(ftp://ftp.krnic.net/rfc/rfc1651.txt)되었으며, 최근의 많은 MTA(Mail Transport Agent: SMTP를 실현한 서버차원의 소프트웨어)는 이를 지원하는 추세를 보이고 있다.

그러나 ESMTP의 경우에도 헤더는 인코딩이 되어야 하는데, 이것은 주소를 포함한 헤더 정보의 손실이 본문보다 위험하며, 또한 다국언어로 이루어진, 사람 이름 등이 혼재될 수 있는 상황이 존재하기 때문이다. 또한, 아직도 다수 존재하는 7bit MTA와, OSI, uucp, x.400, SNA등과의 인터 네트워킹을 위해서도 인코딩은 필요하다. 따라서 수신자는 적절한 인디코딩 프로그램이나, 메일 송수신 프로그램을 이용하여 한글등의 8bit문서를 주고 받아야 한다.

이와는 반대로 유즈넷에 사용되는 NNTP Host와 WWW에 사용되는 HTTP는 8bit를 자르지 않음으로, 7bit로 인코딩을 할 필요는 없다. 한글 뉴스 그룹인 han.*는 사용자 관례에 의거하여, 인코딩되지 않은 8bit 한글코드를 사용하도록 하고 있다. 다만, HTTP에 쓰이는 HTML에서는 예약어 및 특수 기호와 서유럽언어에 쓰이는 특수문자의 경우에, 영문 에디터에서도 사용할 수 있는 표의방식의 택(tag)을 사용하고 있다.

2. 인터넷 메일에서의 한글 문제

2.1 들어가기

인터넷 메일에서의 다양한 언어와, 바이너리전송표준을 제정하기 위하여 MIME (Multipurpose Internet Mail Extensions)규격이 제안되었다. 최신의 MIME 헤더 규격과 메시지 바디에 대한 규격은 RFC 2045 (ftp://ftp.krnic.net/rfc/rfc2045.txt)#FN1, 미디어 형식에 대한 규격은 RFC 2046 (ftp://ftp.krnic.net/rfc/rfc2046.txt), 헤더에 있어서의 다국언어의 인코딩규격은 RFC 2047 (ftp://ftp.krnic.net/rfc/rfc2047.txt) 에 각기 정의하고 있다. MIME 규격에서는 문자의 인코딩에 Quoted Printable(QP)과 바이너리 인코딩에 Base64를 제안하고 있다. QP는 8bit 영역에 해당하는 문자의 경우에 있어서, 그 문자의 16진 코드에 특수기호인 "="을 붙혀 표현한다. 예를 들면, M□(u umlaut)nchen은 M=FCnchen으로 인코딩되는 것과 같다. 그러나, 전체가 8bit로 이루어진, 한글의 경우에는 QP 인코딩시에 최고 3배까지 전송용량이 늘어나는 문제를 안고 있다. 또한 한글 문서의 경우, 한영 혼합문이 쓰이며, 스페이스와 리턴문자가 들어가 있는 텍스트로서 바이너리와 구분됨으로 바이너리 인코딩 방법을 쓰기도 곤란하 다.#FN2 예를 들면, 좌우 스크롤바가 없거나 자동 줄 바꿈이 지원되지 않는 MUA(Mail User Agent: 사용자가 직접 E-Mail을 송수신 하는데 사용하는 소프트웨어)를 사용할 경우를 위하여, 한 라인이 76문자가 넘어가지 못하도록 하고 있으나, Base64 등의 바이너리 인코딩 방법을 쓸 경우에, 긴 문단과 같은 글은 이러한 MUA에서 자동 줄바꿈을 하지 못하는 등의 문제가 있다. 특히 이러한 문제는 한,중,일등 2byte의 문자코드를 사용하는 경우에 문제가 되므로, 이들 나라의 언어에 적합한 인코딩방식이 제안 되었으며, 한글의 경우에 RFC 1557 (ftp://ftp.krnic.net/rfc/rfc1557.txt) 에서 제안하는 ISO-2022-KR Charset방식을 사용하고 있다. ISO-2022-* 코드 규격을 사용하는 또 다른 이유는 이렇게 함으로써, 한,중,일어를 비단 메일에서 뿐만이 아니라, 다른 워드프로세서등의 프로그램에서 분리 인식할 수 있는 장점이 있다.

그러나 불행히도 모든 Mail Agent가 ISO-2022-KR을 지원하는 것은 아니며, 지원하는 경우에도 상호 해석이 달라 사용자는 깨지거나 디코딩이 안된 메일을 받게 되었다. 이러한 문제점을 극복 하고자, 한국전산원을 주축으로, 메일프로그램 개발업체와 국내 주요 ISP들이 모여, 인터넷 한글 협회를 구성하고, RFC 1557의 모호한 점을 분명히 하여 새로운 표준안의 선정을 준비하고 있다. 본 장에서는 RFC 1557에 따른 메일표준을 분석하고, ISO-2022-KR 지원 응용프로그램의 문제점들을 분석하고, 기타, 지원되지 않는 프로그램의 경우에 환경설정과, 여러가지 인/디코딩 프로그램에 대하여, 살펴보고자 한다.

2.2 한글 메일 인코딩 규격과 지원 프로그램의 문제점

RFC 2045, 2047 및 RFC 1557에 따라 제대로 인코딩된 메일은 다음과 같은 형태를 가져야 한다.

MIME-Version: 1.0

Subject: =?EUC-KR?B?WWW-Forum의_발전을_기원합니다._이것을_계기?=

=?EUC-KR?B?로?= Internet =?EUC-KR?B?상의_한글_문제_?=

=?EUC-KR?B?해결에_도움이?= =?EUC-KR?B?_되었으면_합니다.?=

Content-Type: text/plain; charset=ISO-2022-KR

Content-Transfer-Encoding: 7bit

ESC$)C<SO>안녕하세요<SI>? <SO>이영득입니다<SI>.

Internet <SO>기술<SI> <SO>트랙의<SI> <SO>강좌를<SI> <SO>맡게되어<SI> <SO>무한한<SI>

<SO>영광입니다<SI>.

먼저 각 부분에 대하여 살펴보자. RFC 2045에 의하면, MIME-Version: 1.0 이라는 표기에 대하여, 특별한 언급이 있지 않는 이상, 이러한 표기가 이루어져야 한다. 그러나, 일부 영문 MTA의 경우나, Eudora등 일부 MUA의 경우에, Mime-Version: 1.0으로 표기하는 경우가 있다. 물론 다른 RFC들을 살펴 보면, 이 부분이 혼동되어 사용되는 경우를 종종 볼 수 있다.

그러나, MTA차원에서 한글 메일의 인/디코딩을 담당하는 한글 Sendmail의 경우, MIME이라고 모두 대문자로 표기된 경우가 헤더 표기 방식의 변환이 일어나는 조건 중의 하나이다. 물론, RFC 2045는 다른 헤더파트의 내용에 대하여는 엄격하게 적용하지 않는 융통성이 있다. 예를 들면, Base64나 bAsE64나 동일하다. 그러나, MIME-Version: 1.0에 한하여서는 한글 메일의 송수신 문제를 가져 오므로, 이 부분은 중요하며, 한글 Sendmail은 호환성을 고려하여, 수정되는 것이 바람직하다.

RFC 2047은 다국언어로 이루어진 헤더의 인코딩 규격을 설명하고 있다. 헤더의 인코딩 단위는 encoded word로 표현되는데 encoded word의 형식은 다음과 같다.

=?문자집합?인코딩방법?인코딩문자?=

여기서, 문자집합은 컴퓨터에서 부호화된 문자집합을 의미하는 것으로, 일반적으로 사용되는 문자열과는 다르다. 예를 들면, KS C 5601은 추상적인 의미의 한글 문자의 나열이며, EUC-KR은 KS C 5601을 컴퓨터로 인코딩한 문자셋을 의미한다. 즉, 우리나라의 경우, KS C 5601의 MIME Encoded Character Set으로 EUC-KR(Extended Unix Character)이 사용되고 있다. 많은 프로그램에서 사용되는 ISO-8859-*는 1부터 10까지 있으며, 다음과 같은 나라의 문자 코드를 의미한다.

8859-1 Europe, Latin America, Caribbean, Canada, Africa

8859-2 Eastern Europe

8859-3 SE Europe/miscellaneous (Esperanto, Maltese, etc.)

8859-4 Scandinavia/Baltic (mostly covered by 8859-1 also)

8859-5 Cyrillic

8859-6 Arabic

8859-7 Greek

8859-8 Hebrew

8859-9 Latin5, same as 8859-1 except for Turkish instead of Icelandic

8859-10 Latin6, for Lappish/Nordic/Eskimo languages

이들 문자는 1 byte 코드를 사용하는 나라의 언어로, 따라서 한글에서 ISO-8859-1과 같은 인코딩 문자 집합을 쓰는 경우는 잘못된 것이다.

인코딩 방법은 7bit로의 인코딩을 의미하며, B(Base64)인코딩과 Q(QP)인코딩이 쓰이며, RFC 1557은 헤더 인코딩방법으로 두 인코딩을 모두 허용한다. 문자집합표기와 인코딩방법 표기는 대소문자를 구분하지 않는다. 즉, B 또는 b가 동일한 의미를 가지고 있으며, 마찬가지로, EUC-KR이나 euc-kr이나 동일한 의미를 가지고 있다. 그러나, 한글 Sendmail은 euc-kr이면, 디코딩이 이루어 지지 않는데, 구버젼의 넷스케이프는 소문자로 표기한다.

하나의 encoded word는 75 character/line을 넘어가지 못한다. 만일 이것을 넘어갈 경우는 CRLF + linear white space를 두고, 다음 라인에 새로운 encoded word를 만들어야 한다. encoded word를 포함한 모든 헤더 라인은 76 character/line을 넘기지 않는 것이 호환성을 위하여 권장된다. 또한 encoded word는 linear white space로서 다른 encoded word와 구분이 되어야 하며, 이 linear white space는 디코딩시에 무시된다. 그러나 이웃한 일반 text와의 사이의 space는 디코딩시에 무시되지 않는다. Q인코딩의 경우에 스페이스는 =20 또는 _로 표시되어 encoded word안에 표현이 된다. encoded word는 linear white space에 의하여, 다른 text나 encoded word와 구분되어야 하지만, ctext라고 불리우는 "(" 와 ")"는 예외로 하고 있다. 일반적으로 한영 혼합문의 경우에, 영문과 한글 조사가 붙어 있는 경우에는 이 영문은 encoded word안으로 들어가서 인코딩 되어야하며, 만일 영문이 한글과 붙어 있지 않다면, 스페이스와 함께 떨어져 있어도 되며, 역시 마찬가지로 스페이스와 함께 encoded word안으로 들어가도 무방하다.

사실, RFC 2047의 이러한 엄격한 규정을 지키기 어려운 것은 사실이지만, 이 부분의 이해 부족으로 프로그램마다 미묘한 표준위반을 발견할 수 있다. 우선 76 character/line의 제한을 지키지 못하는 프로그램은 한글 Sendmail, Netscape, 한메일 96등이다. E-mail 프로그램으로 많이 사용되는 Eudora의 경우는 단어마다 encoded word를 만들고, 76 character/line을 넘어가면, 다음라인에 단어들을 배치하는 것으로 볼 때, 이 규정을 지키는 듯 보이지만, 역시 긴 단어의 경우에 이 제한을 지키지 않는다. 물론, 이 제한 규정을 지킬 경우에 주의 사항은 한글 단어의 경우 2 byte가 하나의 코드를 표현하므로 한글이 중간에서 잘리지 않도록 해야 한다. MS Internet Mail은 이것을 비교적 잘 수행하지만, 한글과 같은 2byte문자를 고려하지 않은 뉴스리더 프로그램인 Forte Agent로 E-mail을 사용할 경우에는 주의가 필요하다. 물론 Forte Agent는 76character/line의 규정을 지키는 프로그램이다. 최근에 출시된 Netscape 4.0pr3는 한영 혼합문의 경우 스페이스와 영문이 연이어 나온 경우에 다음 라인에 encoded word를 만들지만, 영문 text가 나오지 않는 경우에 encoded word를 자르지 않는다.

encoded word사이의 linear white space는 디코딩시에 무시되며, encoded word는 ctext를 제외하고는 linear white space에 의하여 보호되어야 하지만, 구버전의 넷스케이프와, 한글 Sendmail은 이것을 지키지 않는다. 즉, 한영 혼합문의 경우에 한글에 한하여만 encoded word를 만들고, 영문은 스페이스로 떨어져 있던지 없던지 간에 encoded word안으로 들어가지 않는다. Netscape는 최근 버전에 있어서도 디코딩시에 linear white space가 무시되지 않는다. Agent의 경우에는 모든 linear white space를 무시함으로, 오히려 한글 Sendmail과 호환성이 떨어지게 된다. MS Internet Mail은 CRLF + Linear White Space만을 무시하며, 일반 encoded word사이는 무시하지 않는다.

다음은 Content-Type 헤더 필드를 살펴 보자. 이 중에서 가장 큰 영향을 끼치는 부분은 charset 부분이다. 한글 Sendmail의 경우, 이 부분이 "EUC-KR"과 같이 " "로 묶여 있으면, MIME-Version: 1.0 표기위반과 함께 헤더 변환이 일어나지 않는 또하나의 필요조건이 되고만다. 다만," "가 없는 경우에 대소문자는 상관이 없다. 무엇보다도, MS Exchange나 MS Internet Mail의 경우에는 " "나 대소문자에는 상관이 없으나, 이 부분의 헤더가 잘못 기재 되어 있는 경우에 디코딩이 이루어 지지 않으며, 후술하는 Font Association문제의 영향을 받지 않음으로, 이 부분의 표기에 몹시 민감하다. 즉, ISO-2022-KR 디코딩을 지원하지만, ISO-2022-KR이라고 표기되어 있지 않은 경우에 디코딩이 일어나지 않는다. 한글 Sendmail을 거쳐서 온 메일은 위의 두가지 조건이 위배되는 경우에, 헤더 표기가 잘못될 수도 있다. 그러나 MS사의 메일 프로그램은 잘못된 헤더 표기에 준하여, 본문을 보여줌으로서 한글 메일의 교환에 사용자 불편함을 끼치고 있다. 특히 MS Internet Mail의 경우, ISO-8859-1로 표기가 되어 있으면, 라틴문자로 한글을 보여줌에 따라 사용자는 다시 한번 메뉴의 한국어를 선택하던지, Asian Viewer(http://www.twinbridge.com/)와 같은 외부 Font Association Utility를 이용하여 한글을 보아야 한다. 이 문제는 메일 보다는 뉴스그룹에서 문제가 크다.

ISO-2022-KR은 ISO 2022 양식에 의거하여, RFC 1557에서 규정하고 있는 KS C 5601 한글 또는 8bit EUC-KR 인코딩 문자셋의 7bit 인코딩 문자셋이다. 따라서 Content-Transfer-Encoding 헤더 파트는 7bit로 표기되어야 하며, EUC-KR일 경우에는 8bit로 표기되어야 한다. 따라서 MS Internet Mail에서 ISO-2022-KR을 8bit로 표기하는 것은 잘못이나, 이 부분이 메일 호환에 큰 영향을 끼치지 않는다. 그러나, Content-Transfer-Encoding 헤더 파트가 none으로 되어 있으면, MS Internet Mail의 경우 메시지가 아예 보이지 않는 민감성을 가지고 있다. RFC 2045에는 none이라고 쓰여진 규정자체가 없으나, 최근 메일-뉴스간의 게이트웨이 서버 중 하나인 포항공대의 서버가 QP, Base64 메일을 디코딩하면서, 이 부분을 none으로 한 경우가 있었다. 물론 서버 관리자와 연락을 통하여, 수정을 요청하였으며, 따라서 none으로 기재되는 경우가 없어질 것이지만, 메일 프로그램 개발자는 주의해야 할 것이다.

이제 본문인 ISO-2022-KR메시지를 살펴보자. 필자가 처음으로 인터넷 메일에 관심을 가지게 된 것은 한글 Sendmail과 Exchange간의 비호환성문제를 발견하고 부터였다. RFC 1557에서 규정하는 ISO-2022-KR 한글 인코딩의 원리는 한글 인코딩의 시작을 의미하는 Designator로서 ESC(0x1B)$)C를 문두에 두며, 한글이 발생하는 0x21에서 0x7E까지의 94개 문자 범위의 앞에 SO (0x0E, Shift Out)를 두고 한글이 종료되는 시점에 SI (0x0F, Shift In)를 두도록 하고있다. 즉, SO의 역할은 한글이 시작된다는 선언 부호이며, SI는 한글종료를 뜻하는 부호이다. 디코딩을 할 경우에 SO를 만나면 94개 문자의 범위에 해당하는 문자에 MSB (이진수 10000000) 즉 0x80을 더하는 연산을 수행하여 한글이 깨지지 않도록 하는 것이다. 최근 인터넷 한글 협의회의 합의에 따르면, Designartor 다음에 리턴문자가 오는 경우와 오지 않는 경우가 혼재하므로 리턴문자가 오지 않는 것으로 규정하고 있다. 또한 RFC 1557에 따르면, 문장의 시작은 항상 영문 ASCII상태이어야 한다. 스페이스나 탭과 같은 문자는 ISO 2022 코드 범위에서 지정하는 바에 따라, 한/영문 어느 것에도 속하지 않는 문자여서, SI가 오지 않을 수도 있으나, RFC 1557에서 규정하는 바에 따르면, SO, SI사이에는 94개의 문자만 올 수 있으므로, 이들 특수 문자의 경우에도 SI가 발생하여야 한다. 즉 SI의 의미는 영문시작의 의미가 아니라, 한글 종료의 의미를 내포하고 있다. 따라서 한글 Sendmail과 같이 한글 사이의 공백문자에 SI, SO가 발생하지 않는 것은 규정 위반이다. 그러나, 한글 Sendmail은 RFC 1557의 저자에 의하여 만들어 졌으며, ISO-2022- KR을 최초로 지원하였고, 이미 국내의 많은 서버에 설치되어 사용중임을 미루어, 모든 후속 인/디코딩 프로그램은 호환성을 우선으로 생각하여야 한다. 불행히도 익스체인지는 SI가 나오지 않았다고 하여, 공백문자에 0x80을 더하는 문제를 일으켰다. 당시 뉴스그룹에서 마이크로소프트 관계자의 수정 약속을 받았으나 아직 고쳐지지 않고 있다. ISO-2022-KR의 지원은 윈도우에서 화면상으로 한,중,일 언어를 지원하는 CJK-Viewer 들에서도 이루어 졌는데, Asian Viewer와 NJWIN(http://www.njstar.com/)의 경우에도 스페이스에 0x80을 더하는 문제가 있었으나, 필자를 비롯한 사용자들의 버그 리포트로 수정되었다. 익스체인지는 이외에도 SI가 명시적으로 나옴에도 스페이스에 연이은 영문에 있어서도 0x80을 더한다. 이 부분은 E-mail에서는 지원을 하지 않지만, 브라우저 차원에서 ISO-2022-KR 디코딩을 담당하는 Netscape 3.0에서도 마찬가지였다. 다행히 메일에서 디코딩을 지원하는 Netscape 4.0 pr1 이후의 프로그램은 이부분을 수정하였으며, 필자의 버그리포트가 있었음은 물론이다. 다만, 넷스케이프 4.0 pr3의 경우에 문장의 끝에 SI가 발생하지 않는 경우 리턴문자가 있는 것으로 간주 0x80을 더하는 문제를 가지고 있다. 익스체인지의 또 다른 문제는 문장의 첫 시작을 ASCII가 아닌 한글 상태로 둠에 따라 Designator다음에 리턴 캐릭터가 올 경우, 0x80을 더하는 문제를 가지고 있으며, 라인끝에 또 하나의 SI를 두는 버그가 있다. 한메일 96과 MS Internet Mail 4.70.1155는 인/디코딩에 무리가 없다. 한메일 96의 경우는 필자의 리포트로 버그 수정이 이루어졌다. 최근의 테스트 버젼인 IE 4.0에 부가 프로그램인 Outlook Express는 Designator가 문두에 나와야 하나, 영문으로 시작하는 문장의 경우 한글이 나오는 첫 단어 앞에 나오는 베타버젼의 MS Internet Mail의 문제를 재현하고 있다. 필자가 직접 사용한 적은 없으나, 마이크로소프트의 메일링 리스트로 받아 본 메일에 의하면, Exchange 서버의 경우에도 라인마다, Designator와 CRLF를 두고 있으며, 한글 사이의 공백 문자가 발생하지 않고 있다. 이미 윈도 95와 함께 배포한 Exchange Client와도 호환이 되지 않는 것이다. 이외에 최근에 개발중인 것(MCI프로젝트의 일환으로 IIS Addon E-mail서버)으로 짐작되는 Internet Mail Service의 경우에도, 한글 사이의 공백에 SI, SO가 발생하지 않는다. 모든 지원 프로그램 개발자들은 RFC 1557의 규정을 준수하여, 호환성(Interoperablility)을 떨어 뜨리지 말아야 한다.

2.3 한글 메일을 주고 받기 위한 사용자 설정

사용자가 E-Mail을 사용하는 환경은 여러가지 경우가 있다. 한글 Sendmail은 한국내 주요 Unix 서버에 설치되어 그 동안 한글 메일 송수신에 많은 공헌을 한 것은 사실이다. 그러나, 인터넷을 통하여, 외국의 한국인 사용자와 메일을 주고 받는 경우나, Windows NT 등 한글 Sendmail을 설치할 수 없는 경우#FN3에는 MUA차원의 ISO-2022-KR지원이 없다면, 한글 송수신의 문제가 발생하게 된다. 마찬가지로 QP나 Base64등 MIME을 지원받지 못하는 환경에서도 한글 송수신의 문제가 일어난다. 하지만, 인코딩되는 경우는 아무런 보장 없이 8bit로 송신 했을 경우보다 정보의 비가역적인 손실이 일어나지 않는다는 점에서, 위험한 것은 아니다. 다만 사용자 수준에서 적절한 융통성을 발휘하면, 한글의 송수신에 안전성과 편리성을 추구할 수 있다. 물론, 앞서 언급했듯이 올바른 한글 메일의 지원을 위하여, 개발자와 사용자 모두 노력해야 함은 물론이다. 본장에서는 서버 지원유무의 경우를 고려하여, 주로 Windows 95환경에서 메일을 주고 받는 방법을 기술하고자 한다.

한글 Sendmail의 현재 버젼은 8.6.12h2이다. 그러나 영문 Sendmail의 경우 보안성의 문제로 8.8.5 까지 나와 있으며, 8.7.x이후에는 메일의 경로가 안전한 경로인지의 여부를 파악한 후 본문을 Base64 또는 QP로 인코딩하는 negotiation기능이 추가 되었다. 이러한 이유로, 서버 차원에서 한글 Sendmail이 없이 ISO-2022-KR 인디코딩을 수행하도록 하는 방법으로 신정식씨의 procmail과 hmconv를 이용한 MDA(Mail Delivery Agent)차원의 디코딩 방법(http://pantheon.yale.edu/~jshin/faq/procmail.html)과 박재현씨의 가짜 한글 Sendmail을 이용한 ISO-2022-KR 인코딩 방법(http://entropy.kaist.ac.kr/~jhpark/kesmpre/README.html) 이 개발 되었다. 다만, 많은 국내 인터넷 사용자를 보유하고 있는 국내 3대 PC통신 서비스에서는 아직까지, ISO-2022-KR은 지원하나, MIME은 지원하지 않는다. 따라서 MTA에서 Sendmail 8.8.5의 negotiation기능를 믿고, ISO-2022-KR인코딩을 지원하지 않는다면, PC 통신의 인터넷 메일을 온라인 으로 사용하는 사용자의 경우에 QP/Base64인코딩된 메일을 받게 되므로, 신정식씨의 procmail법에 기술한 특정 사이트의 8bit 송신 방법을 고려하도록 하며, 하이텔, 천리안, 나우누리는 하루속히 MIME 디코딩을 지원하도록 하여야 할 것이다.

현재 윈도우용 메일프로그램으로 MIME과 더불어 ISO-2022-KR의 인디코딩을 지원하는 프로그램은 Microsoft Internet Mail(상위 테스트 버젼인 Outlook Express포함), 한메일96, Netscape 4.0 prelease 3 가 있다. 최초로 PC MUA차원에서 ISO-2022-KR을 지원한 프로그램은 MS Exchange이나 전술한 버그로 서버 차원의 지원이 없는 경우에 사용이 곤란하다. 이 이외에 한/영 윈도우상에서 화면 디코딩을 지원하는 CJK-Viewer로 AsianViewer, NJWIN, AsianSuite 97(http://www.unionway.com/)가 있으며, AsianSuite 97의 경우 한글 타이핑도 지원하므로 영문윈도우에서 외부지원을 받지 못하는 경우에 좋다. Asianviewer의 경우 선택적인 폰트 Association을 함으로, MS Internet Mail/News에 유용하며, NJWIN은 MIME헤더의 디코딩과 아울러, 디코딩시 특수문자를 삭제하며, 한글 윈도우 상에서는 Font Association을 하지 않으므로, Eudora나, Agent, Netscape 구버젼의 경우에 유용한 도구이다. 수동으로 디코딩 하는 프로그램은 이준희씨의 공개 프로그램인 cvt8.exe(ftp://cair-archive.kaist.ac.kr/pub/hangul/code), 신정식씨의 도스용 인디코더 hmconv.exe(ftp://yes.snu.ac.kr/download), 차재춘씨의 넷스케이프 메일 박스 변환 프로그램인 NShmconv.exe(ftp://knot.kaist.ac.kr/pub/Netscape-hmail-conv/) 가 있다. 매킨토시의 경우에는 김정현씨의 각종 E-Mail프로그램의 MAC Latin의 ISO-8859-1변환 패치 파일과 조절판용 필터 프로그램인 한글 메일(http://scorpion.kaist.ac.kr/)을 이용하면, 한글 메일을 주고 받는데 지장이 없다. UNIX 환경의 MUA프로그램인 Pine의 설정은 신정식씨의 Pine에 대한 홈페이지(http://pantheon.yale.edu/~jshin/faq/pine.html) 를 참조하고, 기타 Unix프로그램의 경우에도 동일 사이트의 메일관련 FAQ(http://pantheon.yale.edu/~jshin/faq/qa9.html)를 참조하기 바란다. 신정식씨의 FAQ는 각 분야에 있어서, UNIX이외에도 컴퓨터 전반에 걸친 한글 사용에 대하여, 기술하고 있다.

최근의 많은 PC용 MUA프로그램은 MIME을 지원하고 있다. 따라서, 외부적으로 ISO-2022-KR을 지원 받지 못하는 환경의 사용자에게 한글을 보내기 위하여서는 부차적으로 Base64 또는 QP 인코딩된 메일을 보냄으로서 한글 문제를 해소할 수 있다. 또한 사용자 MUA프로그램은 또한 그 사용자의 계정의 유무와 관계없이 SMTP서버를 바꿀 수 있다. 가령 경우에 따라서 가까운 한글 Sendmail 서버나, ESMTP등을 SMTP로 설정할 수가 있으므로, SMTP의 선택도 사용자에게 달려 있다고 할 수 있으나 일반 적인 경우는 아니다.

Microsoft Exchange는 전술한 버그로 독립적으로 사용하기는 곤란하나, 한글 Sendmail등의 외부지원이 있는 경우에 사용할 수 있다. 문제는 Exchange가 한글 Sendmail이 디코딩한 EUC-KR문장을 인식못하고, Text 파일의 바이너리 파일로 보여준다. 이 문제는 필자가 iso88591.trn을 변형시킨 euckr.trn(http://yes.snu.ac.kr/queen/hmailfaq.htm#6)을 이용하면, 해소되며, 또한 이 옵션을 사용할 경우에 ISO-2022-KR지원을 받지 못하는 외국에 Base64 인코딩된 한글 메일을 보낼 수 있다. MS Internet Mail의 경우는 한국어상태에서 Base64 또는 QP인코딩을 선택하면, ISO-2022-KR로 인코딩된 메일이 다시 한번 이중인코딩이 되는 경우가 발생한다. 따라서 메뉴조작만으로는 ISO-2022-KR을 지원하지 못하는 환경에, EUC-KR메일을 보낼 수 없다. 이 경우에는 다음과 같은 레지스트리 데이터 파일을 하나 만들어 MS Internet Mail의 실행 전에 실행을 하면 Default Charset을 EUC-KR로 바꿀 수 있으며, 이 상태로 8bit, Base64 또는 QP 인코딩된 메일을 보내면 된다.

REGEDIT4

[HKEY_CURRENT_USER\Software\Microsoft\Internet Mail and News\Mail]

"Default Charset"="EUC-KR"

3.0이전의 넷스케이프는 ISO-2022-KR은 지원을 못하지만, Document Encodng이 Korea인 상태에서 EUC-KR메일을 보낼 수 있으며, 옵션에서 MIME Compliant를 선택하면, B인코딩 헤더와 QP인코딩된 본문을 보낼 수 있다. 8bit EUC-KR 한글메일 조차 지원하지 않는 MUA가 많이 있다. 그 중 Eudora의 경우는 ISO-8859-1의 헤더를 가진 메일만을 보낼 수 있으며, 헤더 디코딩에 있어서도, ISO-8859-1만을 지원한다. Eudora의 경우, 외부 지원 프로그램인 한글 Sendmail과도 헤더표기 방식에서 호환성이 떨어진다. 따라서, Eudora의 경우, 한글 Sendmail과의 호환성과 8bit negotiation의 최근 버젼의 영문 Sendmail을 통하여, EUC-KR메일을 보내기 위해서는 또 다른 외부 지원 헤더변환 유틸리티를 사용해야 한다. Maillita(http://huizen.dds.nl/~maillita/)는 사용자 PC에서 작동 하는 가상 SMTP서버로서 이를 이용하여, "iso-8859-1"로 표기된 헤더를 EUC-KR로 바꾸어 전송할 수 있다. Maillita의 사용법은 http://yes.snu.ac.kr/queen/hmailfaq.htm#7에 정리하였다. 한글 Sendmail 서버를 사용하는 유도라 사용자의 경우에 추가로 변경하여야 할 헤더는 Mime-Version: 1.0을 MIME-Version: 1.0으로 바꾸고, 또한 8bit를 7bit로 바꾸어 주고, "iso-8859-1"을 EUC-KR로 바꾸기 보다는 ISO-2022-KR로 바꾸어 주는 것이 좋은데, 그 이유는 한글 Sendmail의 버그로 Multipart의 경우, text/plain part의 헤더를 변경시켜 주지 않기 때문이다.

대부분의 메일응용프로그램은 MIME을 지원하므로, QP인코딩을 이용하면, 비록 전송용량이 3배에 달하게 되지만, ISO-2022-KR 디코딩지원을 못받는 사람에게 한글 메일을 보낼 수 있다. 다만, 메시지 헤더는 EUC-KR이 되어야 함을 주의하여야 한다.

3. 인터넷 뉴스그룹과 WWW에서의 한글 문제

3.1 뉴스그룹에서의 한글 사용

뉴스그룹은 일대일의 메일과는 달리, 불특정 다수와의 대화와 토론이 이루어 지는 장이라는 점에서, 또한 전 세계의 뉴스서버가 동일한 뉴스그룹을 공유한다는 점에서, 유즈넷을 구현하는 프로그램의 특성보다는 사용자 상호간의 합의와 관례, 예절이 보다 중요한 요인으로 작용하고 있다. NNTP는 SMTP와 달리 8bit를 자르지 않는다. 따라서 뉴스그룹에의 기사의 투고는 인코딩이 필요없으며, 한글 사용자 뉴스그룹인 han.*는 관례적으로 8bit 텍스트기사를 사용하고 있다. 물론, 일본과 같은 국가의 뉴스그룹의 경우 인코딩된 텍스트의 교환을 관례로 하는 경우도 있다. 이러한 특성으로 뉴스리더 프로그램들의 경우에 MIME을 지원하는 경향이 메일프로그램들 보다 늦었으나, 최근의 대부분 뉴스 프로그램은 MIME을 지원하는 경향을 보이고 있다.

그러나, 이들 프로그램들 역시 주로 외국에서, 개발된 것으로 한글 뉴스 그룹의 관례에 맞지 않은 경우가 많다. 예를 들면, ISO-2022-KR을 지원하는 소프트웨어들은 뉴스그룹에의 포스팅을 메일과 같이 7bit ISO-2022-KR을 올리도록 하는 경우가 잦은데, 베타버젼의 MS Internet News와 보안문제로 새로이 출시된 MS IN 4.70.1161, Netscape 4.0 pr2 등이 이런 문제를 가지고 있다. 물론, MS IN 4.70.1155는 뉴스그룹에의 투고를 8bit EUC-KR로 하며, 새로 출시된 Netscape 4.0 pr3와 테스트 버젼인 MS Outlook Express는 EUC-KR기사를 올릴 수 있도록 하고 있다. 또 하나의 문제는 MS IMN의 경우, 지나치게 헤더에 민감한 특성에 의하여, Content-Type 헤더 파트가 ISO-8859-1등으로 잘못 기재된 경우, 그 국가의 언어 폰트로 보여 줌으로써, 사용자는 발음기호와 같은 문자로 가득한 메시지 화면을 보게 되었다. 물론 이것은 다국언어그룹으로 이루어진 메일과 뉴스에서 헤더 정보에 의존하여 그 국가의 언어로 자동으로 보여 주도록 하는 것은 옳은 일이지만, 뉴스그룹의 특성상 여러가지 응용프로그램으로 올려진 많은 기사를 읽는다는 점에서, 또한, 특정언어를 사용하는 국가의 뉴스그룹이 분리되어 있다는 점에서 사용자에게 불편함을 초래 하게 된것이다. 예를 들면, YA! Newswatcher와 같은 맥용 뉴스 리더 프로그램은 그룹별 언어 설정을 할 수 있도록 하고 있다. 물론 결과적으로 한글 사용자에게 올바른 헤더를 올리도록 보급을 촉진한 점은 인정되지만, 또한 사용자 상호간에 이 문제로 인한, 불필요한 반목을 일으키는 원인을 제공하였음을 Microsoft는 인정해야 할 것이다.

그러나 불행히도, MIME을 지원하는 뉴스 프로그램 중에는 EUC-KR헤더를 지원하지 않는 경우가 많다. 물론 이들 프로그램의 메일은 아직은 ISO-2022-KR지원을 하지 않는다. 예를 들면, Agent의 경우, 0.99f 이후 MIME을 지원하게 되었는데, 불행히도 일본어인 ISO-2022-JP는 있어도, 한글인 EUC-KR설정이 없다. 그러나 Agent를 사용하는 사용자는 다음과 같은 Korea.csm이라는 이름의 텍스트 파일을 만들어, Agent가 설치된 디렉토리에 넣어 두면, Language 옵션에 Korean EUC-KR 옵션이 발생한다. 따라서, EUC-KR 헤더를 가진 8bit 기사와 QP 인코딩된 메일도 보낼 수가 있다.

Name: Korean

Charset: EUC-KR, us-ascii

Codepage: 949

#(The previous line must be blank.)

#

#This table maps between Windows code page 949 (Korean) and the

#MIME EUC-KR charset.

공개 뉴스 리더 프로그램인 WinVN의 경우에도 EUC-KR헤더를 가진 기사와 메일을 보낼 수 있다. WinVN의 경우, WinVN.ini의 중 MIMECharset 항목을 다음과 같이 ISO-8859-1에서 EUC-KR로 바꾸어 주어야 한다.

[Attachments]

MIMECharset=EUC-KR

mimPC 통신등에서 주로 사용되는 TIN 1.2 pl2의 경우 MIME을 지원하지 않아서 큰 문제는 없지만, UNIX용 응용 프로그램인 최신 버젼의 TIN 1.3 unoff beta의 경우는 ISO-2022-KR도 지원한다. 필자가 직접 사용을 해 보지는 않았지만, 한국어를 위한 tin의 설정은 e_charset은 EUC-KR,post_mime_encoding은 8bit, post_8bit_header는 ON, mail_mime_encoding은 7bit, mail_8bit_header는 OFF로 하여야 한다.(by Jungshik Shin)

3.2 WWW에서의 한글 사용

그러나 실제 han.* 뉴스그룹 사용자의 기사를 살펴 볼 때, 대다수의 잘못된 ISO-8859-1의 헤더를 가진 기사는 위의 언급한 프로그램으로 인한 것보다, 넷스케이프 사용자가 투고한 기사의 경우가 대부분이다. 물론 넷스케이프는 초기 버젼부터, EUC-KR의 한국어를 지원하였다. 그럼에도 불구하고 많은 넷스케이프 사용자는 Western (Latin1)으로 인코딩을 설정한 채로 WWW을 사용하며, 메일이나 뉴스의 사용에 있어서 조차 이러한 설정을 이용함으로서, 한글에 있어서 조차 iso-8859-1의 그릇된 헤더 정보를 가진 메시지를 전송하게 되었다. 물론 MS IE와 달리 한윈95상에서는 넷스케이프의 메시지 작성 창에서 독일어나, 불어, 스페인어를 입력할 수 없으며, 따라서, ISO-8859-1 메일이나 기사를 보낼 수 없음은 물론이다. 이것은 넷스케이프에서 Western상태에서도 한글이 보이기 때문이며, 오히려 Korean으로 encoding을 설정하면, <LI>택으로 인한 bullet이 깨지는 등의 문제가 있다. 물론 bullet의 문제는 최신 4.0베타 버젼에서, 수정되었다. 그러나, Unix나 매킨토시 버젼의 넷스케이프는 Western상태에서 한글이 보이지 않는다.

이 이유는 한글 Windows 3.1의 경우는 win.ini, 한글 Windows 95의 경우는 레지스트리에 설정값을 두고 있는 Font Association이라는 기능이 작동하기 때문이다. 이와 유사한 기능이, 영문 윈도우 상에서 한, 중, 일어를 보여주는 CJK-Viewer나 한메한글의 경우에도 사용된다. 윈도우 95의 레지스트리를 살펴보면 다음과 같은 레지스트리 키를 발견하게 된다.

REGEDIT4

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\fontassoc\Associated CharSet]

"ANSI(00)"="yes"

"SYMBOL(02)"="no"

"OEM(FF)"="yes"

이 중에서 Associated Charset키의 ANSI설정 값이 yes로 켜 있는 경우에 8bit 영역의 영문 폰트의 영역이 한글 폰트의 바탕체로 바뀌어 진다. MS IE를 제외한, 모든 영문 인터넷 응용 프로그램에서 Times New Roman, Courie등의 영문 폰트를 한글로 바꾸지 않았음에도 한글이 보이는 이유가 여기에 있는 것이다. 넷텀의 경우는 이중에서 OEM 설정 값에 영향을 받는다. 결과적으로 이 값이 yes로 설정되어 있는 한 넷스케이프로서는 프랑스, 독일, 스페인과 같은 사이트는 아무리 Western으로 하여도 보이지 않는 것이다. 이 값을 no로 설정하고 시스템을 재시동하면, 이러한 현상이 없어진다. 그러나, 다른 응용프로그램의 메뉴등 이 기능을 이용하는 프로그램의 경우에, 영향을 받아 한글이 보이지 않을 수 있다. Association된 한글 폰트는 원래의 한글 폰트보다 보기에도 좋지 않다. 따라서 모든 인터넷 응용프로그램에서 한글 관련 폰트를 굴림체나, 바탕체등 한글 폰트로 설정하고 사용하는 것이 좋다. 적어도 라틴어 국가의 언어를 가진 사이트는 볼 수 없어도, 3.0이전의 넷스케이프의 경우에, 다음과 같이 관련 레지스트리를 변경시켜, 한글을 사용하면, bullet이 깨지는 일을 예방할 수가 있으며, 미려한 굴림체로 한글을 사용할 수 있다.

REGEDIT4

[HKEY_CURRENT_USER\Software\Netscape\Netscape Navigator\INTL]

"URL Charset"="euc-kr"

"Font4"="euc-kr,굴림,12,굴림체,10,129,0"

넷스케이프사용자가 Western으로 하고 사용하는 경우의 문제점은 비단, News나 메일에만 영향을 끼치는 것은 아니다. 넷스케이프 3.0 Gold의 경우나, 4.0버젼대의 Netscape Composer 를 이용하여 만든 홈페이지는 언어가 영문인 상태에서 작성을 하였을 때, 한글이 다음과 같이 변형되어 저장된다.

&Agrave;&szlig;&cedil;&oslash;&micro;&Egrave;

&Ccedil;&Ntilde;&plusmn;&Ucirc;&Egrave;&uml;&AElig;&auml;&Agrave;&Igrave;&Aacute;&ouml;

즉, 한글이 ISO-8859-1의 특수 문자를 표기하는 표의방식의 택으로 바뀌었음을 알 수 있다. 이 내용은 단지 "잘못된 한글홈페이지"라는 짤막한 글이다. 이렇게 만들어진 홈페이지는 Font Association의 영향을 받지 않는 MS IE로는 보지 못하며, Windows가 아닌 다른 시스템의 넷스케이프로도 보지 못한다.

또 하나 이해할 수 없는 택이 있는데, 한글 홈페이지 중에는 주로 테이블의 폰트 설정에 있어서, <font face=arial> 라고 되어 있는 곳이 있다. arial 폰트는 영문폰트이며, 이 폰트의 어느 부분에도 한글이 없다. 그럼에도 불구하고 넷스케이프에서 볼 수 있는 것은 오로지 Font Association의 영향일 뿐이다.

필자는 최근 넷스케이프의 국내 공급사인 다우기술관계자와 Font Association 문제를 협의하였으며, 내부 검토 중이라고 한다.

홈페이지 작성에 있어서 추가로 언급할 내용으로 다음과 같은 언어설정 택이 있다.

<meta http-equiv="Content-Type" content="text/html; charset=ks_c_5601-1987">

이 택은 Microsoft의 FrontPage나 최신 IE 4.0 테스트버젼에 들어가 있는 FrontPad로 작성할 때에 만들어 진다. 이 meta 택 자체의 용도는 그 페이지가 해당 국가의 언어로 쓰여 있음을 고정 시키며, 따라서 사용자의 언어설정 변경을 무효화 시킨다. 그러나 앞서 언급한 바와 같이 KS C 5601이란 어떠한 구체적인 컴퓨터의 코드설정과는 독립적으로 단지, 한글, 한자, 그리고 특수 문자들을 배치해 놓은 것일 뿐이다. 따라서 KS C 5601 글자셋의 코드는 시스템마다 다를 수 있다. 다만, 인터넷에서 표준적으로 사용되는 8bit MIME encoded Charset으로서 EUC-KR은 KS C 5601의 구체적인 표현이라는 의미를 가진다. 따라서, 위의 헤더는 EUC-KR로 고쳐져야 한다. 만일 MS에서 자의적으로 만든 ks_c_5601-1987이란 또 하나의 구체적인 coded charset명을 사용한다면, Unix시스템이나 매킨토시 시스템의 경우에 unknown charset이 되므로, 아무리 언어 설정을 한국어로 하더라도 볼 수가 없다. 물론, 이를 이해하는 MS IE나, Font Association의 영향으로 한글을 볼 수 있는 윈도우용 넷스케이프 에서만이 볼 수 있을 따름이다. 따라서 MS의 웹저작툴은 호환성을 고려하여, EUC-KR로 고쳐져야 하며, ISO-2022-KR과 같이 인터넷 한글 협회에서는 이미 널리 쓰이는 EUC-KR을 8bit 한글 인코딩 문자셋 표준으로 정해야 할 것이다.

4. 맺음말

컴퓨터와 인터넷을 매개로 한 개방형 정보사회로의 이행에 있어서 무엇보다도 중요한 것은 표준을 지킴으로서 상호간의 원할한 정보 교류를 실현하는 일이다. 표준을 지키려는 노력은 개발자와 사용자 모두의 주의를 요한다. 한글이 걸림돌로 작용하는 한 우리나라 정보 사회의 생산성은 그만큼 뒤쳐질 수 밖에 없다. 또한 아무리 스스로 한글 사랑을 외쳐도 구체적인 문제를 타파하려는 노력이 없다면, 한글 문제의 해결은 요원할 수 밖에 없다. 무분별한 외국 프로그램사 간의 경쟁이 이루어지는 이 시점에 있어서 한번쯤 우리의 위치는 어떠한지 돌이켜 보아야 할 일이다.

References

[Postel 82] Jonathan B. Postel, SIMPLE MAIL TRANSFER PROTOCOL, August 1982,  URL:ftp://ftp.krnic.net/rfc/rfc821.txt

[Klensin 94] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, SMTP Service Extensions, July 1994, URL:ftp://ftp.krnic.net/rfc/rfc1651.txt

[Freed 96-1] N. Freed, N. Borenstein, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, November 1996, URL:ftp://ftp.krnic.net/rfc/rfc2045.txt

[Freed 96-2] N. Freed, N. Borenstein, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types, November 1996, URL:ftp://ftp.krnic.net/rfc/rfc2046.txt

[Moore 96] K. Moore, MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text, November 1996, URL:ftp://ftp.krnic.net/rfc/rfc2045.txt

[Choi 93] U. Choi, K. Chon, H. Park, Korean Character Encoding for Internet Messages, December 1993, URL:ftp://ftp.krnic.net/rfc/rfc1557.txt