게시판 본문 ASP, ASP.NET, IIS & Script - Read Only

말씀하신 부분은 사실 저도 대략의 정보만을 알고 있을 뿐, 체계적으로 정확하게 알고 있는 것은 아닙니다. 따라서 혹시 잘못된 정보가 있을 수도 있으므로 이 점을 감안하고 답변을 읽어주시기 바랍니다. ^_^;;

먼저 인코딩이라는 용어를 조금 자세하게 풀어서 생각해본다면 어떤 문자열을 나중에 다시 복원할 수 있도록 일정한 규칙에 따라서 변형하는 것을 말하는 것입니다. 즉 나중에 다시 복원하여 본래의 문자열로 만들려는 것, 이 과정을 디코딩이라고 하는데 아무튼 이것이 그 본래의 목적인 셈이죠. 그렇다면 어째서 나중에 다시 원래대로 복원할 것을 굳이 복잡한 방법을 사용하여 번거롭게 인코딩을 하는 것일까요? 그 가장 큰 이유는 바로 원래의 문자열을 그대로 전송하면 곤란한 경우가 있기 때문입니다.

주변에서 접해볼 수 있는 가장 대표적인 인코딩의 사례가 바로 URL 인코딩이죠. 예를 들어서 다음과 같은 가상의 URL 이 있다고 생각해 보겠습니다.

http://www.sample.com/sample.asp?id=song&gun

이 URL 에서 쿼리스트링 부분을 보시면 id=song&gun 라는 부분이 있는데 그 의미는 id 가 song&gun 이라는 값을 가지게 된다는 것이죠. 그런데 & 문자는 이미 URL 에서 특수한 의미를 가지고 있는 예약된 문자이기 때문에 그대로 사용하면 원하는 대로 동작을 하지 않게 됩니다. 그래서 이 경우에 URL 인코딩을 하여 다음과 같이 변형을 하게 됩니다.

http://www.sample.com/sample.asp?id=song%26gun

즉 & 문자의 아스키 코드가 26 번이므로 앞에 % 문자를 붙여서 %26 이라는 문자열로 변형한 것이죠. 이 경우 & 문자가 %26 으로 인코딩 된것입니다. 따라서 결국 URL 인코딩이란 특수 문자의 아스키 코드를 구하고 그 앞에 % 문자를 붙이는 것이라고 대략이나마 정의할 수 있을 것입니다. ^_^

질문하신 메일의 경우에도 비슷한 설명을 할 수가 있습니다. 먼저 7 bit 인코딩에 대해서 알아보겠습니다. 이 인코딩은 가장 기본적인 방법이라고 말할 수 있는데 7 bit 를 사용하여 문자를 표현하는 경우 모두 128 가지의 문자를 표현할 수 있습니다. 이 크기는 모든 알파벳과 여러가지 특수 기호들을 포함할 수 있는, 즉 영어권 국가에서는 전혀 부족함 없이 사용할 수 있는 크기죠. 사실 그렇기 때문에 이 방법을 사용하면 실제로는 아무런 인코딩 작업도 일어나지 않습니다. 따라서 7 bit 인코딩이라는 용어는 그저 다른 인코딩 방식과 구분하기 위한 용어 정도라고 이해하셔도 무방할 듯 싶습니다.

그런데 문제는 이 크기만 가지고서는 한글이나 기타 여러 국가의 언어들이나 특수한 문자들을 표현하는 데에는 여러모로 많은 부족함이 생기게 된다는 것입니다. 그래서 여기에 별도의 인코딩이 요구되는 것인데 말씀하신 8 bit 인코딩이나 QP 인코딩, Base64 인코딩 등은 모두 이런 목적으로 사용되는 인코딩을 말하는 것입니다. 즉 다국어로 작성된 메일을 인코딩을 통해서 7 bit 기반으로 전송해도 문제가 없도록 변형한 다음 메일을 받은 쪽에서는 인코딩한 방법의 역으로 디코딩을 해서 실제의 내용을 복원하여 사용자들에게 보여주는 것이죠. 이 설명은 실제의 과정을 간단하게 설명한 것이지만 대략 이러한 목적을 위하여 사용되는 것이 메일에서의 인코딩이라고 생각하시면 됩니다.

다음은 인터넷에서 찾아낸 각각의 인코딩 규칙입니다. 이 밖에도 몇 가지 인코딩 방식이 더 있는 것으로 알고 있습니다만, 저 역시도 그 부분까지는 잘 모르기도 하고 그다지 사용되지도 않는 방법이라고 생각되어 이 자리에는 올리지 않았습니다.

1. 7 bit

디폴트 인코딩 방법으로, 전송 데이터의 본문은 미리 7 bit 로 되어 있어야 하며, 전송 데이터에 대해 실제 인코딩은 하지 않고, 단지 데이터가 7 bit mail-ready representation으로 되어 있다는 것만 나타냅니다.

2. 8 bit

전송 데이터가 8bit, 즉, ASCII 문자뿐만 아니라, non-ASCII 문자를 포함하고 있음을 나타내고, 역시 실제 데이터에 대한 인코딩은 하지 않습니다.

3. Base64

24 bit (3 byte) 를 입력 받아서, 이를 6 bit 씩 잘라 4 byte를 출력하는 인코딩 방법입니다. ISO646 모든 버젼과 EBCIDIC 모든 버젼의 문자셋과 알파벳을 똑같이 표현할 수 있습니다. Base64 인코딩은 Base64 에서 정하는 딜리미터 (SPACE, TAB, CRLF 등) 에 의해 구분되는 단위에 따라 하게 됩니다. 이를 encoded-word 라고 하는데 encoded-word는 "=?charset?encoding?encoded-text?=" 로 표현되며, 문자셋은 인코딩의 대상이 되는 데이터의 문자셋을 나타냅니다.

4. QP (Quoted-Printable)

MSB 가 1 인 문자를 "0123456789ABCDEF" 를 사용해서 "=" 다음에 부호값에 해당하는 십육진수가 오는 형태로 인코딩하고, 부호값이 33 에서 60, 62 에서 126 까지인 문자는 ASCII 문자로 나타내고, 9 에서 32 까지의 부호값을 가지는 문자는 MSB 가 1 인 문자와 같은 방식으로 인코딩합니다. 이 방식으로 인코드된 데이터는 한 라인에 76 글자를 넘을 수 없습니다.


따라서 예를 들어서 메일을 보낼때 Base64 인코딩을 선택했다면 메일의 내용이 Base64 인코딩 규칙에 따라서 변형이 되어지고 전송되게 됩니다. 그리고 메일을 받은 편에서는 헤더를 읽어서 어떤 인코딩 방법을 사용한 메일인지를 파악하고 해당 인코딩 방법에 의거하여 디코딩을 한 다음 사용자에게 실제의 내용을 보여주게 되는 것이죠. 그런데 만약 메일을 보내는 사람이 Base64 인코딩을 사용하여 메일을 전송했지만 메일을 받는 사람이 사용하고 있는 메일 클라이언트에서는 Base64 인코딩을 디코딩 할 수 없는 경우가 발생한다면 어떤 일이 있어날까요? 당연히 이 경우에 메일을 받은 사람은 그 메일을 정상적으로 볼 수가 없게 됩니다.

다행히도 대부분의 메일 클라이언트 프로그램들에서는 위의 인코딩 방식들을 거의 다 지원해 줍니다. 예를 들어서 아웃룩 같은 프로그램들이 그렇습니다. 그런데 일부 외국의 웹 메일 업체들에서는 종종 Base64 인코딩이나 QP 인코딩을 제대로 지원하지 않는 경우가 있어서 문제가 되기도 합니다. 뭐 자기들은 영어로 메일을 작성하면 되므로 디폴트인 7 bit 로 전송을 해버리는 모양입니다. 그러나 만약 이런 경우라면 Base64 인코딩을 사용하여 전송된 메일을 정상적으로 보여주지 못하는 경우도 생길 수 있겠죠. 그러나 대부분 이런 경우라도 8 bit 인코딩은 지원해주는 것으로 알고 있습니다. ^_^;;

기본적인 내용은 대충 이렇습니다만 저도 메일 전송과 관련하여 MIME 쪽을 깊게 이해하고 있는 것은 아닙니다. 그러므로 더욱 자세한 정보를 알고 싶으시다면 W3C (http://w3c.org/) 에서 MIME 관련 문서들을 읽어보실 것을 권해드립니다. 그리고 웹 메일 서비스를 사용해서 메일을 전송하시는 경우에는 사실 해당 웹 메일 서버가 어떻게 구현되어 있느냐에 따라서 많은 영향을 받게 되기 때문에 제가 일률적으로 이렇다라고 말씀드리기는 힘들 것 같습니다. 다만 대부분의 웹 메일 업체들에서 크게 무리가 없는 설정을 디폴트로 해놓기 때문에 단순히 메일 서비스를 사용하시기만 할 것이라면 크게 신경쓰실 일은 없을 것 같구요.

그리고 마지막으로 한글, 영어 인코딩 부분은 HTML 에서 사용하는 캐릭터셋 같은 설정이라고 생각하시면 될 것 같습니다. 다만 말씀하신 대로 영어로 설정하고 한글을 써도 한글이 정상적으로 보이는 것은 메일을 전송하면서 실제 본문을 파악하여 정보를 수정하거나, 메일을 받는 쪽에서 지능적으로 처리를 하기 때문이 아닌가 하고 생각됩니다만 정확한 이유는 저도 들은 말씀만으로는 알기가 힘드네요. ^_^;;

감사합니다.