RFC 1557을 개정하려는 시점에서 새롭게 character set을 추가하는 것보다, 현 재 가장 보편적으로 사용되고 있는 iso-2022-kr을 그대로 사용하고, 다만 그 encoding 방법을 7bit로 명시합니다. 물론 RFC 1521에 encoding에 관한 언급이 없으면 7bit로 처리한다고 되어 있습니다. 따라서 character set을 iso-2022-kr로 사용했다면 굳이 7bit로 명시하지 않아도 무관합니다. 다만, 간 혹 encoding을 7bit가 아닌 8bit 또는 base64로 전송되는 경우가 있을 수 있으 므로 그 표현방법을 확실히 하고자하는 의도입니다.
MIME 타입이 아닌 편지를 받았을 때에는 헤더는 RFC 1522에 따른 encoding 정보대로 처리하고 본문의 경우는 designator가 존재할 때만 한글이 포함된 편지 로 처리합니다.
Iso-2022-kr 형식으로 편지 본문을 encoding 한 후 다시 한번 QP 또는 Base64 로 encoding 하는 경우, 이미 iso-2022-kr로 7bit 전송이 아무런 문제 없이 이 루어 질 수 있는데도 다른 형식으로 encoding 했기 때문에 잘못된 것입니다.
뉴스그룹에 글을 올릴 때에는 추가로 encoding 작업을 거치지 않고 제목과 본 문 모두 8bit이고 character set은 EUC-KR로 지정합니다. 단, 뉴스그룹에서 메 일로 전송을 할 때는 일부 환경에서는 8bit를 받아주기 어려운 부분이 있기 때 문에 이런 상황을 고려해서 7bit로(iso-2022-kr로 encoding) 보내는 것을 권장 합니다.
예제)
MIME에서 표기하는 헤더정보(content type과 content transfer encoding 지정)
맞는 예)
Content-Type: text/plain; charset=iso-2022-kr
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=iso-2022-kr
<Contnet-Transfer-Encoding은 생략>
Content-Type: text/html; charset=iso-2022-kr
Content-Transfer-Encoding: 7bit
잘못된 예)
iso-2022-kr은 7bit 형식이므로 Content Transfer Encoding 헤더에 8bit(또는
base64, quoated-printable)이라고 표기한 것은 잘못입니다.
Content-Type: text/plain; charset=iso-2022-kr
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=iso-2022-kr
Content-Transfer-Encoding: base64
euc-kr은 본문의 charset이 아니라 헤더를 encoding 했을때만 사용이 가능합니 다. 하지만 뉴스그룹에 메시지를 보내는 것이라면 아래의 예는 맞는 경우가 됩 니다.
Content-Type: text/plain; charset=euc-kr
Content-Transfer-Encoding: 8bit
2. designator, white space, shift in/out
designator는 최초로 한글이 나타나기 전, 본문의 임의의 위치에 제일 첫 칸에 명시되어야 합니다. designator의 경우 반드시 CRLF가 따라올 필요가 없습니 다. 다시 말하면 designator를 나타낸 후에 CRLF를 추가하는 것은 잘못 된 것 입니다. 편지를 받는 쪽에서는 만약 designator 바로 다음에 따라오는 CRLF가 있다면 그대로 존중해주는 것을 권장합니다.
designator가 선언된 후에는 언제나 영문상태(SI, shift in 상태)로 시작하는 것을 가정합니다. 따라서 designator 바로 다음에 한글이 따라올 때는 반드시 한글상태임을 나타내는 <SO> (shift out)을 designator와 한글사이에 넣어주어 야 합니다.
공백문자의 처리는 EUC-KR이 공백문자를 포함하느냐 하지 않느냐의 관점에 따 라 달라질 수 있습니다. iso-2022의 code table에 따르면 GL 영역에 공백문자 는 02/00, delete는 07/15에 그리고 그 나머지 영역에(02/01 - 07/14) 94 또는 94^n coded character set이위치하고 있습니다. designator가 G1에 KS C 5601 을 나타내고 G1은 GL에 invoke하므로 SO 상태에서 SI을 하지 않고도 공백 문자를 사용할 수 있습니다.
하지만 대부분의 DBCS 시스템들을 구현할 때 7bit 환경에서의 space문제를 생 각하지 않으므로 오해에 의한 잘못된 표현이 생길 가능성이 매우 큽니다. 따라 서 현재의 의미 그대로 SO/SI 사이에는 02/01 - 07/14의 문자만 올 수 있는 것 으로 권장하고, 다만 편지를 decode할 때, space를 이 사이에 포함시켜서 (SI/SO을 하지 않고) 보내는 경우도 있으므로 이런 경우를 고려해서 decode해 야 합니다.
한 줄의 끝이 한글 상태(shift out)로 종료하는 경우 CRLF 이전에 shift in(SI)을 삽입해야 합니다.
예제) "<" 와 ">"로 둘러싸인 부분은 encoding되었거나 아래에 표기된 용도로 쓰임을 의미합니다.
<designator> = ESC $ ) C
<ESC> = <ISO 2022 ESC, escape>
<SI> = <ASCII SI, shift in>
<SO> = <ASCII SO, shift out>
<SP> = <ASCII SP, space>
원본 (EUC-KR)
******(시작)
Internet Mail<CRLF>
<CRLF>
Internet을 통해서 한글이 포함된<CRLF>
Mail을 전송할 때는<CRLF>
전송되는 내용이 손실을 입지<CRLF>
않도록 RFC 문서를<CRLF>
참조해서 작성해야 한다.<CRLF>
******(끝)
encoding 된 문서 (iso-2022-kr)
맞는 예 1)
******(시작)
<designator>Internet Mail<CRLF>
<CRLF>
Internet<SO>을<SI> <SO>통해서<SI> <SO>한글이<SI>
<SO>포함된<SI><CRLF>
Mail<SO>을<SI> <SO>전송할<SI> <SO>때는<SI><CRLF>
<SO>전송되는<SI> <SO>내용이<SI> <SO>손실을<SI> <SO>입지<SI><CRLF>
<SO>않도록<SI> RFC <SO>문서를<SI><CRLF>
<SO>참조해서<SI> <SO>작성해야<SI> <SO>한다<SI>.<CRLF>
******(끝)
맞는 예 2)
******(시작)
Internet Mail<CRLF>
<designator><CRLF>
Internet<SO>을<SI> <SO>통해서<SI> <SO>한글이<SI>
<SO>포함된<SI><CRLF>
Mail<SO>을<SI> <SO>전송할<SI> <SO>때는<SI><CRLF>
<SO>전송되는<SI> <SO>내용이<SI> <SO>손실을<SI> <SO>입지<SI><CRLF>
<SO>않도록<SI> RFC <SO>문서를<SI><CRLF>
<SO>참조해서<SI> <SO>작성해야<SI> <SO>한다<SI>.<CRLF>
******(끝)
맞는 예 3)
******(시작)
Internet Mail<CRLF>
<CRLF>
<designator>Internet<SO>을<SI> <SO>통해서<SI> <SO>한글이<SI> <SO>포함된
<SI><CRLF>
Mail<SO>을<SI> <SO>전송할<SI> <SO>때는<SI><CRLF>
<SO>전송되는<SI> <SO>내용이<SI> <SO>손실을<SI> <SO>입지<SI><CRLF>
<SO>않도록<SI> RFC <SO>문서를<SI><CRLF>
<SO>참조해서<SI> <SO>작성해야<SI> <SO>한다<SI>.<CRLF>
******(끝)
잘못된 예 1)
아래의 예는 designator가 한 줄을 차지하면서 새로운 줄을 삽입한 경우가 잘 못되었습니다. 즉 원문이 시작할 때 한 줄 빈 줄이 있었다면 맞는 것이 되지만 원래의 내용에는 첫줄에 빈줄이 없었기 때문에 잘못된 것입니다.
******(시작)
<designator><CRLF>
Internet Mail<CRLF>
<CRLF>
Internet<SO>을<SI> <SO>통해서<SI> <SO>한글이<SI>
<SO>포함된<SI><CRLF>
Mail<SO>을<SI> <SO>전송할<SI> <SO>때는<SI><CRLF>
<SO>전송되는<SI> <SO>내용이<SI> <SO>손실을<SI> <SO>입지<SI><CRLF>
<SO>않도록<SI> RFC <SO>문서를<SI><CRLF>
<SO>참조해서<SI> <SO>작성해야<SI> <SO>한다<SI>.<CRLF>
******(끝)
잘못된 예 2)
아래의 예는 designator가 줄의 첫칸에 오지 않은 것이 잘못 되었습니다.
******(시작)
Internet Mail<CRLF>
<CRLF>
Internet<designator><SO>을<SI> <SO>통해서<SI> <SO>한글이<SI> <SO>포함된
<SI><CRLF>
Mail<SO>을<SI> <SO>전송할<SI> <SO>때는<SI><CRLF>
<SO>전송되는<SI> <SO>내용이<SI> <SO>손실을<SI> <SO>입지<SI><CRLF>
<SO>않도록<SI> RFC <SO>문서를<SI><CRLF>
<SO>참조해서<SI> <SO>작성해야<SI> <SO>한다<SI>.<CRLF>
******(끝)
잘못된 예 3)
아래의 예는 줄이 끝날 때 SO상태에서 SI상태로 전환하지 않은 것이 잘못되었
습니다.
******(시작)
Internet Mail<CRLF>
<CRLF>
Internet<designator><SO>을<SI> <SO>통해서<SI> <SO>한글이<SI> <SO>포함된
<CRLF>
<SI>Mail<SO>을<SI> <SO>전송할<SI> <SO>때는<CRLF>
전송되는<SI> <SO>내용이<SI> <SO>손실을<SI> <SO>입지<CRLF>
않도록<SI> RFC <SO>문서를<CRLF>
참조해서<SI> <SO>작성해야<SI> <SO>한다<SI>.<CRLF>
******(끝)
3. MIME의 multi-part 형태로 되어있는 편지
Multi-part로 되어있는 편지의 경우에 한글이 포함되어 있는 각각의 body에 designator를 사용해서 designator의 유효범위를 각각의 body로 제한합니다. 다만, designator를 편지 내용 전체에 하나만 사용하는 경우도 있으므로 decode 할 때 충분히 이런 상황을 고려해야 합니다.
예제)
Content-Type: multipart/mixed; boundary="MAIL-boundary"
This is a multi-part message in MIME format.
--MAIL-boundary
Content-Type: text/plain; charset=iso-2022-kr
Content-Transfer-Encoding: 7bit
<designator>첫 번째 본문을 나타내는
부분입니다. 중얼... 중얼...
--MAIL-boundary
Content-Type: text/plain; charset=iso-2022-kr
Content-Transfer-Encoding: 7bit
<designator>두 번째 본문을 나타내는
부분입니다. 중얼... 중얼...
--MAIL-boundary--
EUC-KR은 GR영역에 KS C 5601이, GL영역에 ASCII가 있는 encoding입니다. 따라 서 GL영역의 ASCII를 EUC-KR의 일부라고 해석할 것인지, 아니면 EUC-KR 문자열 이 끝나고 ASCII가 시작되는 것인지에 대한 해석의 문제입니다. 따라서 해석 방법에 따라 전체 또는 부분 encoding 모두 가능합니다. 헤더에 포함되는 파일 이름과 같이 하나의 토큰으로 인식되어야 하는 경우에는 전체를 하나의 encoding으로 처리해야 합니다. 헤더 처리 방법의 자세한 부분은 RFC 1522을 참조하시기 바랍니다.
예제) 파일이름을 제외한 일반적인 경우는 헤더 중에서 제목을 기준으로 Base64로 encoding 한 것으로 설명합니다.
맞는 예)
Subject: 한글이 들어있는 편지
Subject: =?EUC-KR?B?<한글이 들어있는 편지>?=
Subject: =?EUC-KR?B?<한글이 >?= =?EUC-KR?B?<들어있는 >?=
=?EUC-KR?B?<편지>?=
Subject: Internet 편지를 보냅니다
Subject: =?EUC-KR?B?<Internet 편지를 보냅니다>?=
Subject: Internet =?EUC-KR?B?<편지를 보냅니다>?=
Subject: Internet으로 편지를
Subject: =?EUC-KR?B?<Internet으로 편지를>?=
Subject: 당신의 E-mail 주소를 알려주십시오
Subject: =?EUC-KR?B?<당신의 E-mail 주소를 알려주십시오>?=
Subject: =?EUC-KR?B?<당신의>?= E-mail =?EUC-KR?B?<주소를 알려주십시오>?=
Subject: 사용중인 OS환경을 기준으로...
Subject: =?EUC-KR?B?<사용중인 OS환경을 기준으로...>=
잘못된 예)
encoding된 단어들 사이의 빈칸은 무시하므로 decoding하면 아래와 같이 원본
과 다른 결과를 얻습니다.
Subject: 한글이 들어있는 편지
Subject: =?EUC-KR?B?<한글이>?= =?EUC-KR?B?<들어있는>?=
=?EUC-KR?B?<편지>?=
Subject: 한글이들어있는편지 <== decoding된 것
Internet과 encoding된 "으로 편지를" 사이에 공백 문자가 없으므로 잘못된 것
입니다. 그렇다고해서 두 번째의 예처럼 공백문자를 넣으면 원래의 제목에는
없던 공백문자가 생깁니다.
Subject: Internet으로 편지를
Subject: Internet=?EUC-KR?B?<으로 편지를>?=
Subject: Internet =?EUC-KR?B?<으로 편지를>?=
Subject: Internet 으로 편지를 <== decosing된 것
Iso-2022-kr로 encoding된 메시지를 메일 프로그램이 별도로 저장할 때는 원래 보냈던 사람의 의도가 유지될 수 있도록 decoding 되지 않은 상태로 저장하는 것을 권장합니다. 다만, 메시지를 다른 형식(텍스트 또는 HTML 등)으로 저장할 때는 EUC-KR로 decoding을 한 후에 처리합니다.
EUC-KR이 character set으로 등록이 되어있는지 불확실하므로 정확한 조사가 필요합니다.
또 한가지는 위의 2번 항목의 공백문자 처리에서 iso-2022 원문에 근거해야 하 는 부분이 있습니다. 이 부분 중에서 designator가 G1에 KS C 5601을 나타내고 G1은 GL에 invoke한다는 것이죠.
designator의 위치에 관한 내용도 있습니다. 한글이 나오는 줄에 와야하는 건 지, 아니면 한글이 나오기 이전이라면 어느 곳이라도 관계가 없는 것인지 하는 거죠. 우리가 해석하기로는 두 번째 의견이 우세했습니다. 왜냐하면 RFC 1557 의 BNF식을 보면 designator는 영문으로 된 줄 앞에도 나올 수 있는 것으로 되 어있습니다.