컴퓨터 깨진 메일의 인코딩 종류를 아는 법
페이지 정보
황금비늘쪽지보내기 메일보내기 자기소개 아이디로 검색 전체게시물 06-08-11 20:58 조회6,862첨부파일
-
cvt8-7476.exe
(20.5K)
27회 다운로드
DATE : 2006-08-11 20:58:37
관련링크
본문
CVT8을 이용하면 대부분의 깨진 인터넷 메일을 복구할 수 있습니다. CVT8이 복구할 수 있는 인터넷 메일은 CVT8의 디코딩 메뉴에 나와있는 종류로 인코딩되어 보내진 메일입니다.
메일의 헤더를 살펴보면 어떤식으로 인코딩되어 보내진 메일인지 쉽게 확인할 수 있습니다. 헤더에 있는 encoding 부분을 살펴보면 [encoding=base64] 형식으로 표시되어 있기 때문입니다. 그러나 헤더를 살펴보지 않고 인코딩된 본문만 봐도 어떤 방법으로 인코딩된 것인지 알 수 있습니다.
ISO-2022-KR
ISO2022-KR 의 경우는 우선 한글이 사용된다는 것을 표시하기 위해 mail 의 본문에
<ESC>$)C
라는 문자열이 먼저 나옵니다. 그런 다음 한글이 시작되는 곳에는 SO 문자가 나오고, 한글이 끝나는 곳에는 SI 문자가 나옵니다. 즉 본문의 맨 앞이 <ESC>$)C로 시작되고 <SO>, <SI> 문자가 포함되어 있으면 그 메일은 ISO-2022-KR로 인코딩되어 보낸 메일인 것입니다.
Quoted Printable (QP)
QP의 경우는 8비트가 세트된 문자를 16진수 두 자리로 바꾸고 앞에 '=' 를 붙입니다. 분문이 다음과 같은 형식으로 보이면 QP로 인코딩된 메일입니다.
=BE=C8=B3=E7=C7=CF=BC=BC=BF=E4.
BASE64
BASE64의 경우는 8비트 문자 3개를 모아서 24비트를 만든 다음, 그것을 6비트씩 쪼개서 각각이 0x00..0x3F 의 범위에 있도록 합니다. 그런 다음 그 각각을 다음의 규칙으로 변환하여 4개의 7비트 문자로 변환합니다.
0x00..0x19 ==> 'A'..'Z'
0x1A..0x33 ==> 'a'..'z'
0x34..0x3D ==> '0'..'9'
0x3E ==> '+'
0x3F ==> '/'
메일의 본문이 다음과 같은 문자열로 되어 있으면 BASE64로 인코딩된 메일입니다.
vsiz58fPvLy/5C4gv/iw7bimIL/AtMMgtNkgusOz17/
uuencode/uudecode
uuencode/uudecode는 원래 유닉스 계정에서 바이너리 파일을 e-mail 로 전송하기 위해 만들어진 방법입니다. uuencoder를 통해 바이너리 파일을 텍스트 파일로 전환시켜 송신하고 받는 사람은 uudecoder를 통해 텍스트 파일을 다시 바이너리 파일로 바꾸는 방법을 사용합니다. 그러나 가끔씩 한글 텍스트를 uuencode로 인코딩하여 mail로 보내는 경우가 있습니다.
그러나 가끔씩 한글 텍스트를 uuencode로 인코딩하여 mail로 보내는 경우가 있습니다. 이것은 인터넷에서 한글 메일을 보내는 방법에 대해 설명하고 있는 시중의 책들이 옛날 것이라는 이유에서 기인합니다. SMTP가 압도적일 때 제작된 책들은 8비트 문자인 한글을 사용하여 메일을 보낼 때 바이너리 파일을 보내듯이 보내라고 말하고 있습니다. 그러나 8비트 문자열을 그대로 통과시키는 ESMTP 서버가 보편화되고 받는 메일 서버에서 인코딩된 8비트 본문을 자동으로 8비트로 디코딩하기 때문에 한글 메일을 보낼 때 굳이 본문을 uuencode할 필요는 없습니다.
더욱 중요한 점은 uuencode가 인터넷의 표준이 아니라는 것입니다. 인터넷의 메일 표준을 규정하는 MIME에서는 uuencode를 표준 인코딩으로 인정하지 않고 있으며 uuencode는 여러 가지 형식이 난재해 있으므로 안정성을 보장받을 수 없습니다. 어쨌거나 현실과 맞지 않는 오래된 방식의 uuencode를 통한 한글 메일 보내기가 가끔 행해지고 있는데 이런 식으로 보내온 메일을 해석할 때 CVT8을 사용하면 좋습니다. 그러나 최근 나오는 대부분의 메일러는 uuencode로 인코딩된 본문을 자동으로 디코딩하여 보여 줍니다.
uuencode/uudecode도 Base64와 비슷하게 8비트 문자 3개를 7비트 문자 4개로 변환하는데, Base64처럼 변환하지 않고 각각의 6비트 값에 단순히 32를 더해서 문자로 만듭니다. 그리고 begin 으로 시작하는 줄과 end 로 끝나는 줄 사이에 있는 내용이 인코딩된 내용입니다. 즉 본문의 처음에 다음 문자열이 들어가 있으면 uuencode 방식으로 보내온 메일입니다.
begin 600 ....
어쩌구 저쩌구...
end.
단 주의할 점은 CVT8은 uuencode 형식으로 보내진 텍스트를 완성형 한글로 변환시키는 것이지 바이너리 파일을 변환시키지는 않는다는 것입니다. 바이너리 파일은 다른 PC용 uudecoder나 유닉스 상에서 변환시켜야 합니다.
ISO-2022-7bits, 7bits
ISO-2022-7bits은 ISO-2022-KR 방식과 유사하나 한글 시작과 한글끝이 SO/SI 가 아니라 <ESC>$(C 와 <ESC>(B 인 점이 다릅니다. 자주 보이지는 않지만 가끔씩 뉴스그룹을 보다 보면 나오는데, 이것은 유닉스에서 MULE 등의 메일 프로그램을 쓰시는 분들이 환경 설정을 잘못 하면 메일이 이렇게 인코드되어 전송된다고 합니다.
7bits는 글자 그대로 인코딩된 것이 아니라 MSB 가 잘려서 완전히 깨진 한글 메시지를 볼 때 사용합니다. 이것은 e-mail 클라이언트에서 아무런 인코딩을 하지 않고 그냥 8비트 메시지를 보냈는데, 재수없게 센드메일이 7비트만 전송하도록 된 영문 버전일 경우 이렇게 되겠죠. 이 경우 CVT8은 메시지의 글자들 중에서 KS 완성형 한글 코드 영역에 포함되는 것으로 추측되는 글자들을 한글로 변환하는데, 완벽하지는 않아서 숫자나 기호가 엉뚱한 한글로 나오기도 합니다.
메일의 헤더를 살펴보면 어떤식으로 인코딩되어 보내진 메일인지 쉽게 확인할 수 있습니다. 헤더에 있는 encoding 부분을 살펴보면 [encoding=base64] 형식으로 표시되어 있기 때문입니다. 그러나 헤더를 살펴보지 않고 인코딩된 본문만 봐도 어떤 방법으로 인코딩된 것인지 알 수 있습니다.
ISO-2022-KR
ISO2022-KR 의 경우는 우선 한글이 사용된다는 것을 표시하기 위해 mail 의 본문에
<ESC>$)C
라는 문자열이 먼저 나옵니다. 그런 다음 한글이 시작되는 곳에는 SO 문자가 나오고, 한글이 끝나는 곳에는 SI 문자가 나옵니다. 즉 본문의 맨 앞이 <ESC>$)C로 시작되고 <SO>, <SI> 문자가 포함되어 있으면 그 메일은 ISO-2022-KR로 인코딩되어 보낸 메일인 것입니다.
Quoted Printable (QP)
QP의 경우는 8비트가 세트된 문자를 16진수 두 자리로 바꾸고 앞에 '=' 를 붙입니다. 분문이 다음과 같은 형식으로 보이면 QP로 인코딩된 메일입니다.
=BE=C8=B3=E7=C7=CF=BC=BC=BF=E4.
BASE64
BASE64의 경우는 8비트 문자 3개를 모아서 24비트를 만든 다음, 그것을 6비트씩 쪼개서 각각이 0x00..0x3F 의 범위에 있도록 합니다. 그런 다음 그 각각을 다음의 규칙으로 변환하여 4개의 7비트 문자로 변환합니다.
0x00..0x19 ==> 'A'..'Z'
0x1A..0x33 ==> 'a'..'z'
0x34..0x3D ==> '0'..'9'
0x3E ==> '+'
0x3F ==> '/'
메일의 본문이 다음과 같은 문자열로 되어 있으면 BASE64로 인코딩된 메일입니다.
vsiz58fPvLy/5C4gv/iw7bimIL/AtMMgtNkgusOz17/
uuencode/uudecode
uuencode/uudecode는 원래 유닉스 계정에서 바이너리 파일을 e-mail 로 전송하기 위해 만들어진 방법입니다. uuencoder를 통해 바이너리 파일을 텍스트 파일로 전환시켜 송신하고 받는 사람은 uudecoder를 통해 텍스트 파일을 다시 바이너리 파일로 바꾸는 방법을 사용합니다. 그러나 가끔씩 한글 텍스트를 uuencode로 인코딩하여 mail로 보내는 경우가 있습니다.
그러나 가끔씩 한글 텍스트를 uuencode로 인코딩하여 mail로 보내는 경우가 있습니다. 이것은 인터넷에서 한글 메일을 보내는 방법에 대해 설명하고 있는 시중의 책들이 옛날 것이라는 이유에서 기인합니다. SMTP가 압도적일 때 제작된 책들은 8비트 문자인 한글을 사용하여 메일을 보낼 때 바이너리 파일을 보내듯이 보내라고 말하고 있습니다. 그러나 8비트 문자열을 그대로 통과시키는 ESMTP 서버가 보편화되고 받는 메일 서버에서 인코딩된 8비트 본문을 자동으로 8비트로 디코딩하기 때문에 한글 메일을 보낼 때 굳이 본문을 uuencode할 필요는 없습니다.
더욱 중요한 점은 uuencode가 인터넷의 표준이 아니라는 것입니다. 인터넷의 메일 표준을 규정하는 MIME에서는 uuencode를 표준 인코딩으로 인정하지 않고 있으며 uuencode는 여러 가지 형식이 난재해 있으므로 안정성을 보장받을 수 없습니다. 어쨌거나 현실과 맞지 않는 오래된 방식의 uuencode를 통한 한글 메일 보내기가 가끔 행해지고 있는데 이런 식으로 보내온 메일을 해석할 때 CVT8을 사용하면 좋습니다. 그러나 최근 나오는 대부분의 메일러는 uuencode로 인코딩된 본문을 자동으로 디코딩하여 보여 줍니다.
uuencode/uudecode도 Base64와 비슷하게 8비트 문자 3개를 7비트 문자 4개로 변환하는데, Base64처럼 변환하지 않고 각각의 6비트 값에 단순히 32를 더해서 문자로 만듭니다. 그리고 begin 으로 시작하는 줄과 end 로 끝나는 줄 사이에 있는 내용이 인코딩된 내용입니다. 즉 본문의 처음에 다음 문자열이 들어가 있으면 uuencode 방식으로 보내온 메일입니다.
begin 600 ....
어쩌구 저쩌구...
end.
단 주의할 점은 CVT8은 uuencode 형식으로 보내진 텍스트를 완성형 한글로 변환시키는 것이지 바이너리 파일을 변환시키지는 않는다는 것입니다. 바이너리 파일은 다른 PC용 uudecoder나 유닉스 상에서 변환시켜야 합니다.
ISO-2022-7bits, 7bits
ISO-2022-7bits은 ISO-2022-KR 방식과 유사하나 한글 시작과 한글끝이 SO/SI 가 아니라 <ESC>$(C 와 <ESC>(B 인 점이 다릅니다. 자주 보이지는 않지만 가끔씩 뉴스그룹을 보다 보면 나오는데, 이것은 유닉스에서 MULE 등의 메일 프로그램을 쓰시는 분들이 환경 설정을 잘못 하면 메일이 이렇게 인코드되어 전송된다고 합니다.
7bits는 글자 그대로 인코딩된 것이 아니라 MSB 가 잘려서 완전히 깨진 한글 메시지를 볼 때 사용합니다. 이것은 e-mail 클라이언트에서 아무런 인코딩을 하지 않고 그냥 8비트 메시지를 보냈는데, 재수없게 센드메일이 7비트만 전송하도록 된 영문 버전일 경우 이렇게 되겠죠. 이 경우 CVT8은 메시지의 글자들 중에서 KS 완성형 한글 코드 영역에 포함되는 것으로 추측되는 글자들을 한글로 변환하는데, 완벽하지는 않아서 숫자나 기호가 엉뚱한 한글로 나오기도 합니다.
추천 0
댓글목록
등록된 댓글이 없습니다.
