내발자국[동호회]
[FAQ] CVT8 코드변환프로그램 사용방법
松巖
1997. 5. 11. 22:44
CVT8 FAQ
이 문서는 CVT8.EXE 에 대한 FAQ (frequently asked question) 입니다.
작성자: 이 준희
작성일: 1997. 2. 22.
차례:
1. CVT8 은 뭐하는 프로그램입니까?
2. 어떤 환경에서 쓸 수 있습니까?
3. 어떻게 쓰는 겁니까?
4. 한글 메일은 왜 깨지는 겁니까?
5. 한글 sendmail 은 뭐가 문제입니까?
6. CVT8 이 지원하는 각종 디코딩 방식에 대해 알려주시겠습니까?
7. ISO2022-KR 은 어떻게 인코딩합니까?
8. QP 는?
9. Base 64는?
10. uuencode/uudecode 는?
11. CVT8의 메뉴 중 ISO2022-7bits 과 7bits는 무엇입니까?
12. EUC-KR 와 KS C 5601 의 차이점은 무엇입니까?
13. ISO646, ISO8859-1, ISO2022 는 무엇입니까?
14. 한글 mail 에 대해 좀 더 자세한 정보를 알고 싶습니다.
15. 감사의 말
부록: CVT8의 변천사
====================================================================
1. CVT8 은 뭐하는 프로그램입니까?
CVT8 은 인터넷에서 인코딩되어 알아볼 수 없는(즉 한글이 깨진) e-mail 을
받았을 때 이를 해독하여 원래의 메시지를 복원하는 프로그램입니다.
2. 어떤 환경에서 쓸 수 있습니까?
CVT8 은 윈도우용이며 한글 윈도우 3.1 과 한글 윈도우 95에서 쓸 수 있습니다.
한글 윈도우 NT 에서는 시험해 보지는 않았지만 쓸 수 있을 것이라 생각합니다.
이 프로그램은 자체 한글 처리 능력은 없습니다. 따라서 영문 윈도우에서는
동작은 하겠지만 한글을 디스플레이할 수는 없습니다. 영문 윈도우에서는 한메
한글 for 윈도우나 Unionway 같은 윈도우용 한글 프로그램이 있어야 할 것입니다.
3. 어떻게 쓰는 겁니까?
우선 유도라나 넷스케이프, MS Exchange 같은 e-mail 프로그램에서 깨진 메시지를
선택하여 클립보드에 복사합니다. 유도라의 경우는 깨진 메시지를 띄우고 Edit
메뉴에서 Select All 을 한 다음, 다시 Edit 메뉴에서 Copy 를 하면 메시지가
복사됩니다. 혹은 키보드에서
그 다음 CVT8 을 띄우고 Decode 메뉴에서 적절한 디코딩 방법을 선택하면 메시지를
해독하여 보여줍니다. 디코딩 메뉴에는 여러 가지가 있는데, 잘 모르면 차례대로
하나씩 선택해 보면 됩니다.
해독된 메시지를 다시 e-mail 프로그램으로 가져가고 싶으면, 마우스로 원하는
부분을 선택한 다음
클립보드로 복사합니다. 그런 다음 유도라나 넷스케이프에서
paste 하면 되겠습니다.
e-mail 에 답장을 보낼 때는 원래 메시지의 각 줄의 처음에 '>' 표시를 붙이는
경우가 많습니다. 이럴 때는 Edit 메뉴에서 Quote Back 을 누르면 해독된 메시지의
각 줄의 처음에 '>' 를 붙인 다음 그것을 전체 선택해서 클립보드로 복사하는
일까지 한꺼번에 해 줍니다.
File 메뉴에서 Save As 를 하면 해독된 메시지를 텍스트 파일로 저장할 수 있습니다
.
또 Print 를 선택하면 메시지를 프린터로 찍어 줍니다. 현재 윈도우의 기본 프린터로
지정된 곳으로 출력되며, Courier New 서체의 9포인트 크기로 찍어 줍니다.
단 출력이 별로 예쁘지 않으므로, 좀 더 나은 출력을 원한다면 해독된 메시지를
워드 프로세서 등으로 옮겨서 인쇄하기 바랍니다.
4. 한글 메일은 왜 깨지는 겁니까?
e-mail 이 전송되는 경로는 대개 다음과 같습니다.
클라이언트 메일 서버 메일 서버 클라이언트
(주로 PC) (주로 유닉스 서버)
e-mail ====> mail transfer ====> .... ====> mail transfer ====> e-mail
client agent (MTA) agent (MTA) client
넷스케이프 sendmail sendmail 넷스케이프
유도라 유도라
elm elm
PINE PINE
등등...
여기서 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 클라이언트들이 메일을
인코딩하고 디코딩할 때 조금씩 차이가 있기 때문에 완벽하게 한글이 복원되지
않을 수가 있습니다.
5. 한글 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이
계속 사용될 가능성도 있습니다.
6. CVT8 이 지원하는 각종 디코딩 방식에 대해 알려주시겠습니까?
8비트 문자를 e-mail로 전송하는 방법에는 ISO2022-KR 외에도 많은 방법이
있습니다. 그 중 CVT8 은 많이 사용되는 QP (quoted printable), Base 64, 그리고
uuencode를 지원합니다.
이 중 QP나 Base 64는 영어권에서 개발된 것으로 알고 있으며, 많은 e-mail
클라이언트들(유도라나 넷스케이프)에서 지원하기 때문에 널리 인정받는
표준이라고 할 수 있죠. 그에 비해 ISO2022-KR은 우리나라에서 개발되었으며
한글을 인코딩하는 데는 적합하지만 지원하는 프로그램이 얼마 되지 않는다는
점이 약점입니다.
7. ISO2022-KR 은 어떻게 인코딩합니까?
ISO2022-KR 의 경우는 우선 한글이 사용된다는 것을 표시하기 위해 mail 의
본문에
라는 문자열이 먼저 나옵니다. 여기서 ESC 는 아스키 27번의 이스케이프
제어문자입니다. 그런 다음 한글이 시작되는 곳에는 SO (shift-out, 아스키 14번,
Ctrl-N 에 해당) 문자가 나오고, 한글이 끝나는 곳에는 SI (shift-in, 아스키
15번, Ctrl-O 에 해당) 문자가 나옵니다. SO 와 SI 사이에 있는 한글은 MSB를
클리어해서 7비트 범위 내에 들어오도록 되어 있습니다. 가령
위 문자열은 "안녕하십니까." 가 됩니다.
8. QP 는?
QP 의 경우는 8비트가 세트된 문자를 16진수 두 자리로 바꾸고 앞에 '=' 를
붙입니다. 가령 "안녕하세요." 를 바꾸면
=BE=C8=B3=E7=C7=CF=BC=BC=BF=E4.
가 됩니다. 7비트 범위 내에 있는 글자는 변환하지 않고 그대로 둡니다.
9. 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비트의 배수가 아니면 뒤에는 '=' 를 덧붙입니다.
이 규칙으로 "안녕하세요"를 변환하면
vsiz58fPvLy/5A==
가 됩니다.
10. 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를 찾아보면 나와 있습니다.
11. CVT8의 메뉴 중 ISO2022-7bits 과 7bits는 무엇입니까?
CVT8은 이외에도 ISO2022-7bits 과 7bits의 두 가지 메뉴를 가지고 있는데,
ISO2022-7bits은 ISO2022-KR 방식과 유사하나 한글 시작과 한글끝이 SO/SI 가
아니라
뉴스그룹을 보다 보면 나오는데, 이것은 유닉스에서 MULE 등의 메일 프로그램을
쓰시는 분들이 환경 설정을 잘못 하면 메일이 이렇게 인코드되어 전송된다고
합니다. 이전에는 이 인코딩이 무엇인지 잘 몰라서 그냥 ISO2022-?? 라는
어정쩡한 이름을 붙여 두었는데, 신 정식 씨께서 이것에 대해 알려 주셨습니다.
7bits 는 글자 그대로 인코딩된 것이 아니라 MSB 가 잘려서 완전히 깨진 한글
메시지를 볼 때 사용합니다. 이것은 e-mail 클라이언트에서 아무런 인코딩을 하지
않고 그냥 8비트 메시지를 보냈는데, 재수없게 sendmail이 7비트만 전송하도록 된
영문 버전일 경우 이렇게 되겠죠. 이 경우 CVT8은 메시지의 글자들 중에서 KS
완성형 한글 코드 영역에 포함되는 것으로 추측되는 글자들을 한글로 변환하는데,
완벽하지는 않아서 숫자나 기호가 엉뚱한 한글로 나오기도 합니다. 그러나 아예
못 알아보는 것보다는 낫겠지요.
12. EUC-KR 와 KS C 5601 의 차이점은 무엇입니까?
엄밀하게 말하면 다르겠지만 (사실 저도 정확히 뭐가 다른지는 모르지만, 하여간
다르다고 그러네요), 일반 사용자의 입장에서는 같다고 봐도 됩니다. 둘 다
우리가 현재 사용하고 있는 완성형 한글 코드를 말합니다. EUC-KR 은 주로
유닉스에서 KS C 5601 코드가 사용될 때 부르는 것으로 알고 있습니다.
13. 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 의 경우는
ISO2022-KR 은 문자 코드는 아니지만, 이 ISO2022에 정의된 방식에 따라서
인코딩을 합니다. 마찬가지로 일본어를 위한 ISO2022-JP, 중국어를 위한
ISO2022-CN 도 ISO2022에 규정된 방법을 따릅니다.
14. 한글 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
에 많은 자료가 있습니다. 참고하시기 바랍니다.
15. 감사의 말
CVT8을 제작하고 업그레이드하는 데는 많은 분들의 도움이 있었습니다. 신 정식 씨,
이 영득 씨, 박 명석씨, Gilbert Yun 씨, 유 승헌 씨, han.comp.mail 에 한글 메일에
관한 많은 토론을 해 주신 여러분들, 한글 sendmail의 제작자분들, 그외 한글 메일을
위해 노력해 오신 많은 분들에게 감사드립니다. CVT8을 사용해 보시고 편지를 보내
주신 많은 분들, 그리고 무엇보다도 제게 깨진 편지를 많이 보내 주셔서 프로그램
테스트를 충실하게 할 수 있게 해 주셨던 여러분들께 감사드립니다 :-)
======================================================================
부록: CVT8 의 변천사
- 1997. 2. 22. 버전
. CVT8-FAQ.TXT 의 내용 일부 수정
- 1997. 1. 27. 버전
. 메뉴 체계 변경 - File, Edit, Decode, Help 메뉴
. Save As, Print, Select All, Quote Back 추가
. CVT8-FAQ.TXT 를 읽어서 보여주는 기능 추가
- 1996. 7. 1. 버전
. Base 64 디코딩에서 원문의 줄바꿈을 처리못하는 버그 제거
. UUDecode 디코딩에서 공백이 숫자 0 으로 나타나는 버그 제거
. ISO2022-KR 과 관련된, FAQ 의 잘못된 점 수정
- 1996. 6. 16. 버전
. Base 64 디코딩 추가
. 메일 헤더에 제목 등이 인코딩되었을 경우 (?=EUC-KR?B?...) 이를 복원하는
기능 추가
. 이 FAQ 작성
- 1996. 2. 15. 버전
. 인터넷에 공개된 첫 버전
. MS Visual C 1.5 로 재코딩함
. 메뉴 구성 변경
- 1996. 1. 10. 버전
. QP, 7bits, ISO2022-??, uuencode/uudecode 추가
- 1995. 12. 19 버전
. ISO2022-KR 디코딩 구현
- 1995. 9. 21. 버전
. 최초 제작, 사내용 프로그램
. Visual Basic 3.0 으로 작성
. 휴리스틱을 이용하여 KS C 5601 코드 영역에 포함되는 것으로 추측되는
문자들을 8비트로 변환