iWiz ShareBase

IT Specialist 윤태현의 iWiz ShareBase는 IT뿐 아니라 각종 잡다한 지식들을 함께 나누는 지식공유 커뮤니티입니다.

iWiz,ShareBase,윤태현,Java,JSP,EJB,IT,정보기술,웹프로그래밍,PHP,ASP,DBMS,MySQL,서버,네트워크,server,network,WAS,웹애플리케이션,블로그,blog,웹서버,DB,오라클,oracle,mysql,JRun,웹로직,톰캣,tomcat,아파치,자동차,EF쏘나타,로또 6/45

갤러리 Pixelgrapher.com | 로또 6/45 번호생성 및 통계 데이터 | 전체기사보기 | 전체글 #1 | 전체글 #2 | 전체글 #3 | 전체글 #4 | 전체글 #5 | 전체글 #6 | 전체글 #7 | 전체글 #8 | 전체글 #9 | 전체글 #10 |
HOME iWiz
ShareBase
Remember 0523 & 0818
지식은 나눌수록 커집니다 - iWiz's ShareBase
웹프로그래밍(기타) PHP, ASP, Perl, CGI 등 각종 웹프로그래밍에 관한 자료들입니다.


  iWiz(2004-07-12 18:58:13, Hit : 12902, Vote : 28
 http://www.wz.pe.kr

인터넷 메일 인코딩 및 HTML 처리


1. 한글 Encoding

문자 집합 (Charset)

한글의 7비트 인코딩이 처음 표준화된 것은 RFC 1557에서 ISO-2022-KR이 제졍되면서였습니다. 하지만, ESMTP에서 8비트 전송을 명기하고, 7비트 인코딩이 사장되어 감에 따라서, 표준안에서는 ISO-2022-KR 대신에 KSC5601 charset을 사용하는 것을 제안하고 있습니다.

하지만, 이미 실용적으로 EUC-KR (Extecded Unix Code for Korean)이 널리 사용되고 있고, KSC5601임을 표시하는 방식도 엄청나게 다양해서 다 처리하기 힘들 정도입니다. 실제로 Outlook Express와 같은 MUA에서도 이미 EUC-KR이 가장 안정적으로 지원되는 charset이고, 여타 다른 시스템에서도 가장 널리 사용되고 있는 de facto standard는 euc-kr이 아닌가 싶습니다.

호환 가능한 charset, Content-Transfer-Encoding

다음은 charset마다 사용 가능한 Encoding 방식을 나타냅니다.

ISO-2022-KR / 7bit
EUC-KR / 8bit, base64, quoted-printable

실제로는 이렇게 되어야 한다는 보장은 없습니다. 어차피 Encoding과 charset은 별개의 것이니까요.

7비트 Encoding은 점점 사라지고 있지만, 아직 사용되는 시스템을 위해서 Decoding은 지원하는 것이 좋겠다는 권장 사항이 있습니다.

헤더의 Encoding에서도 한글에 대해서는 대부분 "B" Encoding이 권장됩니다. 특별히 ASCII 문자가 많은 경우가 아니라면, "Q" Encoding을 사용할 이유는 별로 없습니다.



2. CRLF의 처리

RFC822를 보면, 가장 처음에 나오는 내용 중의 하나가...

모든 Line은 CRLF의 조합으로 끝난다...

입니다. 하지만, 이는 실제로 잘 안 지켜지는 내용 중의 하나입니다.

가장 큰 문제는 Platform마다 text/plain의 형식이 조금씩 다른 것 때문이라고 생각됩니다.
각 Platform마다 나타나는 차이첨을 살펴보면,

   Unix/Linux: 모든 Line은 LF로 끝난다. (간단하군요 ^^;)
   DOS/Window: 마지막 Line을 제외한 모든 Line은 CRLF로 끝난다.
   Macintosh: 모든 Line은 CR로 끝난다.

여기서 파생되는 문제점은 두 가지입니다. 전적으로 MIME Encoder의 문제지만, Decoder도 이에 대한 대비를 할 수 있어야 합니다.

   각 Line이 반드시 CRLF로 끝난다는 보장이 없다.
   마지막 Line에 CRLF가 누락된 경우가 상당히 많다.

두번째 경우가 더 큰 문제를 야기할 수 있습니다. 특히 Multipart로 구성된 메시지인 경우에 Epilogue를 인식할 수 없는 경우가 생기는 것이지요.

여담이지만, Outlook Express를 보면서 상당히 놀랄 수밖에 없었던 것이, 여러 가지 경우를 테스트하면서 온갖 종류의 규격에 맞지 않는 어떤 메일이 들어온다고 하더라도, Decode하지 못하는 경우를 거의 발견하지 못했다는 것입니다. (여태 딱 한 번 봤습니다. 이 경우도 왜 못하는지를 잘 이해할 수 없더군요.)
. HTML에 대한 Content-Transfer-Encoding

기본적으로 8bit Encoding 즉, Encoding을 하지 않거나, Base64 혹은 Quoted-Printable로 Encoding하는 것이 권장됩니다. 그다지 특별한 내용은 아니지요?

Outlook Express의 경우를 보면, 대부분의 경우에는 base64로 HTML 문서를 Encoding합니다만, 특별히 설정하지 않는 경우에 있어서는 multipart/alternative로 구성할 때, text/plain 쪽은 base64로, text/html 쪽은 quoted-printable로 구성하는 것을 볼 수 있습니다. 아무래도 앞에서도 언급한 quoted-printable의 장점 때문이겠지요?



2. HTML에 대한 Content-Type

charset 지정을 위해서 문서 안에 아래와 같은 META 태그를 사용하는 것을 권장하고 있습니다. 물론, 이 META 태그가 모든 Browser에서 다 먹히는 것은 아닙니다.

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=euc-kr">



3. Image의 처리

아래의 링크와 IMG 태그를 보시죠...

<a href="../example.html"> ... </a>
<img src="image/icon.gif">

두 경우 모두 그대로 전달된다면, MUA가 HTML 메시지를 지원한다고 하더라도 제대로 디스플레이될 수 없습니다. 대부분의 문서에서, URL이 들어가는 부분에 상대 주소를 사용하고 있기 때문이죠. HTML 메시지를 처리할 때, 생길 수 있는 문제는 바로 이 부분이죠.

어떤 식으로 HTML을 구성해야 이런 문제를 해결할 수 있을까요?

절대 URL로 Image 접근이 가능한 경우

이런 경우는 어렵지 않게 문제를 해결할 수 있습니다. 이런 경우에 사용할 수 있는 방법은 두 가지입니다.

   URL을 모두 절대 경로로 바꾸는 겁니다. 그러면 MUA에서 알아서 Image를 보여줄 수 있습니다. 다만 모든 URL이 나타나는 곳의 주소를 조심스럽게 변경해야 한다는 번거로움이 있겠네요.
   또 하나의 방법은 BASE 태그를 쓰는 것이지요. HTML 문서의 대부분의 URL이 하나의 Base URL에 포함되는 경우에 유용합니다. 위의 방법과 마찬가지로 이 방법도 상당히 많이 사용됩니다.

이런 경우에 HTML 메시지는 두 가지로 구성할 있습니다.

   Top Level Content-Type이 text/html인 메시지
   text/plain과 text/html로 구성된 multipart/alternative 메시지

절대 URL로 Image 접근이 불가능한 경우

이런 경우는 사용자의 컴퓨터에서 직접 HTML을 편집하고, 로컬 컴퓨터에 있는 이미지를 문서에 포함시켰을 때에 발생하게 됩니다.

여기서는 아까도 잠시 언급한 multipart/related 를 사용합니다.

각 Part는 아래와 같이 구성합니다.

   첫번째 본문 파트는 text/html 혹은 multipart/alternative로 구성한다.
   이후의 모든 Embedded Image를 각각의 Body Part로 구성한다.
   각 Part에 Content-ID를 부여하여 HTML 본문 중의 모든 URL과 아래와 같은 방식으로 연결한다.

<img src="cid:<Content-ID>">


예를 하나 보시기 바랍니다.

(전략...)
Content-Type: multipart/related;
    boundary="----=_NextPart_000_0008_01BF162B.976B0000";
    type="multipart/alternative"
(중략...)

This is a multi-part message in MIME format.

------=_NextPart_000_0008_01BF162B.976B0000
Content-Type: multipart/alternative;
    boundary="----=_NextPart_001_0009_01BF162B.976B0000"

------=_NextPart_001_0009_01BF162B.976B0000
Content-Type: text/plain; charset="ks_c_5601-1987"
Content-Transfer-Encoding: 8bit

(텍스트 메시지)

------=_NextPart_001_0009_01BF162B.976B0000
Content-Type: text/html; charset="ks_c_5601-1987"
Content-Transfer-Encoding: 8bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<META content="text/html; charset=ks_c_5601-1987" http-equiv=Content-Type>
</HEAD>

<BODY bgColor=#ffffff>

...
<IMG src="cid:000501bf15e0$276dfb40$865566d2@bawi.org">

...

</BODY>
</HTML>

------=_NextPart_001_0009_01BF162B.976B0000--

------=_NextPart_000_0008_01BF162B.976B0000
Content-Type: image/jpeg; name="m001.jpg"
Content-Transfer-Encoding: base64
Content-ID: <000501bf15e0$276dfb40$865566d2@bawi.org>

Image 내용...

------=_NextPart_000_0008_01BF162B.976B0000--

   Content-Type이 "multipart/related"로 되어 있습니다. 여기에 boundary가 붙고, type이라는 parameter를 사용하고 있습니다. type이 "multipart/alternative"로 되어 있는데, 이는 뒤에 "text/plain"과 "text/html"이 같이 있다는 것이 되겠네요.

   HTML 메시지의 중간에 IMG 태그가 있고, src에 지정된 URL이 Content-ID임을 알 수 있습니다. 그리고 뒤의 한 본문 파트에 같은 Content-ID가 있는데, 이 부분이 이후에 이 HTML 메시지가 디스플레이될 때, 어떻게든 처리가 되는 겁니다.


이런 식으로 하면, 복잡하지만 HTML 메시지와 거기에 포함된 이미지 등을 함께 보내는 것이 가능합니다.
* iWiz님에 의해서 게시물 이동되었습니다 (2010-02-03 16:57)



62   mod_throttle 모듈을 이용한 사용자 트래픽 제어  iWiz 2006/06/22 9000 0
61   Tomcat-Apache using JK2 connector  iWiz 2004/03/21 7379 41
60   RedHat 9.0에서의 JRun JSP 컴파일러의 문제점  iWiz 2004/01/04 5476 50
59   RedHat 9.0에서의 JRun-Apache 커넥터의 문제점  iWiz 2004/01/04 5143 48
58   JRun 4.0의 튜닝 관련 옵션  iWiz 2004/01/04 5890 68
57   JRun 4.0의 Activity 모니터링 방법  iWiz 2004/01/04 4869 57
56   JRun4.0: DataSource 커넥션풀 관련 옵션 [4]  iWiz 2004/01/04 6614 46
55   JRun에서 JSP 컴파일시 java 파일 생성하기  iWiz 2004/01/04 8012 63
54   JRun의 실제 서비스 운영시 고려사항  iWiz 2004/01/04 6311 44
53   수정된 인터넷 익스플로러에서 상호작용 ActiveX 컨트롤 활성화 가이드  iWiz 2006/03/03 8370 4
52   HTML 특수기호 엔터티(Entity) 테이블 [2]  iWiz 2006/03/03 14109 2
51   웹사이트의 새로운 혁명 Ajax [13]  iWiz 2005/11/22 5809 6
50   MSN 메신저 친구 자동등록 스크립트  iWiz 2004/10/12 6142 35
49   JavaScript MD5 해쉬 생성 함수  iWiz 2004/01/07 8998 35
48   JavaScript로 만든 진법변환 및 보수계산기 [4]  iWiz 2004/01/04 159766 51

1 [2][3][4][5]
 

Copyright 1999-2023 Zeroboard / skin by zero
iWiz ShareBase, ⓒCopyleft by iWiz.  For more information contact .
본 웹사이트에 게시된 이메일 주소가 전자우편 수집 프로그램이나 그 밖의 기술적 장치를 이용하여 무단으로 수집되는 것을 거부하며, 이를 위반시에는 정보통신망법에 의해 형사처벌됨을 유념하시기 바랍니다. [게시일 2004. 1. 31]