한글 메일 복구 방법

한글 메일이 깨지는 이유

인터넷에서의 E-mail 전송코드는 7bit 체계이고, 한글은 8bit 체계이기 때문에 메일프로그램에서 한글메일을 보낼때 한글을 인코딩하여 보내게 됩니다. 하지만, 익스플로러의경우 한글을 ISO-2022-KR 방식으로 인코딩을 하고,넷스케이의 경우 ISO-8859-1 방식으로 인코딩하기 때문에 서로 다른 브라우저를 사용한다면 한글이 깨져보일 수 있습니다.
아래의 방법을 이용하여 간단하게 한글메일을 복구하여 보실 수 있습니다. 보다 자세한 한글메일 사용법은 아래 문서를 참고해 주시기 바랍니다.

인터넷 한글 전자우편 S/W 사용 안내서(한국전산원)

한글 메일 복구방법 - cvt8이란?

CVT8 은 인터넷에서 인코딩되어 알아볼 수 없는(즉 한글이 깨진) e-mail 을 받았을 때 이를 해독하여 원래의 메시지를 복원하는 프로그램입니다.

CVT8 은 윈도우용이며 한글 윈도우 3.1 과 한글 윈도우 95에서 쓸 수 있습니다. 한글 윈도우 NT 에서는 시험해 보지는 않았지만 쓸 수 있을 것이라 생각합니다. 이 프로그램은 자체 한글 처리 능력은 없습니다. 따라서 영문 윈도우에서는 동작은 하겠지만 한글을 디스플레이할 수는 없습니다. 영문 윈도우에서는 한메 한글 for 윈도우나 Unionway 같은 윈도우용 한글 프로그램이 있어야 할 것입니다.

1. 어떻게 쓰는 겁니까?

우선 유도라나 넷스케이프, MS Exchange 같은 e-mail 프로그램에서 깨진 메시지를 선택하여 클립보드에 복사합니다. 유도라의 경우는 깨진 메시지를 띄우고 Edit 메뉴에서 Select All 을 한 다음, 다시 Edit 메뉴에서 Copy 를 하면 메시지가 복사됩니다. 혹은 키보드에서 <Ctrl-A> <Ctrl-C> 를 누르면 됩니다.그 다음 CVT8 을 띄우고 Decode 메뉴에서 적절한 디코딩 방법을 선택하면 메시지를 해독하여 보여줍니다. 디코딩 메뉴에는 여러 가지가 있는데, 잘 모르면 차례대로 하나씩 선택해 보면 됩니다.

해독된 메시지를 다시 e-mail 프로그램으로 가져가고 싶으면, 마우스로 원하는 부분을 선택한 다음 <Ctrl-C> 를 누르거나, Edit 메뉴에서 Copy 를 선택해서 클립보드로 복사합니다. 그런 다음 유도라나 넷스케이프에서 <Ctrl-V>를 눌러서 paste 하면 되겠습니다.

e-mail 에 답장을 보낼 때는 원래 메시지의 각 줄의 처음에 '> 표시를 붙이는 경우가 많습니다. 이럴 때는 Edit 메뉴에서 Quote Back 을 누르면 해독된 메시지의 각 줄의 처음에 '>' 를 붙인 다음 그것을 전체 선택해서 클립보드로 복사하는 일까지 한꺼번에 해 줍니다.

File 메뉴에서 Save As 를 하면 해독된 메시지를 텍스트 파일로 저장할 수 있습니다. 또 Print 를 선택하면 메시지를 프린터로 찍어 줍니다. 현재 윈도우의 기본 프린터로 지정된 곳으로 출력되며, Courier New 서체의 9포인트 크기로 찍어 줍니다. 단 출력이 별로 예쁘지 않으므로, 좀 더 나은 출력을 원한다면 해독된 메시지를 워드 프로세서 등으로 옮겨서 인쇄하기 바랍니다.

▶▶ top

2. 한글 메일은 왜 깨지는 겁니까?

e-mail 이 전송되는 경로는 대개 다음과 같습니다.

여기서 MTA에 해당하는 것이 sendmail 인데, 이 sendmail은 client가 보내는 메일을 외부로 전송하고, 또 외부에서 들어온 메일을 받아서 각 client에게 전달해 주는 역할을 합니다.

그런데 이 sendmail 은 원래 7비트만 전송하도록 되어 있었기 때문에 한글로 메일을 작성해서 보내면 MSB 가 모두 날아가서 이상한 영문으로 깨져서 보였습니다. 요즘 설치되는 유닉스 기계들의 sendmail들은 대부분 8비트를 그대로 통과시키지만, 옛날에 나온 기계들 중에는 아직도 MSB를 잘라먹는 놈들이 많이 있습니다.


이를 해결하기 위해 만들어진 것이 ISO2022-KR 이란 인코딩 방식입니다. 이 방식은한국과학기술원(KAIST)의 몇분의 주도로 만들어졌으며, 이후 IETF에 의해 한글 메일을 인코딩하는 표준방식으로 인정되어 현재 RFC 1557로 등록되어 있습니다. 이를 구현한 것이 한글 sendmail 인데, 클라이언트에서 보낸 메시지 중에 한글 텍스트가 포함되어 있으면 이것을 ISO2022-KR 방식으로 인코딩하여 7비트로 만들어서 전송하고, 들어온 메일이 ISO2022-KR 로 인코딩되어 있으면 그것을 원래 메시지로 복원하는 기능을 가지고 있습니다. 한국 내에 설치된 메일 서버 중 70% 이상이 이 한글 sendmail을 이용하고 있는 것으로 알고 있습니다.

그러나 이 방식은 보내는 쪽 서버와 받는 쪽 서버 모두 한글 sendmail이 설치되어 있어야 합니다. 국내에서 메일을 주고받을 때는 별문제가 없지만, 국내라도 한글 패치되지 않은 원래 영문 sendmail을 사용하는 사이트라든가 외국 사이트에 메일을 보내면 받는 쪽 sendmail이 ISO2022-KR 인코딩을 해독하지 못하기 때문에 인코딩된 메시지가 그대로 전달이 됩니다. 인코딩된 메시지는 당연히 알아볼 수가 없으므로 받는 쪽에서는 한글 메시지가 깨졌다고 생각하게 되는 것입니다.

한글 메일이 문제가 되자 MS Mail 이나 Netscape 4.0 등 몇몇 e-mail 클라이언트들이 자체 내에 ISO2022-KR 인코딩을 해독할 수 있는 기능을 집어넣고 있습니다만, 아직까지 일반화되고 있지는 않습니다. 또 많은 e-mail 클라이언트들이 메일을 인코딩하고 디코딩할 때 조금씩 차이가 있기 때문에 완벽하게 한글이 복원되지 않을 수가 있습니다.

▶▶ top

3. 한글 sendmail 은 뭐가 문제입니까?

한글 sendmail, 혹은 ISO2022-KR에 대해서는 찬반양론이 있습니다. 한글 sendmail을반대하는 쪽에서는 메일의 인코딩/디코딩은 e-mail 클라이언트가 알아서 할 일이지 sendmail과 같은 MTA는 메일 내용을 건드리지 말아야 한다고 주장하고 있습니다. 혹은 MTA에서 일괄변환하더라도 ISO2022-KR 대신 더 많은 e-mail 클라이언트들이 지원하고 있는 QP 나 Base64 (FAQ 6~9 참조) 를 사용하자는 의견도 있습니다.

한글 sendmail을 찬성하는 쪽에서는 ISO2022-KR는 엄연히 IETF에서 인정한 표준이며, QP나 Base64보다는 한글을 인코딩하는 데 훨씬 효율적이라고 주장합니다. 또한 갈수록 많은 e-mail 클라이언트들이 ISO2022-KR을 지원하고 있으므로, 지금의 혼란은 곧 진정될 것이라고 말합니다. 일본어를 위해 제안된 ISO2022-JP가 대부분의 e-mail 클라이언트에서 지원되고 있는 것을 예로 들고 있습니다.

한글 e-mail 문제는 확실히 과도기에 있으며, 조만간 어떤 방식으로든 정착이 될것입니다. 최근 버전의 sendmail 들은 8비트를 그대로 통과시키는 ESMTP 프로토콜을구현하고 있기 때문에 아예 인코딩을 하지 않고 8비트 그대로 보내도 괜찮습니다. 그러나 소수이긴 하지만 아직도 MSB를 잘라먹는 MTA들이 있기 때문에 ISO2022-KR과같은 인코딩이 필요합니다. 최근 한국내의 소프트웨어 개발업체들과 인터넷 서비스 업체들이 모임을 가지고 ISO2022-KR 을 보완하여 계속적으로 한글 메일 교환의 표준으로 사용하기로 했다고 하므로, 모든 MTA들이 8비트가 된 후에도 ISO2022-KR이 계속 사용될 가능성도 있습니다.

4. CVT8 이 지원하는 각종 디코딩 방식에 대해 알려주시겠습니까?

8비트 문자를 e-mail로 전송하는 방법에는 ISO2022-KR 외에도 많은 방법이

있습니다. 그 중 CVT8 은 많이 사용되는 QP (quoted printable), Base 64, 그리고 uuencode를 지원합니다. 이 중 QP나 Base 64는 영어권에서 개발된 것으로 알고 있으며, 많은 e-mail 클라이언트들(유도라나 넷스케이프)에서 지원하기 때문에 널리 인정받는

표준이라고 할 수 있죠. 그에 비해 ISO2022-KR은 우리나라에서 개발되었으며 한글을 인코딩하는 데는 적합하지만 지원하는 프로그램이 얼마 되지 않는다는 점이 약점입니다.

▶▶ top

5. ISO2022-KR 은 어떻게 인코딩합니까?

ISO2022-KR 의 경우는 우선 한글이 사용된다는 것을 표시하기 위해 mail 의 본문에 <ESC>$)C 라는 문자열이 먼저 나옵니다. 여기서 ESC 는 아스키 27번의 이스케이프 제어문자입니다. 그런 다음 한글이 시작되는 곳에는 SO (shift-out, 아스키 14번, Ctrl-N 에 해당) 문자가 나오고, 한글이 끝나는 곳에는 SI (shift-in, 아스키 15번, Ctrl-O 에 해당) 문자가 나옵니다. SO 와 SI 사이에 있는 한글은 MSB를 클리어해서 7비트 범위 내에 들어오도록 되어 있습니다. 가령 <ESC>$)C <SO>H3gGO=J4O1n<SI>.위 문자열은 "녕하십니까." 가 됩니다.

6. QP 는?

QP 의 경우는 8비트가 세트된 문자를 16진수 두 자리로 바꾸고 앞에 '=' 를 붙입니다. 가령 &quot;안녕하세요.&quot; 를 바꾸면 =BE=C8=B3=E7=C7=CF=BC=BC=BF=E4.가 됩니다.  7비트 범위 내에 있는 글자는 변환하지 않고 그대로 둡니다.

7. Base 64는?

Base64 의 경우는 8비트 문자 3개를 모아서 24비트를 만든 다음, 그것을 6비트씩 쪼개서 각각이 0x00..0x3F 의 범위에 있도록 합니다. 그런 다음 그 각각을 다음의 규칙으로 변환하여 4개의 7비트 문자로 변환합니다.

  0x00..0x19 ==> 'A'..'Z'

  0x1A..0x33 ==> 'a'..'z'

  0x34..0x3D ==> '0'..'9'

  0x3E       ==> '+'

  0x3F       ==> '/'

만일 주어진 문자열이 정확히 24비트의 배수가 아니면 뒤에는 '=' 를 덧붙입니다.

이 규칙으로 &quot;안녕하세요&quot;를 변환하면 vsiz58fPvLy/5A== 가 됩니다.

▶▶ top

8. uuencode/uudecode 는?

uuencode/uudecode는 원래 바이너리 파일을 e-mail 로 전송하기 위해 만들어진 방법이며, 텍스트 파일을 전송하는 데는 잘 사용되지 않습니다. 그러나 가끔씩 한글 텍스트를 uuencode로 인코딩하여 mail로 보내는 사람도 있으므로 CVT8에 포함시켰습니다.

uuencode/uudecode 도 Base64 와 비슷하게 8비트 문자 3 개를 7비트 문자 4개로 변환하는데, Base64처럼 변환하지 않고 각각의 6비트 값에 단순히 32를 더해서 문자로 만듭니다. 그리고 begin 으로 시작하는 줄과 end 로 끝나는 줄 사이에 있는 내용이 인코딩된 내용이며, 각각의 줄은 그 줄의 글자 수를 나타내는 값 (대개는 M 으로서, 45개의 문자가 있음을 나타냄)으로 시작합니다. 자세한 것은 유닉스에서 man 명령으로 uuencode를 찾아보면 나와 있습니다.

9. CVT8의 메뉴 중 ISO2022-7bits 과 7bits는 무엇입니까?

CVT8은 이외에도 ISO2022-7bits 과 7bits의 두 가지 메뉴를 가지고 있는데, ISO2022-7bits은 ISO2022-KR 방식과 유사하나 한글 시작과  한글끝이 SO/SI 가 아니라 <ESC>$(C 와 <ESC>(B 인 점이 다릅니다. 자주 보이지는 않지만 가끔씩 뉴스그룹을 보다 보면 나오는데, 이것은 유닉스에서 MULE 등의 메일 프로그램을 쓰시는 분들이 환경 설정을 잘못 하면 메일이 이렇게 인코드되어 전송된다고 합니다.

7bits 는 글자 그대로 인코딩된 것이 아니라 MSB 가 잘려서 완전히 깨진 한글 메시지를 볼 때 사용합니다. 이것은 e-mail 클라이언트에서 아무런 인코딩을 하지 않고 그냥 8비트 메시지를 보냈는데, 재수없게 sendmail이 7비트만 전송하도록 된 영문 버전일 경우 이렇게 되겠죠. 이 경우 CVT8은 메시지의 글자들 중에서 KS 완성형 한글 코드 영역에 포함되는 것으로 추측되는 글자들을 한글로 변환하는데, 완벽하지는 않아서 숫자나 기호가 엉뚱한 한글로 나오기도 합니다. 그러나 아예 못 알아보는 것보다는 낫겠지요.

10. EUC-KR 와 KS C 5601 의 차이점은 무엇입니까?

엄밀하게 말하면 다르겠지만 (사실 저도 정확히 뭐가 다른지는 모르지만, 하여간 다르다고 그러네요), 일반 사용자의 입장에서는 같다고 봐도 됩니다. 둘 다 우리가 현재 사용하고 있는 완성형 한글 코드를 말합니다. EUC-KR 은 주로 유닉스에서 KS C 5601 코드가 사용될 때 부르는 것으로 알고 있습니다.

▶▶ top

11. ISO646, ISO8859-1, ISO2022 는 무엇입니까?

ISO646 은 현재 우리가 사용하고 있는 7비트 아스키 코드를 말합니다. 여기에는 7비트의 범위, 즉 0..127 에 해당하는 문자만 정의되어 있습니다. ISO8859 는 아스키를 확장하여 128부터 255에 해당하는 범위의 문자를 정의하는데, 그 중에서 ISO8859-1 은 유럽에서 사용되는 각종 문자들(독일어의 움라우트나 불어의 액센트 등)을 그 범위에 정의한 것입니다.

ISO2022는 2바이트 이상의 문자(한글, 일본어, 중국어 등등)를 위한 문자 코드를 만들 때 기본이 되는 표준입니다. 우리나라의 KS C 5601, 일본의 JIS, 중국의 GB 코드 등이 모두 이 표준에 따라 만들어진 것입니다. 그러나 ISO2022 자체로는 어떠한 문자의 개별적인 코드도 정의하지 *않고* 있습니다.

ISO2022 에서는 아스키 0..31 까지의 제어문자 영역을 C0 라고 하고, 128..159 까지를 C1 영역이라고 해서 문자 코드로 사용 못하게 합니다. 따라서 가용한 범위는 160..255인데, KS C 5601의 경우는 161..254 (A1..FE) 까지를 사용하고 있습니다. 그리고 영문을 쓰다가 2바이트 문자가 나올 경우는 이스케이프 시퀀스 (KS C 5601 의 경우는 <ESC>$(C )를 두어서 알 수 있도록 하고 있습니다.

ISO2022-KR 은 문자 코드는 아니지만, 이 ISO2022에 정의된 방식에 따라서 인코딩을  합니다. 마찬가지로 일본어를 위한 ISO2022-JP, 중국어를 위한 ISO2022-CN 도 ISO2022에 규정된 방법을 따릅니다.

12. 한글 mail 에 대해 좀 더 자세한 정보를 알고 싶습니다.

뉴스그룹 중  han.comp.mail    han.comp.hangul 이 한글과 e-mail에 대해 많은 정보를 담고 있습니다. 한편

    
    http://yes.snu.ac.kr/queen/hmailfaq.htm

    http://pantheon.cis.yale.edu/~jshin/faq/hmail.html

에 많은 자료가 있습니다. 참고하시기 바랍니다.

만약 이 프로그램으로도 복구가 안된다면 대단히 복구하기가 힘들것입니다. 아래의 사이트를 참조해 주시기 바랍니다.

http://dblab.changwon.ac.kr/tips/e_mail.html

▶▶ top